Re: Net::Telnet core dumps

Hmm, the examples in the perldoc for Net::Telnet suggest opening sessions like so:

my $ses = new Net::Telnet();
$ses->open(Host => $hostname,
    Port => $port);
[download]

Many of them don't use close() (but it's a good idea). None of them that I've seen use DESTROY. Perl should call this automatically for you at the end of the block, when $ses goes out of scope.

You can debug timeout errors with the input_log() and dump_log() methods. The first shows filtered output from the remote session, and the latter shows unfiltered. Something like:

$logtxt = $ses->dump_log();
&logit;
[download]

might do the trick.

Comment on Re: Net::Telnet core dumps Select or Download Code

Replies are listed 'Best First'.
RE: Re: Net::Telnet core dumps by raflach (Pilgrim) on Apr 19, 2000 at 20:27 UTC
Hmmm... If I wasn't getting core dumps, but some other type of non-crashing failure, these might work for me, but I don't think that they will do any good in my situation. I hope I am wrong. Am I? Note: NET::Telnet defaults to the standard telnet port if no port is specified. which is why I don't have a port specified. The port option is there to allow the module to be used for things other than standard telnet, like muds, or even completely non-standard network communications. I constantly cored when I didn't specify a timeout in the initial code, which is why I added that param, but increasing it above 1000 doesn't seem to have any affect one way or the other. The errmode param, I can't remember why I added, and it may not be needed. My error is occuring prior to the call of DESTROY, so I'm fairly sure that is not the issue, but it may be superfluous code, so I'll take it out, test it, and see. Thanks for your help.	[reply]
RE: RE: Re: Net::Telnet core dumps by chromatic (Archbishop) on Apr 20, 2000 at 00:10 UTC
I'd get rid of the errmode, anyway, or at least change it to a simple return call. That way, if there is an error, you can call errmsg() and see what it is. I've seen signal handlers die randomly sometimes. (In the perlipc manpage, it says that some system libraries aren't reentrant, and trying to do too much in a sighandler can cause nasty things like coredumps.) That doesn't look to be the case in Telnet.pm, as far as I can see. wait just looks wrong. Why would you need to wait for a CHLD signal?	[reply]