Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

syslog-ng-3.20 deadlock caused by grouping-by() parser #2630

Closed
abalage opened this issue Mar 14, 2019 · 20 comments · Fixed by #2758

Comments

@abalage
Copy link

commented Mar 14, 2019

syslog-ng

Version of syslog-ng

syslog-ng 3 (3.20.1)
Config version: 3.20
Installer-Version: 3.20.1
Revision: 
Module-Directory: /usr/lib64/syslog-ng
Module-Path: /usr/lib64/syslog-ng
Include-Path: /usr/share/syslog-ng/include
Available-Modules: add-contextual-data,affile,afprog,afsocket,afstomp,afuser,appmodel,basicfuncs,cef,confgen,cryptofuncs,csvparser,date,dbparser,disk-buffer,examples,graphite,hook-commands,json-plugin,kvformat,linux-kmsg-format,map-value-pairs,pseudofile,sdjournal,snmptrapd-parser,stardate,syslogformat,system-source,tags-parser,tfgetent,xml,mod-python,geoip-plugin,geoip2-plugin,http
Enable-Debug: off
Enable-GProf: off
Enable-Memtrace: off
Enable-IPv6: on
Enable-Spoof-Source: on
Enable-TCP-Wrapper: on
Enable-Linux-Caps: on
Enable-Systemd: on

Platform

openSUSE Leap 15.0

Issue

Syslog-ng stops storing log messages. No new messages are getting stored in any destination drivers.

Failure

gdb "threads apply all bt full" is attached, so as the core file

Steps to reproduce

  1. start syslog-ng with the configs supplied in attachment

  2. use monitoring system to realize no new logs are coming in :)

Configuration

See attached bundle.

Input and output logs (if possible)

See attached bundle.
bugreport-syslog-ng-320-opensuse.tar.gz

@abalage

This comment has been minimized.

Copy link
Author

commented Mar 14, 2019

strace, netstat, lsof, gdb backtrace, core file, messages, config are all stored in that tar.gz
I am sorry for any inconveniences it may caused that I did not upload it separately.

@Kokan

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2019

Thanks for the great report, it is fine uploading them in one tar.gz.

@Kokan Kokan added the bug label Mar 14, 2019
@Kokan

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2019

The issue seems to be related to the group-by parser and the file destination.

  1. The timer for the group-by is expired thus triggering in the main thread. This thread waits for the lock owned by group-by pipe item.
  2. The log path that has the group-by configured also active in a different thread, where it processes a message (the group-by queue holds the lock), and reaches the file destination that wants to open a writer affile_dd_open_writer, which - as of now - should be done in the main thread.
  3. But the main the main thread waits for the processing thread to release the lock.

If you avoid having the file destination in the same logpath with the group-by this issue should not happen. For example as a workaround you could replace the current: destination(d_network_conntrack); with a network destination sending the message to syslog-ng itself:

...
destination d_network_conntrack{
    network("127.0.0.1" port(1111));
};
...

log {
   source {
       network("127.0.0.1" port(1111));
   };
   destination {
    file(
        "/var/log/network/$HOST/$S_YEAR.$S_MONTH.$S_DAY/messages.json"
        template("$(format_json --scope rfc5424 --key HOST --key ISODATE --key hostname.* --key nf_new.* --key nf_reply.* --key nf.SESSION* --key geoip2.*)\n")
        create-dirs(yes)
    );
   };
};

This workaround should work as it breaks the above mentioned cycle.

Disclaimer the above workaround config snippet was not tried, and possible you have to do some work with the macros, etc ...

@abalage

This comment has been minimized.

Copy link
Author

commented Mar 18, 2019

fyi: Removing the file destination from the nested log path did not resolve the issue.

@abalage abalage changed the title syslog-ng-3.20 deadlock on opensuse syslog-ng-3.20 deadlock caused by grouping-by() parser Mar 20, 2019
@Kokan

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

Thanks for the feedback, I had to do something else for a while; but I am back on this track.

@Kokan

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

I could not reproduce this on my system, but based on your debug bunldle, gdb stacktrace I have the idea explained above. I came up a patchset that should solve this deadlock: https://github.com/Kokan/syslog-ng/tree/group_by_deadlock

Would it be possible for you to try this out ?

@abalage

This comment has been minimized.

Copy link
Author

commented Apr 2, 2019

I installed a binary built from your branch to test the issue. I will report back after a couple of days.

@abalage

This comment has been minimized.

Copy link
Author

commented Apr 4, 2019

I enabled file destinations again but no logs are being stored there (could be because of my config).
Anyway I still experience coredump upon logrotation (SIGABRT).

Apr  4 11:27:39 microchuck syslog-ng[19027]: Accepting connections; addr='AF_INET(172.18.0.20:5140)'
Apr  4 11:27:39 microchuck syslog-ng[19027]: Disk-buffer state loaded; filename='/opt/syslog-ng/var/syslog-ng-00000.qf', qout_length='0', qbacklog_length='0', qoverflow_length='0', qdisk_length='0'
Apr  4 11:27:39 microchuck syslog-ng[19027]: Disk-buffer state loaded; filename='/opt/syslog-ng/var/syslog-ng-00001.qf', qout_length='0', qbacklog_length='0', qoverflow_length='0', qdisk_length='0'
Apr  4 11:27:39 microchuck syslog-ng[19027]: Disk-buffer state loaded; filename='/opt/syslog-ng/var/syslog-ng-00002.qf', qout_length='0', qbacklog_length='0', qoverflow_length='0', qdisk_length='0'
Apr  4 11:27:39 microchuck syslog-ng[19027]: Disk-buffer state loaded; filename='/opt/syslog-ng/var/syslog-ng-00003.qf', qout_length='0', qbacklog_length='0', qoverflow_length='0', qdisk_length='0'
Apr  4 11:27:39 microchuck syslog-ng[19027]: Log pattern database reloaded; file='/etc/syslog-ng/patterndb.xml', version='4', pub_date='2018-06-05'
Apr  4 11:27:39 microchuck syslog-ng[19027]: WARNING: window sizing for tcp sources were changed in syslog-ng 3.3, the configuration value was divided by the value of max-connections(). The result was too small, clamping to value of min_iw_size_per_reader. Ensure you have a proper log_fifo_size setting to avoid message loss.; orig_log_iw_size='50', new_log_iw_size='100', min_iw_size_per_reader='100', min_log_fifo_size='2000'
Apr  4 11:27:39 microchuck syslog-ng[19027]: Accepting connections; addr='AF_INET(172.18.0.20:514)'
Apr  4 11:27:39 microchuck syslog-ng[19027]: Disk-buffer state loaded; filename='/opt/syslog-ng/var/syslog-ng-00004.qf', qout_length='0', qbacklog_length='0', qoverflow_length='0', qdisk_length='0'
Apr  4 11:27:39 microchuck syslog-ng[19027]: Disk-buffer state loaded; filename='/opt/syslog-ng/var/syslog-ng-00005.qf', qout_length='0', qbacklog_length='0', qoverflow_length='0', qdisk_length='0'
Apr  4 11:27:39 microchuck syslog-ng[19027]: Disk-buffer state loaded; filename='/opt/syslog-ng/var/syslog-ng-00006.qf', qout_length='0', qbacklog_length='0', qoverflow_length='0', qdisk_length='0'
Apr  4 11:27:39 microchuck syslog-ng[19027]: Disk-buffer state loaded; filename='/opt/syslog-ng/var/syslog-ng-00007.qf', qout_length='0', qbacklog_length='0', qoverflow_length='0', qdisk_length='0'
Apr  4 11:27:39 microchuck syslog-ng[19027]: Configuration reload request received, reloading configuration;
Apr  4 11:27:39 microchuck syslog-ng[19027]: Configuration reload finished;
Apr  4 11:27:41 microchuck syslog-ng[24858]: syslog-ng starting up; version='3.19.1.625.ga3610c5'
Apr  4 11:27:40 microchuck systemd[1]: syslog-ng.service: Main process exited, code=killed, status=6/ABRT
Apr  4 11:27:40 microchuck systemd[1]: syslog-ng.service: Unit entered failed state.
Apr  4 11:27:40 microchuck systemd[1]: syslog-ng.service: Failed with result 'signal'.
Apr  4 11:27:40 microchuck systemd-coredump[24850]: Process 19027 (syslog-ng) of user 0 dumped core.
Apr  4 11:27:40 microchuck systemd[1]: syslog-ng.service: Service RestartSec=100ms expired, scheduling restart.
Apr  4 11:27:41 microchuck syslog-ng[24858]: Syslog connection accepted; fd='58', client='AF_INET(172.18.0.1:56240)', local='AF_INET(172.18.0.20:514)'
Apr  4 11:27:41 microchuck syslog-ng[24858]: Syslog connection accepted; fd='59', client='AF_INET(172.18.0.142:49134)', local='AF_INET(172.18.0.20:514)'
Apr  4 11:32:56 microchuck syslog-ng[24858]: Error from call to getaddrinfo; gai_error='Name or service not known', where='lookup'
Apr  4 11:34:57 microchuck syslog-ng[24858]: Syslog connection accepted; fd='66', client='AF_INET(172.18.0.6:41035)', local='AF_INET(172.18.0.20:514)'

