Schwern writes "Chip Turner, maintainer for Red Hat's Perl distribution, has just announced that an official RPM for perl 5.6.1 is finally available! Previously Red Hat only shipped perl 5.6.0. The relevent Red Hat Errata is found
here. Just in time for 5.8.0.
Re:Strange goings-on on RedHat 7.2
djberg96 on 2002-03-06T14:32:10
Interesting. I looked at your sample code. Have you tried stepping this through the debugger? My guess is that there's a warning generated on that line.Put a permanent watch on $! and $@ and see if anything happens. Perhaps wrap it in an 'eval' as well. Please let me know what happens - we're running on RH 7.2 here as well for some machines.
Re:Strange goings-on on RedHat 7.2
barryp on 2002-03-06T14:54:51
Wow! That was a fast response!Thanks for the suggestions. I will do what you suggest.
Actually I'm pretty sure the assignment to the '$from_who' variable (as a result from the 'recv' call) is redundant. As I'm using TCP, the connection is already established, so it makes no sense to ask 'recv' to identify the other end of the connection, as the call to 'accept' has aready done this. It does make sense when using UDP, however. Thanks again.
Re:Strange ... (response to your suggestions)
barryp on 2002-03-06T17:11:27
To my undying shame, I had to read 'man perldebug' to remind myself how to use the debugger... Now, wrapping the code within an 'eval' had no effect - it still died with the same error message. Note - surprisingly - that the code that contained the 'eval' died, not the evaled code (which was very strange and unexpected). The program was killed by RedHat!
:-) I then ran the original code through the debugger, with watches on $@ and $!, as you suggested. The code died again with the same message, with the debugger reporting "Debugged Program Terminated". Just prior to the programs death, the debugger printed 'Illegal Seek' three times for the $@ variable. Note, too, that the original code was run as 'perl -w' by default, and that it compiled cleanly (with 'perl -c').
So, the mystery remains: how come this code works on most platforms other than RedHat 7.2? Emmm
.... Whatever the answer is, removing the assignment to the '$from_who' variable fixes things.
Re:Strange ... (response to your suggestions)
djberg96 on 2002-03-06T19:00:07
Ah, yes. Ye 'ol "Illegal Seek" warnings. That and "Bad File Descriptor" are my favorite warnings, especially since no one in clpm can ever explain them and there's no way to step into core functions.My *guess* is that there's some difference in socket.h on RH 7.2 that's causing that problem. If you're feeling particularly frisky, you could look into it.
:) Re:Strange ... (response to your suggestions)
barryp on 2002-03-07T09:56:34
Curious I may be, frisky I'm not.;-) Actually, I'm exchanging e-mails with Chip Turner in an attempt to "resolve" the issue. I'll report back to this 'thread' if anything comes of this.
Re:Chip Turner Gets To The Bottom Of Things
barryp on 2002-03-07T21:38:03
Chip Turner at RedHat has tracked down the problem. As was suspected, my code incorrectly assigned the result from recv to the $from_who variable. Here's the contents of the e-mail from Chip:Hey Paul,
I've traced down the problem. recvfrom isn't required by the UNIX98 spec to populate the from fields for connection-oriented sockets (in this case, TCP). I've confirmed that this is standard behavior in the default Linux 2.4 kernel.
The man page for recvfrom (which is what Perl's recv ends up using, as can be seen from strace) states:
If from is not NULL, and the socket is not connection-oriented, the source address of the message is filled in. The argument fromlen is a value-result parameter, initialized to the size of the buffer associated with from, and modified on return to indicate the actual size of the address stored there.
So
... it's a change from the 2.2 kernel to the 2.4 kernel, and is within UNIX98 specifications (and documented in the man page). From a Perl perspective, just don't use the return value of recv when not using a connection-oriented socket (TCP, UNIX domain socket, etc). Chip.
And here's my reply (I believe this is called 'eating some crow' in North America):
Thanks for this. Great to have the issue resolved.
I need to be more careful. I'd written a client/server pair using UDP, then re-written it to use TCP (and, being lazy, copied/pasted from the UDP code into the TCP programs). That assignment as a result of the call to recv should never have stayed in the TCP code. I'll pay more attention to these details in future.
Thanks for taking the time to devote to this problem. I very much appreciate it.
It's a case of RTFM for me.
Illegal Seek
pne on 2002-03-07T16:10:46
IIRC, "illegal seek" sometimes comes from checking $! when you have no business doing so (that is, when the operation you just completed did not signal an error, such as through its return code).
ISTR reading something about how the stdio innards do some trickery to find out whether a file descriptor is connected to a TTY or something, and that this can result in the errno getting set to "illegal seek" -- but that this "error" is expected in that context and is therefore not passed on as an error return value from whatever routine you called.
Don't know whether that applies to you here, but still: only check $! if you know that an error occurred (even setting it to zero beforehand won't guarantee that it will be zero after a successful system call).
I love RedHat 7.[12]. In fact, my response after a day of using RedHat 7.1 was, "I'm getting rid of my Macintosh." The system is well integrated, pleasant to use, and had all the software anyone else in my family might want.
That said, I never use the system Perl on any machine. If there's a Perl that came with the OS in
I have found installing modules with a vendor supplied Perl is often difficult, although I think the situation has gotten better. I would never want to be in a situation where I decided to upgrade
So I'm thrilled RedHat upgraded, because that means I can trust any Perl programs they include more, but it won't affect my daily work as much as one might expect.
To us on the fasttrack (those who install versions like 5.7.3 and 5.8.0-rc1), RedHat seems light-years behind. However, it takes time to do real integration testing to verify that everything else included with RedHat and based on Perl still works with the new version. Sure, we're convinced it does, but the corporate world wants it tested, and I'd hate to have one mistake leave people who only see RedHat's packages saying, "Perl has bugs." That integration testing it what makes RedHat better than doing it yourself, at least for some purposes. So, a commercial distro can always be expected to lag behind, sometimes dramatically, not just with Perl but also with the kernel, python, and what-have-you.
When did Debian upgrade to 5.6.1? I'm thinking it was actually quite recently.
Re:I never use the system Perl
schwern on 2002-03-06T22:44:27
> When did Debian upgrade to 5.6.1? I'm thinking it was actually quite recently.
"Depends":)
Debian is actually four concurrent distributions: security, stable, testing and unstable. Each distribution is a tradeoff between stablity and up-to-dateness. Packages flow from unstable to testing and down to stable.
Perl 5.6.1 entered Debian unstable on May 21st, 2001. If I recall correctly it went into the testing distribution shortly after that and has been there since. It has yet to reach stable (which is still using 5.005_03 I think).
Debian's idea of "stable" is a little different than other distributions. When they say stable, the mean stable. Because it revs so slowly, most people use the testing distribution which means its already been through a good deal of QA. Because Debian is so easy to seemlessly upgrade, and because there's a choice of distributions, there's little pressure to prematurely put anything into stable.Re:I never use the system Perl
m2 on 2002-03-11T10:02:47
Debian is actually four concurrent distributions: security, stable, testing and unstable.Security isn't a distribution actually. If you must, call it a component of stable. Security upgrades are included in proposed-updates which get folded into stable every now and then.
Perl 5.6.1 will be included in stable when Debian 3.0 (woody) releases. With some luck that will be sometime this millenium, and with truckloads of luck even before 5.8.0 sees the light of day.
Re:I never use the system Perl
jeppe on 2002-03-07T18:52:51
If you're brave, you can go through the modules that came with the distribution. Get those for your 5.6.1 installation in/usr/local. Then, in a piece of bold genious,
mv/usr/bin/perl /usr/bin/perl.junk ln -s /usr/local/bin/perl /usr/bin/perl
If the Gods smile upon thee, you might find yourself with a gorgeous new 5.6.1 system.
However, I doubt that'll work in the highly integrated modern distributions. Never know, tho. Shouldn't be unbootable if I'm wrong. A simple
rm/usr/bin/perl mv /usr/bin/perl.junk /usr/bin/perl
and you're back to your known problems if this should fsck up your box.
