Re: [HACKERS] Core dump in regression tests.

In message <199809010623(dot)CAA00709(at)candle(dot)pha(dot)pa(dot)us>, Bruce Momjian writes:
> > 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.
>
> 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(at)candle(dot)pha(dot)pa(dot)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 ()