Thread

  1. Re: [HACKERS] Core dump in regression tests.

    Thomas A. Szybist <szybist@boxhill.com> — 1998-09-01T14:04:09Z

    In message <199809010623.CAA00709@candle.pha.pa.us>, Bruce Momjian writes:
    > > Thomas A. Szybist <szybist@boxhill.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.
    > 
    > One idea is to track heapDescriptor from CatalogIndexInsert() all the
    > way down into the lower functions.
    > 
    > Compile with assert checking, which I assume you are already doing.
    > 
    > Add this "Assert(heapDescriptor->natts != 0)" to the function, and in
    > lower functions substitute heapDescriptor with the new variable name it
    > took as a function parameter.)
    > 
    > When the assert fails, we can see where it is getting messed up.
    > 
    > 
    > -- 
    > 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)
    > 
    
    I don't know if this helps, but here's what I've done so far.  I'm now on
    a Solaris Box, since the optimization thing seems to be similar to the
    Linux Box.  Its just easier for me to work on the Solaris Box.
    
    When indexing.c is compiled with -O2, I get a core dump. (Big news.)
    The core dump occurs at line 208 of backend/access/common/heaptuple.c.
    at this memmove.    
    
    		{
    			data = (char *) LONGALIGN(data);
    			memmove(data, DatumGetPointer(value[i]),
    				att[i]->attlen);
    			data += att[i]->attlen;
    		}                                    
    
    This consistantly happens when tupleDesc->natts is 1.  When i = 1 on the
    second time on the outer loop, value[1] is something like 2123236.
    This is out of range when it gets derefenced, memmove barfs.
    
    I was backtracking and turning on debugging one file at a time, but got
    lost in fmgr.c.
    
    I'll insert the asserts like you suggested.
    
    Bruce, I can let you on this machine if you like.
    
    Thanks,
    
    Tom
    
    #0  0xef5d0580 in _memcpy ()
    (gdb) bt
    #0  0xef5d0580 in _memcpy ()
    #1  0x297e0 in DataFill (data=0x1a8e0c "", tupleDesc=0x15dce8, value=0xefffccac,
    nulls=0xefffccb0 "", infomask=0xefffc9c6, bit=0x1a8e00 "\003") at heaptuple.c:208
    #2  0x2bf24 in index_formtuple (tupleDescriptor=0x15dce8, value=0xefffccac, null=0xefffccb0 "")
    at indextuple.c:76
    #3  0x3ff40 in btinsert (rel=0x1a8060, datum=0xefffccac, nulls=0xefffccb0 "", ht_ctid=0x1a8858,
    heapRel=0x166a38) at nbtree.c:358
    #4  0xde1bc in fmgr_c (finfo=0xefffcb70, values=0xefffcb80, isNull=0xefffcb6f "") at fmgr.c:115
    #5  0xde7bc in fmgr (procedureId=331) at fmgr.c:286
    #6  0x38c3c in index_insert ()
    #7  0x4d440 in CatalogIndexInsert ()
    #8  0x4a6c4 in AddNewAttributeTuples ()
    #9  0x4a968 in heap_create_with_catalog ()
    #10 0x51b70 in DefineRelation ()
    #11 0xb7884 in ProcessUtility ()
    #12 0xb5da8 in pg_exec_query_dest ()
    #13 0xb5c9c in pg_exec_query ()
    #14 0xb6eb8 in PostgresMain ()
    #15 0x9ef90 in DoBackend ()
    #16 0x9e9dc in BackendStartup ()
    #17 0x9df64 in ServerLoop ()
    #18 0x9dab8 in PostmasterMain ()
    #19 0x722e4 in main ()