Net::SSH::Perl kills perl from within an eval

[jahrens]

I didn't think this was possible.

So I'm using Net::SSH::Perl. Randomly it seems a connection that is in use will manage to kill perl while within an eval.

The code is very simple. $ssh is a Net::Perl::SSH object that is connected and authenticated.

 eval {($out, $err, $status) = $ssh->cmd("ls -l")};

It manages to kill perl. Like, total exit, no errors printed. I'm hoping someone might have some idea about what's going on, or how I might track it down. It's seems random, which makes it even worse. The exact same sequence of commands can work one time, but not another.

If nothing else, how about an explanation about how it's managing to die within an 'eval' without getting back to the main program?

[tye]

If nothing else, how about an explanation about how it's managing to die within an 'eval' without getting back to the main program?

exit is the easiest way. exec also works. There are also less pedestrian ways including bugs in perl, POSIX::_exit(), XS code, ...

(update) I tested and the following is another way:

 $ perl -e'eval { alarm(1); sleep(3); }; print "Done\n"'
Alarm clock
 $

In other words, the module (Net::SSH::Perl) could set a handler for a time-out but then remove the handler before canceling the time-out.

But I don't see where the module calls exit(), exec(), or even alarm().

[jahrens]

[almut]

Maybe running your program under strace (or equivalent) would help to shed some light on what's going on... (from the system call perspective, that is).  This would easily detect stuff like trying to write to a broken socket/pipe, etc.

[salva]

Instead of Net::SSH::Perl that's an almost dead project, if you can, use Net::SSH2. It is based on the libssh2 library that is actively developed and bugs are solved quickly.

[Krambambuli]

Maybe you can turn on some extra params to the connection to see more of what's going on, like



 
    my $ssh = Net::SSH::Perl->new( "host", 
                                   debug => 1,
                                   options => [
                                                 "ConnectTimeout 30", 
                                                 "LogLevel Debug3",
                                                 "ServerAliveInterval 
+10",
                                                 "ServerAliveCountMax 
+5",
                                               ],
              );

With a bit of luck, you might get ssh behaving in a way that would not make Perl show the unwanted behavior even with a flaky connection or over a link that faces packet loss.

Hth,

[jahrens]

I found http://www.perlmonks.org/?node_id=580411 after deeper digging. It sounds possible. I also got 141 for $? after the silent exit.

I'll have to throw in a suite of signal handlers to call out when they get called to see if it explains anything.

[ikegami]

That means it died from signal 13 (141 & 127). See man kill for a list. On my linux system, that's SIGPIPE, a very likely signal in the situation you presented.