Just another Perl shrine | |
PerlMonks |
Re^2: Techniques for isolating bugs in perlby Ytrew (Pilgrim) |
on Oct 22, 2004 at 15:43 UTC ( [id://401533]=note: print w/replies, xml ) | Need Help?? |
No, I didn't call it "test". I had actually whimsically renamed the file to "I_create_a_coredump.t", only to realize that it was just sheer luck that the bug didn't vanish I actually ended up writing a tiny little shell script that systematically re-ran perl on the file, and checked the exit status. If it was 0 (no bug found), it renamed the file, and tried again. I was of the opinion that only the filename length was significant, so I started with a filename of "a", then "aa", then "aaa", and so on. This showed me that the filename length was significant, and the bug didn't manifest until I had a filename of length 16. This seemed like a "magic number", and I was momentarially interested, until I noticed that a filename of length 21 also triggered the bug. I put it down to a co-incidence, or at least, of little value in isolating where things went wrong. Later, I tried running "tusc", and of course, by changing the command line, it failed to coredump for me. So I ran my "change filename" script, and added "tusc" to the command it runs. I was fortunate, and after a while, my script happened upon a filename that coredumped again. :-) Reading through the output from tusc, I tracked down the difference in the system calls between a working and a coredumping version of the program to a brk() system call at the end of the working program, versus a segmentation fault in the other program. My guess is that perl's memory (de?)allocation failed somehow. My boss has told me to stop debugging this obscure flaw in perl (or possibly, in our XS code), and go on with the unit tests that the program is actually supposed to do. I'm off to meet deadlines, so that's where this ends, I guess. :-( Thanks to everyone for their suggestions and comments.
--
In Section
Seekers of Perl Wisdom
|
|