Front page | perl.vmsperl |
Postings from March 2006
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 wb8tyw@qsl.net Personal Opinion OnlyThread Previous