Still getting compression failed on 5.25.1

Issue #734 new
Former user created an issue

I'm in an oraclelinux:6 docker container with the following rpm versions:

$ uname -a
Linux 52d7f18bb83a 4.9.87-linuxkit-aufs #1 SMP Wed Mar 14 15:12:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -qi monit
Name        : monit                        Relocations: (not relocatable)
Version     : 5.25.1                            Vendor: Fedora Project
Release     : 1.el6                         Build Date: Tue Dec 26 20:39:46 2017
Install Date: Thu Apr  5 10:38:58 2018         Build Host: buildvm-09.phx2.fedoraproject.org
Group       : Applications/Internet         Source RPM: monit-5.25.1-1.el6.src.rpm
$ rpm -qi zlib
Name        : zlib                         Relocations: (not relocatable)
Version     : 1.2.3                             Vendor: Oracle America
Release     : 29.el6                        Build Date: Fri Dec 21 05:55:20 2012
Install Date: Thu Mar  8 19:20:04 2018         Build Host: ca-buildj3.us.oracle.com
Group       : System Environment/Libraries   Source RPM: zlib-1.2.3-29.el6.src.rpm

And still seeing compression failure in the logs :)

$ tail /var/log/monit
[UTC Apr  5 15:55:26] critical : AssertException: compression failed:
 raised in StringBuffer_toCompressed at src/util/StringBuffer.c:300
[UTC Apr  5 16:00:45] info     : Starting Monit 5.25.1 daemon with http interface at [localhost]:2812
[UTC Apr  5 16:00:45] info     : '52d7f18bb83a' Monit 5.25.1 started
[UTC Apr  5 16:00:46] critical : AssertException: compression failed:
 raised in StringBuffer_toCompressed at src/util/StringBuffer.c:300
[UTC Apr  5 16:01:00] info     : Starting Monit 5.25.1 daemon with http interface at [localhost]:2812
[UTC Apr  5 16:01:00] info     : '52d7f18bb83a' Monit 5.25.1 started
[UTC Apr  5 16:01:06] critical : AssertException: compression failed:
 raised in StringBuffer_toCompressed at src/util/StringBuffer.c:300

Might be because it's Oracle's zlib distribution in this case rather than the one seen in #515.

Comments (2)

  1. Ben Meier

    Could trigger the crash by using the following request:

    $ curl -u foo:bar -H 'Accept-Encoding: gzip' http://127.0.0.1:2812/_ping
    

    Is the ping/pong response too small to zip correctly or something? I didn't see the same issue when using _status

  2. Log in to comment