develooper Front page | perl.perl5.porters | Postings from April 2003

DProf bug report: infinite loop at startup

Thread Next
April 11, 2003 01:41
DProf bug report: infinite loop at startup
Message ID:

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

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` $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/ 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):

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 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

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                  as an atomic bomb."   -- Peter Neumann

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About