in reply to Re: Net::Telnet core dumps
in thread Net::Telnet core dumps

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.

Replies are listed 'Best First'.
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?