[OpenSIPS-Users] segfault at the opensips 2.4.5

[Oleg Podguyko]

Hi

The "segfault" event itself is already a sign that something is not working correctly. And this is the reason to open bugreport
I want to understand the mechanism of how opensips processes this kind of accident
For example in the logs I see messages:
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[5577]: CRITICAL:core:sig_usr: segfault in process pid: 5577, id: 13
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[5564]: NOTICE:event_jsonrpc:destroy: destroy module ...
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:core:main: version: opensips 2.4.5 (x86_64/linux)
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: WARNING:core:init_reactor_size: shrinking reactor size from 262144 (autodetected via rlimit) to 52428 (limited by memory of 10% from 16Mb)
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: WARNING:core:init_reactor_size: use 'open_files_limit' to enforce other limit or increase pkg memory
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:signaling:mod_init: initializing module ...
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:event_jsonrpc:mod_init: initializing module ...
I noticed from this accident that opensips seemed to be "rebooted" and In this case, opensips continued to process traffic.
But what really happened? I see a new uptime after it. Am I understand correctly that in this particular case only the module jsonrpc was overloaded? 
Or the whole service was restarted? 
 
And another case at the another server:

Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: CRITICAL:core:sig_usr: segfault in process pid: 168640114, id: 5
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: DBG:core:restore_segv_handler: restoring SIGSEGV handler...
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: DBG:core:restore_segv_handler: successfully restored system SIGSEGV handler
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30348]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 10
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30345]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 7
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30344]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 6
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: ERROR:core:parse_msg: message=<309132295C7FA6B57F8DE8DC3D4C0#015#012Content-Type:application/ISUP;base=itu-t92+;version=itu-t92+#015#012Content-Disposition:signal;handling=required#015#012Content-Transfer-Encoding:binary#015#012#015#012#001#020 #001#012>
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: ERROR:core:receive_msg: Unable to parse msg received from [10.48.101.171:60105]
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30350]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 12
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 11
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30351]: CRITICAL:core:sig_usr: segfault in process pid: 23032000, id: 13

After all these messages, opensips just “fell asleep”. It didn't handle any traffic until I reloaded it. 
 
id  10,11,12,13 — receiver SCTP
id 7,6 — receiver UDP

How opensips handles segfault?  And what needs to be done so that he does not die just like in the latter case?
 
--
Oleg Podguyko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200312/e81573d1/attachment-0001.html>