Re^2: Techniques for isolating bugs in perl

Running gdb (or adb, the HP/UX version) on the core file just gives me a back trace with no real information, other than the fact that segmentation fault caused the error. I already knew that. :-(

We don't have Devel::Trace installed, but I suspect it would just make the bug go into hiding again: adding the "-s" flag makes the bug go away.

By running a shell script, I determined that the minimum name that the program needed to be named to trigger the bug was 16 characters long. The bug only manifests itself when run from a certain directory, as well. Perhaps something involving a minimum path size is affecting it.

Certain changes to whitespace don't make the bug go away; others do. Reducing the size of certain comments can trigger/hide the bug.

This bug is very confusing: changes to comments affect it, suggesting that there is a problem with how the code gets parsed, yet it runs until the end of the program before dumping core.

--Ytrew

Comment on Re^2: Techniques for isolating bugs in perl

Replies are listed 'Best First'.
Re^3: Techniques for isolating bugs in perl by tilly (Archbishop) on Oct 22, 2004 at 00:19 UTC
If changes to comments affect the bug, then that is strongly suggestive that the problem is due to C-level code writing somewhere random that it shouldn't. That could be a bug in Perl. That could be a bug in C code in the XS library. Unfortunately for you, any change in how Perl lays out its data will move the bug around (and if the data overwritten is purely informational, you won't see it - until the program changes again). 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.	[reply]

Replies are listed 'Best First'.

Re^3: Techniques for isolating bugs in perl
by tilly (Archbishop) on Oct 22, 2004 at 00:19 UTC

any

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.

[reply]