Re: [HACKERS] Core dump in regression tests. - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [HACKERS] Core dump in regression tests. |
Date | |
Msg-id | 199808311747.NAA23967@candle.pha.pa.us Whole thread Raw |
In response to | Re: [HACKERS] Core dump in regression tests. (Keith Parks <emkxp01@mtcc.demon.co.uk>) |
List | pgsql-hackers |
> 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)
pgsql-hackers by date: