Re: Techniques for isolating bugs in perl

renaming the program

What did you name your program?? Hopefully not something silly like 'test' ...

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Comment on Re: Techniques for isolating bugs in perl

Replies are listed 'Best First'.
Re^2: Techniques for isolating bugs in perl by Ytrew (Pilgrim) on Oct 22, 2004 at 15:43 UTC
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. -- Ytrew	[reply]

Replies are listed 'Best First'.

Re^2: Techniques for isolating bugs in perl
by Ytrew (Pilgrim) on Oct 22, 2004 at 15:43 UTC

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.

--
Ytrew

[reply]