Re: [HACKERS] Core dump in regression tests.

From: Keith Parks <emkxp01(at)mtcc(dot)demon(dot)co(dot)uk>
To: szybist(at)boxhill(dot)com
Cc: maillist(at)candle(dot)pha(dot)pa(dot)us, hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Core dump in regression tests.
Date: 1998-08-31 19:19:29
Message-ID: 199808311919.UAA01013@mtcc.demon.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas A. Szybist <szybist(at)boxhill(dot)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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Massimo Dal Zotto 1998-08-31 20:51:21 Re: [HACKERS] TPRINTF in trace.h
Previous Message korapat 1998-08-31 18:40:57 UNION opration NOT return all result set :) pls help