Re: Initdb problem on debian mips cobalt: Bus error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: glynastill(at)yahoo(dot)co(dot)uk, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-general(at)postgresql(dot)org, remi_zara(at)mac(dot)com
Subject: Re: Initdb problem on debian mips cobalt: Bus error
Date: 2008-08-06 13:55:41
Message-ID: 12639.1218030941@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

[ cc'ing Remi to see if he remembers anything about how he got around this ]

Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martin Gainty 2008-08-06 13:58:08 Re: Invocation overhead for procedural languages
Previous Message Sim Zacks 2008-08-06 13:16:42 Re: bytea encode performance issues