Re: [HACKERS] Core dump in regression tests.

In message <199808311703.SAA29362@mtcc.demon.co.uk>, Keith Parks writes:
> Thomas A. Szybist" <szybist@boxhill.com>
> > > Bruce Momjian
> > > 
> > > Again, if someone wants to conditionally compile the directories to find
> > > the offending file, I am sure we can get a fix for it.
> > > 
> > 
> > At first look it seems to be:  backend/catalog/indexing.c.
> > Maybe Keith can confirm?  
> > 
> 
> With the latest from cvs the core dump on "create table" is back
> when compiled with -O2.
> 
> 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?

> 
> I'm still getting some regression test failures, the worst of which
> is a core when creating a function.
> 
> Here's a bactrace from a "create function" immediately after an initdb
> and using the template1 database.
> 
> Keith.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x34264 in GetIndexValue (tuple=0x1ba810, hTupDesc=0x1ba86c, attOff=0, 
> attrNums=0x1bd544, fInfo=0x0,
>     attNull=0xefffcc97 "") at indexam.c:404
> 404                     returnVal = heap_getattr(tuple, attrNums[attOff],
> (gdb) bt
> #0  0x34264 in GetIndexValue (tuple=0x1ba810, hTupDesc=0x1ba86c, attOff=0, 
> attrNums=0x1bd544, fInfo=0x0,
>     attNull=0xefffcc97 "") at indexam.c:404
> #1  0x4974c in FormIndexDatum (numberOfAttributes=1, attributeNumber=0x1bd544, 
> heapTuple=0x1ba810,
>     heapDescriptor=0x1ba86c, datum=0xefffcd80, nullv=0xefffcd20 "   \230", 
> fInfo=0x0) at index.c:1284
> #2  0x4a4e8 in CatalogIndexInsert (idescs=0xefffcdf8, nIndices=3, 
> heapRelation=0x171b90, heapTuple=0x1ba810)
>     at indexing.c:154
> #3  0x4fb2c in ProcedureCreate (procedureName=0x166bf0 "widget_in", returnsSet=0 
> '\000',
>     returnTypeName=0x166bb0 "widget", languageName=0xefffcf98 "C", 
> prosrc=0xeb800 "-",
>     probin=0x1aeb10 "/usr/local/pgsql/src/test/regress/input/../regress.so", 
> canCache=112 'p',
>     trusted=1 '\001', byte_pct=100, perbyte_cpu=0, percall_cpu=0, 
> outin_ratio=100, argList=0x166bd0,
>     dest=Remote) at pg_proc.c:275
> #4  0x55674 in CreateFunction (stmt=0x165a50, dest=Remote) at define.c:329
> #5  0xb8430 in ProcessUtility (parsetree=0x165a50, dest=Remote) at utility.c:392
> #6  0xb60f8 in pg_exec_query_dest (
>     query_string=0xefffd1a0 "CREATE FUNCTION widget_in(opaque)\n   RETURNS 
> widget\n   AS '/usr/local/pgsql/src/test/regress/input/../regress.so'\n   
> LANGUAGE 'c';", dest=Remote, aclOverride=0 '\000') at postgres.c:749
> #7  0xb5fec in pg_exec_query (
>     query_string=0xefffd1a0 "CREATE FUNCTION widget_in(opaque)\n   RETURNS 
> widget\n   AS '/usr/local/pgsql/src/test/regress/input/../regress.so'\n   
> LANGUAGE 'c';") at postgres.c:687
> #8  0xb72ec in PostgresMain (argc=10, argv=0xeffff268, real_argc=10, 
> real_argv=0xeffffd84) at postgres.c:1609
> #9  0x9f27c in DoBackend (port=0x107c00) at postmaster.c:1519
> #10 0x9ecf4 in BackendStartup (port=0x167c00) at postmaster.c:1291
> #11 0x9e16c in ServerLoop () at postmaster.c:750
> #12 0x9dcc4 in PostmasterMain (argc=0, argv=0xeffffd84) at postmaster.c:556
> #13 0x723b0 in main (argc=10, argv=0xeffffd84) at main.c:93                  
> 
> 

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.

Tom Szybist
szybist@boxhill.com