Version

# /opt/syslog-ng/sbin/syslog-ng -V
syslog-ng 3 (3.19.1.625.ga3610c5)
Config version: 3.20
Installer-Version: 3.19.1.625.ga3610c5
Revision: 
Compile-Date: Apr  2 2019 13:06:05
Module-Directory: /opt/syslog-ng/lib/syslog-ng
Module-Path: /opt/syslog-ng/lib/syslog-ng
Include-Path: /opt/syslog-ng/share/syslog-ng/include
Available-Modules: syslogformat,afsocket,affile,afprog,afuser,http,csvparser,confgen,system-source,linux-kmsg-format,basicfuncs,cryptofuncs,dbparser,json-plugin,geoip2-plugin,afstomp,pseudofile,graphite,sdjournal,mod-python,kvformat,date,cef,disk-buffer,add-contextual-data,tfgetent,map-value-pairs,stardate,snmptrapd-parser,tags-parser,xml,appmodel,hook-commands,examples
Enable-Debug: on
Enable-GProf: off
Enable-Memtrace: off
Enable-IPv6: on
Enable-Spoof-Source: on
Enable-TCP-Wrapper: off
Enable-Linux-Caps: off
Enable-Systemd: on

gdb.txt.gz

@abalage

This comment has been minimized.

Copy link
Author

commented Apr 4, 2019

Let me know if you need the core file too.

@Kokan

This comment has been minimized.

Copy link
Contributor

commented Apr 4, 2019

You compiled from the fork of my master, which did not have my fix.
The crash you found is a different issue on master, fortunately @furiel just found and created a fix for this crash: #2655

Now to I've rebased my branch on top of @furiel 's, so my group_by_deadlock branch should contains both fixes.

One possible way to get the correct branch:

git clone https://github.com/Kokan/syslog-ng/
git checkout group_by_deadlock

You could verify the source with checking the hash:

git log -1 HEAD
commit e3efac204fbd04e516bc9aa92f55a0929ed16f3d (HEAD -> group_by_deadlock, origin/group_by_deadlock)
Author: Kokan <kokaipeter@gmail.com>
Date:   Tue Mar 26 10:55:57 2019 +0100

    groupingby: send new synthetic msg after the lock

    The *stateful_parser_emit_synthetic* inject the new msg
    into the current logpath, and holds the lock, but
    the lock imho is not required at this stage, as nothing is done
    after this only waits here the stack to be rolled back.

    Therefore the ordering change should be fine.

    Signed-off-by: Kokan <kokaipeter@gmail.com>

