Re: "cache reference leak" and "problem in alloc set" warnings

From: Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: "cache reference leak" and "problem in alloc set" warnings
Date: 2006-08-18 14:36:53
Message-ID: 20060818143653.GA1347@alamut
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Aug 17 10:38, Tom Lane wrote:
> Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr> writes:
> > I've still biten by a single "write past chunk" error while returning a
> > record in PL/scheme:
>
> > WARNING: problem in alloc set ExprContext: detected write past chunk
> > end in block 0x84a0598, chunk 0x84a0c84
>
> The actual bug, almost certainly, is that you're miscomputing the space
> needed for a variable-size palloc request. But tracking that down will
> be hard until you find out which chunk it is.

Looks like my palloc() math was correct. Just I had missed special
handling of attnulls array passed to heap_formtuple(). It had should be

attnulls[i] = (isnull) ? 'n' : ' ';

> Do you have a sequence that will make the problem happen consistently at
> the same address? If so, you can use a gdb watchpoint to find out where
> the write-past-end is happening. Or use a conditional breakpoint in
> AllocSetAlloc to try to identify where the chunk is handed out.

Yeah! That's exactly it. After setting a "watchpoint *0x84a0c84", in the
first "where" call, the erronous line is in front of me!

> Another possibility is to set a breakpoint where the warning is emitted
> and take a look at the contents of the chunk to see if you can identify
> it; that wouldn't require knowing the target chunk address in advance.
>
> BTW, if I recall that code correctly, the "chunk address" in the message
> is probably the address of the start of the overhead data for the chunk,
> not the usable-space start address that is passed back by palloc.

Thanks so much for your kindly help. These all mentioned methods are
applicable in a whole software development area. Thanks again.

Regards.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2006-08-18 14:43:14 Re: BF Failure on Bandicoot
Previous Message Tom Lane 2006-08-18 14:16:12 Re: [PATCHES] selecting large result sets in psql using