Bug #4468
closed
Assertion failures in TmThreadsInjectFlowById
Added by Cooper Nelson over 3 years ago.
Updated 5 months ago.
Description
We are seeing period failures in suricata 6.0.2 with the following exit status on a 40G deployment:
suricata: tm-threads.c:2310: TmThreadsInjectFlowById: Assertion `!(id <= 0 || id > (int)thread_store.threads_size)' failed.
Aborted
Is it possible to share some backtrace/core info ?
Peter Manev wrote in #note-1:
Is it possible to share some backtrace/core info ?
I’m not seeing a segfault in the logs, I needed to run suricata interactively and wait until it terminated, I got that info from the console.
It’s exiting via a 6/ABRT in the logs, so there is no core:
Apr 27 19:31:29 serv01 suricata480965: 27/4/2021 -- 19:31:29 - <Notice> - This is Suricata version 6.0.2 RELEASE running in SYSTEM mode
Apr 27 19:31:29 serv01 systemd1: Started Suricata Intrusion Detection Service.
Apr 27 19:33:49 serv01 systemd1: suricata.service: Main process exited, code=killed, status=6/ABRT
Apr 27 19:33:49 serv01 systemd1: suricata.service: Failed with result 'signal'.
Apr 27 19:33:54 serv01 systemd1: suricata.service: Service RestartSec=5s expired, scheduling restart.
I think this is the source of the error, it looks like its a debugging tool:
https://linux.die.net/man/3/assert
I’m not seeing a segfault in the logs, I needed to run suricata interactively and wait until it terminated, I got that info from the console.
It’s exiting via a 6/ABRT in the logs, so there is no core:
Apr 27 19:31:29 suricata480965: 27/4/2021 -- 19:31:29 - <Notice> - This is Suricata version 6.0.2 RELEASE running in SYSTEM mode
Apr 27 19:31:29 systemd1: Started Suricata Intrusion Detection Service.
Apr 27 19:33:49 systemd1: suricata.service: Main process exited, code=killed, status=6/ABRT
Apr 27 19:33:49 systemd1: suricata.service: Failed with result 'signal'.
Apr 27 19:33:54 systemd1: suricata.service: Service RestartSec=5s expired, scheduling restart.
I think this is the source of the error, it looks like its a debugging tool:
https://linux.die.net/man/3/assert
Yes there is an assert to catch bad input to the function. It should lead to a core dump from which you should be able to generate a stack trace.
- Related to Bug #4582: BUG_ON triggered from TmThreadsInjectFlowById added
- Status changed from New to Closed
Also available in: Atom
PDF