Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group