Re: "cache reference leak" and "problem in alloc set" warnings
От | Volkan YAZICI |
---|---|
Тема | Re: "cache reference leak" and "problem in alloc set" warnings |
Дата | |
Msg-id | 20060818143653.GA1347@alamut обсуждение исходный текст |
Ответ на | Re: "cache reference leak" and "problem in alloc set" warnings (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "cache reference leak" and "problem in alloc set" warnings
|
Список | pgsql-hackers |
On Aug 17 10:38, Tom Lane wrote: > Volkan YAZICI <yazicivo@ttnet.net.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.
В списке pgsql-hackers по дате отправления: