#4 interruption of select() in interconnect

serious
closed-fixed
Core (10)
5
2002-03-13
2002-03-06
No

I have found what appears to be a bug in the handling
of the return
value from the call to select in Expect::interconnect.
The problem
is that (at least on my system) select can return -1.
The code that
checks the return value only really checks for a
"false" return
value (0/''/undefined). Since -1 is "true", the loop
continuation
(``next CONNECT_LOOP'') is skipped, and the code tries
to read from
the filehandles indicated in the $rout bitset. On my
system the
read bitset is not changed when select returns -1 (at
least in my
particular case), so the code tries to read from all
the filehandles
originally present in the bit set before it continues
(even though
they may not be ready for reading).

The attached patch makes my problem go away. But I
wonder if the
original return value checking is correct. The
perlfunc entry for
select does not really talk about the return value
much, so I assume
it returns the same value as the select(2) system call
(which is
documented (again, on my system) to return -1 in error
situations).

Maybe

next CONNECT_LOOP unless ( defined $nfound && $nfound
&& $nfound > 0 );

would be better. This could be simplified to

next CONNECT_LOOP unless $nfound > 0;

if you are sure that $nfound will never be undef or
''. Generally
though, looping may not be the correct thing to do in
all "select
returns -1" situations, but basically is the right
thing to do for
signal-based interruptions.

My environment is as follows:

Linux/x86 2.2.19 (Debian 2.2)
Perl 5.005_03
Expect.pm 1.12

I checked in the latest version of Expect.pm (1.13_08),
and it
appears to have the same code construct. The attached
patch is
actually against the 1.13_08 version of Expect.pm.

The situation causing a -1 return from select is the
delivery of a
non-ignored signal (SIGWINCH in my case -- I am
propagating window
size changes through a telnet session).

The effect of the bug is that the application freezes
up unless all
the filehandles that were selected upon for reading
produce
something for the interconnect loop to read. My
application is an
auto-login telnet wrapper, so unless the remote system
sends the
telnet session something and the local user types
something, it will
block on the reads indefinitely. I have successfully
unwedged the
application by 'echoing' something to the remote tty
that is used
for the telnet connection and then typing something
into the local
session.

Discussion

  • Chris Johnsen

    Chris Johnsen - 2002-03-06

    Logged In: YES
    user_id=477349

    Ugh, sorry about the formatting, I had
    no idea it would not use my actual line
    breaks (which were around a reasonable,
    (or so I thought) 68 columns).

     
  • Roland Giersig

    Roland Giersig - 2002-03-06
    • milestone: 101727 --> serious
    • assigned_to: nobody --> rgiersig
     
  • Roland Giersig

    Roland Giersig - 2002-03-06

    Logged In: YES
    user_id=40438

    Thanks for pointing that one out, I'll fix that ASAP.

     
  • Roland Giersig

    Roland Giersig - 2002-03-13

    Logged In: YES
    user_id=40438

    Fixed in v1.14

     
  • Roland Giersig

    Roland Giersig - 2002-03-13
    • status: open --> closed-fixed
     

Log in to post a comment.