Thread: Re: [HACKERS] Core dump in regression tests.
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.
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
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
> 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. I have looked over indexing.c and can still see nothing strange. I do remember that ProcedureSrcIndexScan/PROSRC cache call never worked in the old code, so this call is now working, but that is the only functional difference I remember. The old code in this section was somewhat mangled. Can I telnet into this machine? > > 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, My guess is that hTupDesc is badly formed, not having the proper attributes for the relation. Can you do a print of *hTupDesc, and attrNums[0]? > 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 > > -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)