Hey,
Won't that be a bit pointless since we don't use threads?
Regards,
Robin Geuze
On 4/9/2018 10:31, Илья Шипицин wrote:
can you try thread sanitizer (in real time)?
https://github.com/google/sanitizers/wiki#threadsanitizer
I'd like to try myself, however, we do not observe bad things in our
environment
2018-04-09 13:24 GMT+05:00 Robin Geuze <rob...@transip.nl
<mailto:rob...@transip.nl>>:
Hey Willy,
So I made a build this morning with libslz and re-enabled
compression and within an hour we had the exit code 134 errors, so
zlib does not seem to be the problem here.
Regards,
Robin Geuze
On 4/7/2018 00:30, Willy Tarreau wrote:
Hi Robin,
On Fri, Apr 06, 2018 at 03:52:33PM +0200, Robin Geuze wrote:
Hey Willy,
I was actually the one that had the hunch to disable
compression. I
suspected that this was the issue because there was a
bunch of "abort" calls
in include/common/hathreads.h" which is used by the
compression stuff.
However I just noticed those aborts are actually only
there if DEBUG_THREAD
is defined which it doesn't seem to be for our build. So
basically, I have
no clue whatsoever why disabling compression fixes the bug.
At least I don't feel alone :-)
I can see next week if we can make a build with slz
instead of zlib (we seem
to be linked against zlib/libz atm).
Thank you, I appreciate it!
Cheers,
Willy
