On Aug 17 10:38, Tom Lane wrote:
> Volkan YAZICI <[EMAIL PROTECTED]> 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.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
