Thread: 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:-

boolean .. failed
char .. failed
name .. failed
varchar .. failed
text .. failed
strings .. failed
int2 .. failed
int4 .. failed
int8 .. failed
oid .. failed
float4 .. failed
float8 .. failed
numerology .. failed
point .. failed
lseg .. failed
box .. failed
path .. failed
polygon .. failed
circle .. failed
geometry .. failed
timespan .. failed
datetime .. failed
reltime .. failed
abstime .. failed
tinterval .. failed
horology .. failed
comments .. ok
create_function_1 .. ok        <- ******
create_type .. failed
create_table .. failed
create_function_2 .. failed
constraints .. failed
triggers .. failed
copy .. failed
create_misc .. failed
create_aggregate .. ok
create_operator .. failed
create_view .. failed
create_index .. failed
sanity_check .. failed
errors .. failed
select .. failed
select_into .. failed
select_distinct .. failed
select_distinct_on .. failed
select_implicit .. failed
select_having .. failed
subselect .. failed
union .. failed
aggregates .. failed
transactions .. failed
random .. failed
portals .. failed
misc .. failed
arrays .. failed
btree_index .. failed
hash_index .. failed
select_views .. failed
alter_table .. failed
portals_p2 .. failed
setup_ruletest .. failed
run_ruletest .. failed

***** So with -O2, one of the few tests that fail with -O0 succeeds!!

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