Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Different perl behavior between V5.10 and V5.14

by markseger (Beadle)
on Apr 01, 2013 at 12:02 UTC ( #1026468=perlquestion: print w/ replies, xml ) Need Help??
markseger has asked for the wisdom of the Perl Monks concerning the following question:

I have no idea if this is perl or ubuntu, as this works find on an Ubuntu/natty distro running perl 5.10 and does not do what I expect on Ubuntu/precise running perl 5.14.

The simple problem statement is I want to tail a file and count various types of entries, writing intermediate counters to a file every second. My solution, which has been running just fine for over a year is to simply set a timer with ularm to wake me every second at which time I write my counters and continue.

To reproduce the behavior, first you create the file xyz and then run the script which I've posted after the results. Then in a different window run the command: "echo test >> xyz" a couple of times.

On natty you see:

alarm alarm test alarm alarm test

In other words it stays inside the loop processing the tail command. But the identical test on precise produces the following, noting which each new line written to the file it breaks out of the inner loop:

alarm alarm alarm test Fell through... alarm alarm test Fell through... alarm alarm

I've been trying a variety of things to get this to do what I want and am out of ideas. Here's the code:

#!/usr/bin/perl -w use Time::HiRes; $SIG{"ALRM"}=\&sigAlarm; my $interval=1; my $uInterval=$interval*10**6; Time::HiRes::ualarm($uInterval, $uInterval); open TAIL, "tail -f xyz|" or die 'couldnt open xyz'; while (1) { while ($line=<TAIL>) { print $line; } print "Fell through...\n"; } sub sigAlarm { print "alarm\n"; }

thoughts?

Update...
Now here's somethign really odd I also just discovered. If I run my second 'echo test' before the second consecutive alarm fires, it doesn't fall through the loop! Look at this, noting I waited a couple of second before doing the fourth echo command:

alarm alarm test Fell through... alarm test <<< stayed in loop alarm test <<< stayed in loop alarm alarm alarm test Fell through... alarm

-mark

Comment on Different perl behavior between V5.10 and V5.14
Select or Download Code
Re: Different perl behavior between V5.10 and V5.14
by vsespb (Hermit) on Apr 01, 2013 at 12:14 UTC
    I can confirm this. Tested on Ubuntu 10.04 and 12.04.
Re: Different perl behavior between V5.10 and V5.14
by Loops (Curate) on Apr 01, 2013 at 12:23 UTC
    Bit of an odd one. As a data point, unable to reproduce the problem here on Fedora 17, with either the system 5.14 perl, or 5.16.
      Since what it currently happening is the code is reading the new record, printing it and then immediately exiting the loop, I inserted an eof() before trying to read the pipe from the pipe and did verify eof() is returning a 1. So I put in some code to call eof() before trying to read and if it returns 1 to simply do a read I know will fail and then follow it with next to stay in the inner loop.

      Seems to work just fine but it doesn't make me happy. Perhaps this might offer a clue to someone else who does know what's going on?

      -mark

        Hm. Weird. I've modified code like this:
        #!/usr/bin/perl -w use Time::HiRes; $SIG{"ALRM"}=\&sigAlarm; my $interval=1; my $uInterval=$interval*10**6; Time::HiRes::ualarm($uInterval, $uInterval); open TAIL, "tail -f xyz|" or die 'couldnt open xyz'; while (1) { while ($line=<TAIL>) { $X = $!; print $line; } if (eof(TAIL)) { print "EOF TAIL!\n"; } print "Fell through... $!\n"; } sub sigAlarm { print "alarm\n"; }
        After first EOF found, it never works normal again. It just prints EOF TAIL + Fell through... in infinite loop. So, I think filehandle never recovered after Perl finds EOF.
Re: Different perl behavior between V5.10 and V5.14
by vsespb (Hermit) on Apr 01, 2013 at 13:35 UTC
    Looks like similar issue http://stackoverflow.com/questions/14756747/perl-how-to-prevent-sigalrm-from-closing-a-pipe
Re: Different perl behavior between V5.10 and V5.14
by vsespb (Hermit) on Apr 01, 2013 at 14:12 UTC

    Well, obviously readline() is not retried when signal arrives (EINTR is set)

    I think this should not happen: perlipc safe signals

    Consequently, restartable system calls can fail (with $! set to EINTR ) in places where they previously would have succeeded. The default :perlio layer retries read, write and close as described above; interrupted wait and waitpid calls will always be retried.

    Also, this perl5140delta might explain difference between 5.10 vs 5.14

    "Safe signals" optimisation Signal dispatch has been moved from the runloop into control ops. This should give a few percent speed increase, and eliminates nearly all the speed penalty caused by the introduction of "safe signals" in 5.8.0. Signals should still be dispatched within the same statement as they were previously. If this does not happen, or if you find it possible to create uninterruptible loops, this is a bug, and reports are encouraged of how to recreate such issues.
      Thanks for the details but I guess I'm not sure I really sure what to do about this, especially since an earlier reply stated this does not happen on fedora and so feels like it could be outside of perl or at least not completely inside of perl.

      From your reference to perl5140delta are you suggesting this IS a perl bug and should be reported?

      -mark

        I am not 100% sure. I would wait couple of days, until maybe some Perl maintainers confirm here that it's a bug or not.
Re: Different perl behavior between V5.10 and V5.14
by dave_the_m (Parson) on Apr 01, 2013 at 20:40 UTC
    It broke in 5.13.8 and was fixed in 5.15.4, so stable releases from 5.16.0 onwards are ok.

    Dave.

      Is this #107216? Why it's not backported to Perl 14? Looks like a serious bug.
        Is this #107216?
        Unlikely: the patch in that ticket is for the POSIX module, and was included in 5.15.7.
        Why it's not backported to Perl 14?
        Because our procedures for backporting fixes are a bit haphazard. Also, the 5.14.x branch is unlikely to have any further releases.

        Dave.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1026468]
Approved by Corion
Front-paged by LanX
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (5)
As of 2014-12-20 23:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (99 votes), past polls