[ cc'ing Remi to see if he remembers anything about how he got around this ] Stefan Kaltenbrunner <stefan@xxxxxxxxxxxxxxxx> writes: > FWIW: there also seems to be a fairly indepth discussion on the cobalt > related netbsd list from last year about a problem that looks very > similiar (at least to you issue with etch): > http://www.nabble.com/Strange-segmentation-fault-trying-to-run-postgresql-on-current-to9997129.html Hmm. I'm not sure it's the same problem, because what they were getting was SIGSEGV not SIGBUS. OTOH I would think the latter is a more correct errno for reporting an alignment trap, so maybe the NetBSD kernel has been fixed since then to report SIGBUS for this case. Anyway, it would be easy to verify this theory by looking at the instruction stream and registers in Glyn's dump, to see if it's trying to store at a non-aligned address. The conclusion of the thread seemed to be that it was a linker or assembler problem triggered by our use of SUBSYS.o files to aggregate all the backend .o files into a smaller number of files for the final link. If so the answer is either (a) update to a newer toolchain that might fix the problem, or (b) try our CVS HEAD which doesn't use the SUBSYS.o trick anymore. Mind you, I'd not especially recommend trying to run CVS HEAD for production purposes, but it would be real interesting at this point to see if you can compile it and run the regression tests with the toolchain you've got. regards, tom lane
