Re: [HACKERS] Core dump in regression tests. - Mailing list pgsql-hackers

From Keith Parks
Subject Re: [HACKERS] Core dump in regression tests.
Date
Msg-id 199808311919.UAA01013@mtcc.demon.co.uk
Whole thread Raw
Responses Re: [HACKERS] Core dump in regression tests.  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Core dump in regression tests.  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Core dump in regression tests.  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
Thomas A. Szybist <szybist@boxhill.com>
>
> >
> > If I compile backend/catalog with -O2 then the table creation is
>                                     ^^^
> > OK. So it looks like it may be indexing.c, even with Bruce's
> > recent fixes.
>
> Do you mean -O0 here?
>

Yes, a typo, I used -O0 for this dir.

>
> I managed to get this running on a Solaris box.  -O2 was not included
> by default (wonder why :)).  I got a core dump when running initdb
> with -O2.  I recompiled indexing.c without -O2, and it is much better.
> (I basically get the same results as under Linux.)  I get the same
> core dumps that Keith is seeing with create function.
>
> So, both my Sparc boxes are behaving the same.
>

I've not got round to trying a build on my Solaris 2.6 box yet. I was
hoping that someone with something faster than a SPARC 2 would do
the biz and get the same results.

So we have at least two problems, some code that is tickling a gcc
optimiser bug (gcc 2.7.2.1 in my case) and an alignment bug in our
code that affects SPARC architecture.

I've half a mind to see if there is a later version of gcc that
does the optimisation correctly. (rpm format for Redhat 4.2)

The "create function" problem is a little harder for me to see
a way forward. ( my debugging skills are very few.)

Keith.


pgsql-hackers by date:

Previous
From: Peter T Mount
Date:
Subject: JDBC Update
Next
From: David Hartwig
Date:
Subject: AIX Port Strangness