Re: random crashes on -HEAD for a few days now - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject Re: random crashes on -HEAD for a few days now
Date
Msg-id 46C9A2DE.6040603@kaltenbrunner.cc
Whole thread Raw
In response to Re: random crashes on -HEAD for a few days now  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: random crashes on -HEAD for a few days now  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> at least one of my buildfarm members (emu) is crashing on what seems 
>> totally unrelated regression tests for a few days now:
> 
> I was wondering about that ...
> 
>> it took me about 10 tries to reproduce that manually and I'm getting the 
>> following stacktrace:
> 
>> #0  varbit_out (fcinfo=0x88c75000) at varbit.c:549
>> 549             x = *sp;
> 
> Just eyeballing that code, it looks like it will try to fetch the byte
> immediately beyond the end of the bit array, when the number of bits is
> an exact multiple of 8.  This is unlikely to cause a problem but it
> *could* happen that the input is right up against the end of memory.
> Could you check whether that is what happened here?  (The important
> question is whether the input seems to be sane, ie, "len" isn't huge.)

"end of memory" sounds familiar to:

http://archives.postgresql.org/pgsql-hackers/2005-06/msg00819.php

which is how emu is (still) set up.

as for len it seems to be 0:

#0  varbit_out (fcinfo=0x88c75000) at varbit.c:549        s = (VarBit *) 0x88c75000        result = 0x84d33128 ""
r = 0x84d33128 ""        sp = (bits8 *) 0x88c75000 <Address 0x88c75000 out of bounds>        x = 0 '\0'        i = 0
   k = 0        len = 0
 


Stefan


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why NESTED LOOP Not Allowed for FULL and RIGHT Join.
Next
From: Lodewijk Vöge
Date:
Subject: Re: INSERT/SELECT and excessive foreign key checks