On Wed, 21 Jan 2004 16:28:45 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
>Steve Hay wrote: >[...] >BTW, if you've read my request to p5p, I don't think the perl_destruct traces >(on the infamous error) are of any good use. Since they just tell that there >is a problem, but they don't say where. winFU-perl needs to spot the problem >when it's created and not when the perl exits. So as you could see from my >last patch, restoring the context fixes some things. So ideally i want >winFU-perl pin-point that place in the code where the context was wrong. It is really hard to detect where the problem is created: whenever you store a pointer to some memory you may be creating an invalid cross-link between 2 interpreters. This can be anything, from allocating a new SV for an RV, allocating or growing a PVX or changing magic attached to an SV. There are an awful lot of places in sv.c alone that store memory pointers in structures. Each of them can be the culprit if called in the wrong context. In general, the code in threads::shared is especially suspect because it has to deal with marshaling data from one interpreter to the other. It is very important to always use the correct context, as even innocent looking code like SvPV_nolen(sv) called in the wrong context can result in the PVX being allocated from the wrong pool. Sorry, I have no good suggestion how to deal with this problem beyond looking at what the "freed" memory block contains. Cheers, -Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]