From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | emkxp01(at)mtcc(dot)demon(dot)co(dot)uk |
Cc: | emkxp01(at)mtcc(dot)demon(dot)co(dot)uk, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Core dump in regression tests.u |
Date: | 1998-09-01 21:41:13 |
Message-ID: | 199809012141.RAA02305@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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(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)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-09-02 01:32:33 | Re: [HACKERS] Core dump in regression tests. |
Previous Message | Keith Parks | 1998-09-01 21:20:31 | Re: [HACKERS] Core dump in regression tests.u |