Front page | perl.perl5.porters |
Postings from April 2003
Re: DProf bug report: infinite loop at startup
Thread Previous
From:
Slaven Rezic
Date:
April 16, 2003 12:11
Subject:
Re: DProf bug report: infinite loop at startup
Message ID:
87brz6v3t8.fsf@vran.herceg.de
msb@vex.net (Mark Brader) writes:
> 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.
Can you try the same with perl-5.8.1-to-be? As far as I know, there
were some serious performance problems using the -d switch with
perl-5.8.0, which should be solved now.
Regards,
Slaven
--
Slaven Rezic - slaven@rezic.de
tknotes - A knotes clone, written in Perl/Tk.
http://ptktools.sourceforge.net/#tknotes
Thread Previous