Also the suffix of the compiled syslog-ng installer version should have this: .ge3efac2 value.

@abalage

This comment has been minimized.

Copy link
Author

commented Apr 4, 2019

Thanks for the notice. I recompiled it but this time on the right branch after git pull.

@abalage

This comment has been minimized.

Copy link
Author

commented Apr 5, 2019

This isn't look good. It aborts in every couple of minutes. (I noticed that your branch is on 3.19 and not on 3.20)
gdb.10116.txt.gz SIGSEGV
gdb.10662.txt.gz SIGSEGV
gdb.10775.txt.gz SIGABRT
gdb.11897.txt.gz SIGABRT

@Kokan

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2019

It is not on 3.19, but there was a change to use git describe to obtain the version, which looks for recent tag. But my fork does not have the 3.20.1 tag (it has the code for it but not tagged). Thus if you only clone my repo, you get the 3.19.1.g..... (https://github.com/Kokan/syslog-ng/tags)

I'll check later the gdb outputs, thanks for the test.

@abalage

This comment has been minimized.

Copy link
Author

commented Apr 15, 2019

How is your progress? Is there anything I can do to help?

@Kokan

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2019

I had to investigate some nasty linker related issue, now I am back on this track.

Based on the first glance of those stack traces it still hits some issue before the code that causes the deadlock. All of them seem to originate from the same root cause.

@abalage

This comment has been minimized.

Copy link
Author

commented Apr 26, 2019

Do you have any news on this issue? Thanks in advance.

@Kokan

This comment has been minimized.

Copy link
Contributor

commented May 2, 2019

Yes, sadly only once but I could trigger the same crash as yours. Which gave me the location of free and use after free:

==16181==ERROR: AddressSanitizer: heap-use-after-free on address 0x60400002c010 at pc 0x7fd2eed4d878 bp 0x7fd2eecbd5d0 sp 0x7fd2eecbd5c8
READ of size 8 at 0x60400002c010 thread T1
    #0 0x7fd2eed4d877 in iv_list_del_init /usr/include/iv_list.h:75:25
    #1 0x7fd2eed4dfaa in timer_wheel_mod_timer /src/syslog-ng/build/../modules/dbparser/timerwheel.c:210:3
    #2 0x7fd2eed3cae1 in _perform_groupby /src/syslog-ng/build/../modules/dbparser/groupingby.c:388:15
    #3 0x7fd2eed3c081 in grouping_by_process /src/syslog-ng/build/../modules/dbparser/groupingby.c:427:12
    #4 0x7fd2f477cfbe in log_parser_process_message /src/syslog-ng/build/../lib/parser/parser-expr.c:61:17
    #5 0x7fd2f477d7fc in log_parser_queue /src/syslog-ng/build/../lib/parser/parser-expr.c:91:13
    #6 0x7fd2f477e053 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #7 0x7fd2f477d825 in log_parser_queue /src/syslog-ng/build/../lib/parser/parser-expr.c:96:7
    #8 0x7fd2f4714213 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #9 0x7fd2f4714221 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:366:7
    #10 0x7fd2f4714221 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:366:7
    #11 0x7fd2f4714221 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:366:7
    #12 0x7fd2eedc9113 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #13 0x7fd2f4728483 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #14 0x7fd2f4728e49 in log_source_queue /src/syslog-ng/build/../lib/logsource.c:379:3
    #15 0x7fd2f4728483 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #16 0x7fd2f4728199 in log_source_post /src/syslog-ng/build/../lib/logsource.c:296:3
    #17 0x7fd2f4726a41 in log_reader_handle_line /src/syslog-ng/build/../lib/logreader.c:406:3
    #18 0x7fd2f4726459 in log_reader_fetch_log /src/syslog-ng/build/../lib/logreader.c:473:16
    #19 0x7fd2f4725e3d in log_reader_work_perform /src/syslog-ng/build/../lib/logreader.c:105:23
    #20 0x7fd2f473a2a0 in _work /src/syslog-ng/build/../lib/mainloop-io-worker.c:69:3
    #21 0x7fd2f44d1012  (/usr/lib/libivykis.so.0+0x5012)
    #22 0x7fd2f44cf9a4  (/usr/lib/libivykis.so.0+0x39a4)
    #23 0x7fd2f44d5ad5  (/usr/lib/libivykis.so.0+0x9ad5)
    #24 0x7fd2f44d1c48  (/usr/lib/libivykis.so.0+0x5c48)
    #25 0x7fd2f44d3272 in iv_main (/usr/lib/libivykis.so.0+0x7272)
    #26 0x7fd2f44d0dd7  (/usr/lib/libivykis.so.0+0x4dd7)
    #27 0x7fd2f44d45e5  (/usr/lib/libivykis.so.0+0x85e5)
    #28 0x7fd2f400ca91 in start_thread (/usr/lib/libpthread.so.0+0x7a91)
    #29 0x7fd2f3dc9cd2 in __GI___clone (/usr/lib/libc.so.6+0xfacd2)

0x60400002c010 is located 0 bytes inside of 48-byte region [0x60400002c010,0x60400002c040)
freed by thread T1 here:
    #0 0x558ecacfd2d1 in free (/tmp/install/sbin/syslog-ng+0xf82d1)
    #1 0x7fd2eed4df5c in timer_wheel_del_timer /src/syslog-ng/build/../modules/dbparser/timerwheel.c:203:3
    #2 0x7fd2eed3c998 in _perform_groupby /src/syslog-ng/build/../modules/dbparser/groupingby.c:331:13
    #3 0x7fd2eed3c081 in grouping_by_process /src/syslog-ng/build/../modules/dbparser/groupingby.c:427:12
    #4 0x7fd2f477cfbe in log_parser_process_message /src/syslog-ng/build/../lib/parser/parser-expr.c:61:17
    #5 0x7fd2f477d7fc in log_parser_queue /src/syslog-ng/build/../lib/parser/parser-expr.c:91:13
    #6 0x7fd2f477e053 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #7 0x7fd2f477d825 in log_parser_queue /src/syslog-ng/build/../lib/parser/parser-expr.c:96:7
    #8 0x7fd2f4714213 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #9 0x7fd2f4714221 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:366:7
    #10 0x7fd2f4714221 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:366:7
    #11 0x7fd2f4714221 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:366:7
    #12 0x7fd2eedc9113 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #13 0x7fd2f4728483 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #14 0x7fd2f4728e49 in log_source_queue /src/syslog-ng/build/../lib/logsource.c:379:3
    #15 0x7fd2f4728483 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #16 0x7fd2f4728199 in log_source_post /src/syslog-ng/build/../lib/logsource.c:296:3
    #17 0x7fd2f4726a41 in log_reader_handle_line /src/syslog-ng/build/../lib/logreader.c:406:3
    #18 0x7fd2f4726459 in log_reader_fetch_log /src/syslog-ng/build/../lib/logreader.c:473:16
    #19 0x7fd2f4725e3d in log_reader_work_perform /src/syslog-ng/build/../lib/logreader.c:105:23
    #20 0x7fd2f473a2a0 in _work /src/syslog-ng/build/../lib/mainloop-io-worker.c:69:3
    #21 0x7fd2f44d1012  (/usr/lib/libivykis.so.0+0x5012)

previously allocated by thread T1 here:
    #0 0x558ecacfd901 in calloc (/tmp/install/sbin/syslog-ng+0xf8901)
    #1 0x7fd2f45427f9 in g_malloc0 (/usr/lib/libglib-2.0.so.0+0x657f9)
    #2 0x7fd2eed3cb60 in _perform_groupby /src/syslog-ng/build/../modules/dbparser/groupingby.c:392:32
    #3 0x7fd2eed3c081 in grouping_by_process /src/syslog-ng/build/../modules/dbparser/groupingby.c:427:12
    #4 0x7fd2f477cfbe in log_parser_process_message /src/syslog-ng/build/../lib/parser/parser-expr.c:61:17
    #5 0x7fd2f477d7fc in log_parser_queue /src/syslog-ng/build/../lib/parser/parser-expr.c:91:13
    #6 0x7fd2f477e053 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #7 0x7fd2f477d825 in log_parser_queue /src/syslog-ng/build/../lib/parser/parser-expr.c:96:7
    #8 0x7fd2f4714213 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #9 0x7fd2f4714221 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:366:7
    #10 0x7fd2f4714221 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:366:7
    #11 0x7fd2f4714221 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:366:7
    #12 0x7fd2eedc9113 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #13 0x7fd2f4728483 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #14 0x7fd2f4728e49 in log_source_queue /src/syslog-ng/build/../lib/logsource.c:379:3
    #15 0x7fd2f4728483 in log_pipe_queue /src/syslog-ng/build/../lib/logpipe.h:362:7
    #16 0x7fd2f4728199 in log_source_post /src/syslog-ng/build/../lib/logsource.c:296:3
    #17 0x7fd2f4726a41 in log_reader_handle_line /src/syslog-ng/build/../lib/logreader.c:406:3
    #18 0x7fd2f4726459 in log_reader_fetch_log /src/syslog-ng/build/../lib/logreader.c:473:16
    #19 0x7fd2f4725e3d in log_reader_work_perform /src/syslog-ng/build/../lib/logreader.c:105:23
    #20 0x7fd2f473a2a0 in _work /src/syslog-ng/build/../lib/mainloop-io-worker.c:69:3
    #21 0x7fd2f44d1012  (/usr/lib/libivykis.so.0+0x5012)

Thread T1 created by T0 here:
    #0 0x558ecac4e252 in pthread_create (/tmp/install/sbin/syslog-ng+0x49252)
    #1 0x7fd2f44d4802 in iv_thread_create (/usr/lib/libivykis.so.0+0x8802)

SUMMARY: AddressSanitizer: heap-use-after-free /usr/include/iv_list.h:75:25 in iv_list_del_init
Shadow bytes around the buggy address:
  0x0c087fffd7b0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x0c087fffd7c0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fd
  0x0c087fffd7d0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fd
  0x0c087fffd7e0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x0c087fffd7f0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
=>0x0c087fffd800: fa fa[fd]fd fd fd fd fd fa fa fa fa fa fa fa fa
  0x0c087fffd810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

That lead to me to a commit I did in this branch (6c0ba34)
The g_hash_table_remove(self->correllation->state, &context->key); should have been called :(

Now pushed a new patch to fix it, you can find the fix on the same fork/branch. The commit hash is: Kokan@7d0eb30

Really appreciate testing these patches out.

@abalage

This comment has been minimized.

Copy link
Author

commented May 15, 2019

I have installed a version compiled from your branch. It looks better (no coredump vs frequent coredump in every minutes). I will leave it running for a while.

@abalage

This comment has been minimized.

Copy link
Author

commented May 16, 2019

I have no more crashes since I applied your patch. Log traffic is considered medium or small. I consider this as resolved.

Do you have any plans in which version is this going to be fixed?

Thank you for your help.

@Kokan

This comment has been minimized.

Copy link
Contributor

commented May 16, 2019

Some additional work is needed for the patches to be accepted, but I am sure it can fit into the next release 3.22.

@Kokan Kokan self-assigned this May 16, 2019
@furiel furiel closed this in #2758 Jun 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.