I apologize for not being able to include significant details of the build, as this is happening on a sandboxed system in a proprietary context.
I've been attempting to dump emacs built from the 28.1 tarball with a large number of core libraries preloaded. I have observed segmentation faults when attempting to dump with native-compilation enabled and with native-compilation disabled. However, it only happened with one file (nxml/rng-pttrn.el) while dumping several hundred core libraries with native compilation. With native compilation disabled, the problem has appeared with both auth-source.el and emacs-lisp/eieio-core.el, the latter preventing me from proceeding much further in the dump process. Note these were both dumped successfully with native-compilation enabled.
I used gdb to look at the backtrace after the segmentation fault while loading auth-source.el, and the stack was in a tight recursive loop in purecopy:
for (i = 0; i < size; i++)
vec->contents[i] = purecopy (vec->contents[i]);
In this case the index I alternated between two values in each pair of stack frames: 0 and 10.
I'm not familiar enough with the layout of lisp objects to recognize the pseudo vector type on site, but it's probably a byte-vector with a recursive call - the constants vector in slot 0, and the recursive binding in slot 10 of the constants vector. Plus, the fact that this started happening more frequently with byte-compilation only is suspicious in itself.
Since I'm restricted to using official release tarballs with only local modifications, I'd welcome any hints on any "quick fix" to the problem aside from the long-term solution of just eliminating purecopy altogether (unless that can be done with a de minimis change to the code).
Lynn