There are tools (eg purify) which attempt to detect and locate this kind of bug in an automated way. The tools are far from perfect, but they are better than nothing. I would strongly recommend getting someone who is knowledgeable about how to use them to study the XS modules to see if any bugs of this kind can be located and fixed. (I suggest focussing on XS modules because perl is more complex, and people have looked for this kind of problem in it so it is less likely to have this kind of bug than random libraries. Plus studying the modules with these tools will likely find several other bugs that you'll be glad to fix.)
If the automated solution fails, you could try a manual audit of the XS code. That is a little hit or miss because where the bug shows up is not going to be anywhere near where the bug is. If you can figure out what address is getting corrupted (sorry, I don't have good ideas for how you would do this except by staring at the stack backtrace, guessing and being lucky), you might be able to trace the running program and try to figure out when it gets messed up. This could simplify the audit.
Good luck. Incidentally the difficulty of attempting to track this kind of bug down is a very good argument against using C except when you absolutely have to. Alternately if you do use C, it is a good argument for using all of the techniques that you can to track down this kind of bug.
In reply to Re^3: Techniques for isolating bugs in perl
by tilly
in thread Techniques for isolating bugs in perl
by Ytrew
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |