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]

Reply via email to