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.


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

Reply via email to