in reply to Re^9: Can't decompress zlib compression stream with Compress:Zlib
in thread Can't decompress zlib compression stream with Compress:Zlib

Do you mean that it has fixed the issue with Compress::Zlib?

Calls to Compress::Zlib still do not work. Only 'use strict' errors are eliminated.

  • Comment on Re^10: Can't decompress zlib compression stream with Compress:Zlib

Replies are listed 'Best First'.
Re^11: Can't decompress zlib compression stream with Compress:Zlib
by pmqs (Friar) on Oct 10, 2016 at 10:54 UTC
    OK, in that case can you verify that the if statement in this section of your code evaluates to true and the block is actually being executed? My reading of the code suggests that if it isn't the contents of $s->{buf} will remain unchanged. That could account for your observation that you see strange ascii characters on the terminal.
    if ($nread && $s->{opts}{86}{remote_enabled}) { my ($nout, $status) = $zlib->inflate($s->{buf}); if (! defined $nout) { print "Error inflating: errnum: $status\n"; } else { # Inflation successful $s->{buf} = $nout; $nread = length ($nout); } }
    Also, if that block is triggered, does the call to inflate pass or fail? If it fails, what does this line actually print?
    print "Error inflating: errnum: $status\n";

      OP here. Looks like the MyTelnet->_fillbuf function is never actually called, due to some inheritance problem.

      Darned if I can see why inheritance doesn't work as expected:

      #!/usr/bin/perl -- my $connectObj = MyTelnet->new(); $connectObj->open( Host => 'iberiamud.mooo.com', Port => 5900, ); while (1) {} # Poor man's main loop { package MyTelnet; use base ("Net::Telnet"); sub _fillbuf { print "This function is never called\n"; print "Base class's ->_fillbuf function is called instead\n"; } }

      Regarding the call to inflate. My production code (which probably has no inheritance problems, as it generates billions of debug messages that actually appear) was producing:

      Error: No output status: data error msg: incorrect header check

      I tried ignoring everything before the first ASCII 120 character, which is where the zlib stream is supposed to start. The first couple of calls to Compress::Zlib->inflate then succeed. After that, we're back to square one, with new error messages:

      Error: No output status: data error msg: invalid code lengths set

      The zlib docs suggest this kind of error appears if the compressed stream is corrupted, but I haven't yet found anything in Net::Telnet that might be responsible.

        Net::Telnet doesn't easily lend itself to subclassing, at least not in the way you want to use it. It calls the (private) subroutine _fillbuf as:

        &_fillbuf($self, $s, 0);

        ... which will never respect inheritance.

        Before copying and rewriting Net::Telnet in a more approachable manner, you can monkey-patch Net::Telnet instead of inheriting:

        require Net::Telnet; { no warnings 'redefine'; *Net::Telnet::_fillbuf = sub { ... }; }; my $connectObj = Net::Telnet->new(); $connectObj->open( Host => 'iberiamud.mooo.com', Port => 5900, );