DProf bug report: infinite loop at startup

I'm reporting a problem expereinced with DProf.  The documentation I have
says to email the perl5-porters list, so that's what I'm doing -- I hope
it's still the right destination, as this is necessarily a somewhat verbose
bug report.


On my work computer (not the one I'm sending this message from), I'm running
Red Hat Linux 7.2 with, I believe, kernel 2.4.18-5.  And I have "perl, v5.8.0
built for i686-linux-thread-multi" installed.

Yesterday I was in a directory containing two files:

$ ls -l
total 852
-r--r--r--    1 msb      msb        408583 Apr  9 13:32 G.pdf.xil
-r--r--r--    1 msb      msb        451166 Apr  9 13:31 japan35.ps.xil

and I typed this command into a shell (bash pretending to be sh):

$ for i in *.xil
... do
... j=`basename $i .xil`                  
... time perl -d:DProf `which dsip2.pl` $i
... mv tmon.out tmon.out.$j
... time dprofpp -u -O 50 tmon.out.$j >top50.$j
... done; ls -lS; lpr top50*

and then left for the day.

(The above is moused directly from the screen, except that I have replaced
my $PS1 and $PS2, which are made of colored spaces, with $ and ... for the
sake of readability.)

The above should have taken about 4 hours to complete.  When I got back
the next day, it was still running.

The first perl invocation should have expanded to:

    time perl -d:DProf /home/xxxx/xxx/xxxx/xxxx/bin/dsip2.pl G.pdf.xil

(where I have x'd out part of the pathname for security reasons), and by
running "ps" in another window, I confirmed that it had.  This process
should have taken about 20 minutes to run; it had now been running for
more than 20 CPU-hours....

According to "top", the process was using only a little over 4 megabytes
of memory.  See for yourself (moused from the window where I ran it):

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
30172 msb       25   0  4160 4160  1328 R    99.8  0.8  1224m perl


Here is the critical thing: a tmon.out file had been created, but the
file was only 9 lines long and not growing!  The file contained:

|   #fOrTyTwO
|   $hz=100;
|   $XS_VERSION='DProf 20000000.00_01';
|   # All values are given in HZ
|   $over_utime=4; $over_stime=0; $over_rtime=4;
|   $over_tests=10000;
|                                                                                                                                                                                                                                                   
|   
|   PART2

(I have prefixed each line with "|    " for readability.)

Also, the program had not produced any of the output files that it
normally would if not being debugged, similarly suggesting that it
had never really gotten started.


I tried sending the perl process various signals and nothing seemed to
happen.  (The program uses "confess" and I was hoping for a traceback.)
A co-worker than suggested connecting to it with strace, but this gave
a segmentation fault.

I now killed the perl process (using signal 9) and the for-loop that
I had typed the day before then iterated and started the dsip2.pl program
on the second input file, as it should have.  This ran correctly and took
the expected time.  I then moved the output files to a safe place (using
another window) and then typed !! (in the original window) to repeat the
for-loop.

This time the program started up as expected, producing the expected
tmon.out file correspoding to input file G.pdf.xil.


I haven't used DProf very much, but have never seen perl exhibit this
sort of behavior when I was not running DProf.  I concluded that there
is some sort of random behavior, such as a race condition, that can
affect DPRof in my environemnt and cause it to go into an infinite
loop at startup.  I presume it is a relatively rare problem or else it
would have been fixed already, but I have no idea how rare it might be,
since I haven't used DProf very much.

I know this isn't much to go on.  If anyone wants to suggest something
to try by way of further diagnosis if it happens again, I will try it.
On the other hand, if this is a known bug, and especially if it has
been fixed already, it would be good to hear about a patch.
-- 
Mark Brader                 "When a supposedly indivisible transaction
Toronto                      fails to complete properly, this is known
msb@vex.net                  as an atomic bomb."   -- Peter Neumann

• DProf bug report: infinite loop at startup by msb
• Re: DProf bug report: infinite loop at startup by Slaven Rezic