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

> Bruce Momjian <maillist@candle.pha.pa.us>
>
> >
> > > (gdb) print attrNums[attOff]
> > > $3 = 15
> > > (gdb) print *hTupDesc
> > > $5 = {natts = 0, attrs = 0x0, constr = 0x0}
> > > (gdb) print fInfo
> > > $6 = (FuncIndexInfo *) 0x0
> > >
> >
> > I believe this is the pg_proc.prosrc index.  This is the only case of a
> > system index/cache on a 'text' field, rather than 'name'.  'text' is
> > variable length, unlike the other fields.  I wonder if there is some
> > problem with the cache code on this type of index.  In 6.3.2, it was
> > there but never used, so it may have been broken all along.  This is
> > just a guess, though.
> >
>
> I've just cvs updated and built with -O2 and assert checking.
>
> The automated process actually runs the regression tests at the
> end and gives the following results:-

I just worked with Thomas A. Szybist and telnet'ed into his
Solaris/Sparc machine.  We worked through gdb, and found the system
shifting the array values in idesc on the fifth call
to CatalogIndexInsert() while creating a table.  The last time through
the for() loop, idesc[2] is null and idesc[1] equals the old value of
idesc[2].



Because recompiling indexing.c with no optimization fixes the problem,
and because gdb is showing idesc[i] getting modified by the for() loop,
I am concluding we have some sort of Sparc gcc optimizer problem.  This
code is only slightly modified from the 6.3.2 version, but perhaps
enough to cause the optimizer to get confused.

I tried adding some code to make things clearer for the optimizer but
did not have any luck.

He is going to continue researching the crashes, and perhaps try a newer
gcc.

--
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)