incorrect errno/perror with IO::socket->new
in [Perl]
|
Prev: Close function blocks forever when reading from piped output
Next: Perldoc error: "Could not create temp file"
From: brandon on 17 Jan 2008 00:36 On Jan 16, 10:27 pm, Uri Guttman <u...(a)stemsystems.com> wrote: > >>>>> "b" == brandon <brandon.mayfi...(a)att.net> writes: > > b> I really did get you the first time :-) I was thinking that perhaps > b> the errno was NOT getting set in Socket->new() from it's system calls > b> (I am kinda just assuming that $! returns the current value of errno > b> or perror depending on the context), and I wanted to see if $! was > b> different before and after the call. > > but where did you get the totally misguided idea that $! has anything to > do with the results of the io::socket call? where in the docs is that? > what source led you to think that? $! is defined for system calls. you > don't care about individual system calls in a module as it may call MANY > system calls and even handle those errors. modules will not clear or > reset $! so you get bogus info. > No I am expecting that Socket->new() is making system calls and if they fail I can retrieve the error with $!. If not, then there is not a way for me to tell exactly why the call failed. I am left only with an undef $socket. The writers of Socket should be (and apparently are) either returning immediately on a filed system call, or if others need to be made to clean up then saving it and restoring it after all clean up system calls are finished. That does seem to be what they are doing an it is not unreasonable to expect. > b> If it was not changed from before the call it might mean nothing set > b> an error code during the call or it might mean there is a bug > b> somewhere if Perl (read IO::Socket::INET) is saving errno off > b> temporarily while it does some other system calls after the first > b> failure (for instance maybe it needs to make other system calls to > b> clean up). > > who cares if it was changed? it has no relationship to the io::socket > call. why do you keep checking it? I have to disagree with that. It is set, and correctly apparently. > > b> Or if was changed from before the call then at least I know something > b> in the call really did change it and it was not just that value to > b> begin with. This is the case I had, it was I guess 'undef' before the > b> call and something else after, turns out it may be valid (though if it > b> is it doesn't seem consistent across platforms) after all. > > no, it could be random noise from a cosmic ray changing it. there is no > informational value in $! after an io::socket call. stop even thinking > the name of $!. > > b> That wasn't really what I was having trouble with, it was the $! > b> after the Socket->new(). Based on your next post I did find out some > b> more, so thanks very much for all your comments. > > i tell you to not look at $! and you keep saying you have trouble with > it. i give up. > > uri > > -- > Uri Guttman ------ u...(a)stemsystems.com -------- http://www.sysarch.com-- > ----- Perl Architecture, Development, Training, Support, Code Review ------ > ----------- Search or Offer Perl Jobs -----http://jobs.perl.org --------- > --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com---------
From: Uri Guttman on 17 Jan 2008 01:01 >>>>> "b" == brandon <brandon.mayfield(a)att.net> writes: b> On Jan 16, 10:27�pm, Uri Guttman <u...(a)stemsystems.com> wrote: >> >>>>> "b" == brandon �<brandon.mayfi...(a)att.net> writes: >> >> � b> �I really did get you the first time :-) I was thinking that perhaps >> � b> the errno was NOT getting set in Socket->new() from it's system calls >> � b> (I am kinda just assuming that $! returns the current value of errno >> � b> or perror depending on the context), and I wanted to see if $! was >> � b> different before and after the call. >> >> but where did you get the totally misguided idea that $! has anything to >> do with the results of the io::socket call? where in the docs is that? >> what source led you to think that? $! is defined for system calls. you >> don't care about individual system calls in a module as it may call MANY >> system calls and even handle those errors. modules will not clear or >> reset $! so you get bogus info. >> b> No I am expecting that Socket->new() is making system calls and if b> they fail I can retrieve the error with $!. If not, then there is not b> a way for me to tell exactly why the call failed. b> I am left only with an undef $socket. b> The writers of Socket should be (and apparently are) either returning b> immediately on a filed system call, or if others need to be made to b> clean up then saving it and restoring it after all clean up system b> calls are finished. That does seem to be what they are doing an it is b> not unreasonable to expect. then write your own module. i did. otherwise expect nothing more than what the docs offer. your expectations are wrong, useless and leading you into a brick wall. enjoy. >> � b> �If it was not changed from before the call it might mean nothing set >> � b> an error code during the call or it might mean there is a bug >> � b> somewhere if Perl (read IO::Socket::INET) is saving errno off >> � b> temporarily while it does some other system calls after the first >> � b> failure (for instance maybe it needs to make other system calls to >> � b> clean up). >> >> who cares if it was changed? it has no relationship to the io::socket >> call. why do you keep checking it? b> I have to disagree with that. It is set, and correctly apparently. but who cares?? your connection failed. $@ tells you why. why the hell check $!??? it could be anything inside the module and it could be something that does not matter. yet you give it credence. this is on your head and not the module. bang your head away. enjoy. uri -- Uri Guttman ------ uri(a)stemsystems.com -------- http://www.sysarch.com -- ----- Perl Architecture, Development, Training, Support, Code Review ------ ----------- Search or Offer Perl Jobs ----- http://jobs.perl.org --------- --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
From: Ilya Zakharevich on 17 Jan 2008 02:38 [A complimentary Cc of this posting was sent to Uri Guttman <uri(a)stemsystems.com>], who wrote in article <x7d4s1w4v1.fsf(a)mail.sysarch.com>: > do you understand me now?? a) there is no reason to yell; b) your arguments are, IMO, wrong. In a perfect world, your argument that `$@ should contain all the information one needs' would be right. In a perfect world, presetting these variables to FALSE would not be needed. In a perfect world, one would not need to check $!. However, as the OP had shown, the world he lives in is not perfect. Somethign fishy is happening. So it is very logical, very polite, and very helpful (*) that he is setting $!, $@ to FALSE, and is the value of reporting $! to us. (*) Well, not helpful enough for me to solve his problem (sorry!), but helpful in avoiding unneeded assumptions and questions. Hope this helps, Ilya
From: Uri Guttman on 17 Jan 2008 04:04 >>>>> "IZ" == Ilya Zakharevich <nospam-abuse(a)ilyaz.org> writes: IZ> [A complimentary Cc of this posting was sent to IZ> Uri Guttman IZ> <uri(a)stemsystems.com>], who wrote in article <x7d4s1w4v1.fsf(a)mail.sysarch.com>: >> do you understand me now?? IZ> a) there is no reason to yell; there is a reason when the OP keeps banging his head on the wall and won't listen. IZ> b) your arguments are, IMO, wrong. and i disagree. but you are always right so i won't argue with you. it is a waste of time. IZ> In a perfect world, your argument that `$@ should contain all the IZ> information one needs' would be right. In a perfect world, presetting IZ> these variables to FALSE would not be needed. In a perfect world, IZ> one would not need to check $!. and the module code can be patched in the imperfect world. or you can write your own which i did. no problems with any error handling then. IZ> However, as the OP had shown, the world he lives in is not perfect. IZ> Somethign fishy is happening. So it is very logical, very polite, and IZ> very helpful (*) that he is setting $!, $@ to FALSE, and is the value IZ> of reporting $! to us. nope, i did the same things and got a clean error message from $@. $! is useless as it could be from some system call that failed but was handled by the module. LWP does retries and such so $! may get set along the way to a perfectly fine page fetch. if the module doesn't specify it will use $! then looking at it is dumb. IZ> (*) Well, not helpful enough for me to solve his problem (sorry!), IZ> but helpful in avoiding unneeded assumptions and questions. well, you didn't help either. so why argue about it. io::socket works fine for everyone but the OP. i lay the blame on the obvious location. uri -- Uri Guttman ------ uri(a)stemsystems.com -------- http://www.sysarch.com -- ----- Perl Architecture, Development, Training, Support, Code Review ------ ----------- Search or Offer Perl Jobs ----- http://jobs.perl.org --------- --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
From: brandon on 17 Jan 2008 09:22
On Jan 17, 2:04 am, Uri Guttman <u...(a)stemsystems.com> wrote: > >>>>> "IZ" == Ilya Zakharevich <nospam-ab...(a)ilyaz.org> writes: > > IZ> [A complimentary Cc of this posting was sent to > IZ> Uri Guttman > IZ> <u...(a)stemsystems.com>], who wrote in article <x7d4s1w4v1....(a)mail..sysarch.com>: > >> do you understand me now?? > > IZ> a) there is no reason to yell; > > there is a reason when the OP keeps banging his head on the wall and > won't listen. > > IZ> b) your arguments are, IMO, wrong. > > and i disagree. but you are always right so i won't argue with you. it > is a waste of time. > > IZ> In a perfect world, your argument that `$@ should contain all the > IZ> information one needs' would be right. In a perfect world, presetting > IZ> these variables to FALSE would not be needed. In a perfect world, > IZ> one would not need to check $!. > > and the module code can be patched in the imperfect world. or you can > write your own which i did. no problems with any error handling then. > > IZ> However, as the OP had shown, the world he lives in is not perfect.. > IZ> Somethign fishy is happening. So it is very logical, very polite, and > IZ> very helpful (*) that he is setting $!, $@ to FALSE, and is the value > IZ> of reporting $! to us. > The only thing I have been able to find close to a mention of how to determine why one's use of IO::Socket might be failing is from $@, and that only in an example. So I am using $@ now ok? After you mentioned this I started printing both. > nope, i did the same things and got a clean error message from $@. $! is > useless as it could be from some system call that failed but was handled > by the module. LWP does retries and such so $! may get set along the way > to a perfectly fine page fetch. if the module doesn't specify it will > use $! then looking at it is dumb. > Not exactly, you did not try passing Timeout. You helped point me to what the problem is though, it's the original problem I am really having $! or $@ aside. This may make it more clear : ---------- A Sun example : ----------- 1) First with a port on which there is no process listening : # uname -s SunOS # perl -MIO::Socket -e '$s = IO::Socket::INET->new(PeerAddr => "172.16.18.96", PeerPort => "10" ); print "$@\n" unless $s' IO::Socket::INET: connect: Connection refused # perl -MIO::Socket -e '$s = IO::Socket::INET->new(PeerAddr => "172.16.18.96", PeerPort => "10", Timeout => "5"); print "$@\n" unless $s' IO::Socket::INET: connect: Connection refused # In both cases I get "connect: Connection refused", even though I am passing a Timeout 2) Now a host that does not exist on the subnet and will timeout # time perl -MIO::Socket -e '$s = IO::Socket::INET->new(PeerAddr => "172.16.18.200", PeerPort => "10" ); print "$@\n" unless $s' IO::Socket::INET: connect: Connection timed out real 3m45.01s user 0m0.27s sys 0m0.04s # set -o vi # time perl -MIO::Socket -e '$s = IO::Socket::INET->new(PeerAddr => "172.16.18.200", PeerPort => "10" , Timeout => "5"); print "$@\n" unless $s' < IO::Socket::INET: connect: timeout real 0m5.35s user 0m0.29s sys 0m0.05s # The message from $@ in the second case is set in IO::Socket and is not the same as the first which is the text context of $!, the system perror set in the _error() subroutine from the system call to connect. But note that the timeout I've passed caused the call to be abandoned after 5 seconds. ------------- An AIX example : ------------ 1) Same thing as above, a port on which there is no process listening : # uname -srv AIX 3 5 # perl -MIO::Socket -e '$s = IO::Socket::INET->new(PeerAddr => "172.16.18.96", PeerPort => "10" ); print "$@\n" unless $s' IO::Socket::INET: connect: A remote host refused an attempted connect operation. # perl -MIO::Socket -e '$s = IO::Socket::INET->new(PeerAddr => "172.16.18.96", PeerPort => "10", Timeout => "5"); print "$@\n" unless $s' IO::Socket::INET: connect: A system call received a parameter that is not valid. # In the two cases above it looks to me like passing a Timeout is causeing some heartache to the AIX build of Perl - same thing on HP. 2) And again, a host that does not exist on the subnet and will timeout the connect # time perl -MIO::Socket -e '$s = IO::Socket::INET->new(PeerAddr => "172.16.18.200", PeerPort => "10" ); print "$@\n" unless $s' IO::Socket::INET: connect: A remote host did not respond within the timeout period. real 1m14.80s user 0m0.04s sys 0m0.02s # time perl -MIO::Socket -e '$s = IO::Socket::INET->new(PeerAddr => "172.16.18.200", PeerPort => "10" , Timeout => "5"); print "$@\n" unless $s' IO::Socket::INET: connect: timeout real 0m5.00s user 0m0.05s sys 0m0.01s # So that is the behavior I think is inconsistent. Why would passing Timout result in EINVAL on AIX and HP boxes when an error is encountered in connect? Thanks |