Nicholas Clark wrote:
On Thu, Mar 09, 2006 at 10:01:52AM +0000, Dave Mitchell wrote:
On Tue, Mar 07, 2006 at 10:50:45PM -0500, John E. Malmberg wrote:
In util.c the routines Perl_safesysmalloc and friends are updating a
linked list.
There does not seem to be any protection from a different thread also
updating the same linked list at the same time, especially on a
multi-processor system.
They are updating a per-thread linked list, so I think it's thread-safe.
Yes, I just realized that this morning as I was thinking about the
issue. From the way that the macros are hiding that, it is not
immediately obvious though.
Which is what I was thinking but I hadn't replied yet. The other bit I
was thinking was "unless things have got very buggy" but I'm not sure how
many defences one puts in against the sky falling.
Apparently that type of bug was present in vms/vms.c and is easy to code
in because of the slight differences in the *spawn() and *exec() wrappers.
The routines in pp_sys.c that call do_spawn and do_aspawn on OpenVMS
always deallocate PL_Cmd after the call.
One of the things addressed in the last patch to vms/vms.c submitted but
not called out in my description is that do_aspawn allocates PL_Cmd, and
do_spawn never allocated PL_Cmd, so calling do_spawn in vms/vms.c would
result in PL_Cmd attempted to be deallocated when it was not allocated.
Because the interpreter field was not cleared, that bug was not detected
at the time Perl_safesyssfree() was called, and the link list ended up
being corrupted. It was not until a later unrelated Perl_safesysfree()
was called that the the problem was detected.
That is why I would like that field poisoned. Poisoning the prev and
next pointers might work better though because then when looking at a
corruption issue, you could see what thread last allocated a freed
memory block.
-John
[EMAIL PROTECTED]
Personal Opinion Only
