[asterisk-bugs] [Asterisk 0014211]: Asterisk Crashes with signal 11 (segmentation fault) at random intervals (but at least 2 times a day)
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Jan 15 15:03:15 CST 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=14211
======================================================================
Reported By: aborghi
Assigned To: putnopvut
======================================================================
Project: Asterisk
Issue ID: 14211
Category: Channels/chan_sip/Registration
Reproducibility: random
Severity: crash
Priority: normal
Status: ready for testing
Asterisk Version: 1.4.22
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-01-11 16:34 CST
Last Modified: 2009-01-15 15:03 CST
======================================================================
Summary: Asterisk Crashes with signal 11 (segmentation fault)
at random intervals (but at least 2 times a day)
Description:
Asterisk Crashes with signal 11 (segmentation fault) at random intervals
(but at least 2 times a day)
Asterisk began crashing after a configuration change to the sip channel to
handle two additional Corda numbers (before we had only one number and the
server keep running months).
Beside the obvious error in sip configuration i was going to solve,
asterisk began crashing more or less regularly after adding the
registrations for the new corda numbers, totalling 3 SIP registrations to
the cordia servers.
while debugging, I noted that che cordia servers does not seem to reply in
a timely manner to the sip requests, delaying registrations for long time
before accepting it.
from various backtraces i done while preparing the files for the report,
form various different crashes, i see that the signal 11 occours every time
in handle_response_register
A thing i noted is that while i have registerattempts=10 when the
registrations to cordia are timing out in the messages in the console i see
ALWAYS the attempt count a 0. It seems that asterisk is not counting
attempts to register to the cordia servers so it is not reaching the limit
i imposed of 10 attempts.
======================================================================
----------------------------------------------------------------------
(0097967) aborghi (reporter) - 2009-01-15 15:03
http://bugs.digium.com/view.php?id=14211#c97967
----------------------------------------------------------------------
ok. i can confirm that this patch resolves the crash problems for me.
Asterisk has not crashed in 2 days, 20 hours of service.
during this period i had some events like these:
Jan 13 20:15:04] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 13 20:15:04] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 13 20:15:04] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 13 20:24:24] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 13 20:24:24] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 13 20:24:24] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 13 21:12:05] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 13 22:35:44] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 13 22:35:44] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 14 01:32:16] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 14 01:32:16] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 14 01:32:16] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 14 02:09:26] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 14 02:09:26] WARNING[9169] chan_sip.c: Got 200 OK on REGISTER that
isn't a register
[Jan 14 02:46:40] WARNING[9169] chan_sip.c: Got a 408 response to our
REGISTER on call 4e6d2fb319ff613b7c840f355cd89b04 at 127.0.1.1 after we had
destroyed the registry object
[Jan 14 02:46:40] WARNING[9169] chan_sip.c: Got a 408 response to our
REGISTER on call 568b62eb24666c3575291c4a40757375 at 127.0.1.1 after we had
destroyed the registry object
[Jan 14 02:46:40] WARNING[9169] chan_sip.c: Got a 408 response to our
REGISTER on call 0b74e9133af5cd9d032a3f516a40ddc1 at 127.0.1.1 after we had
destroyed the registry object
[Jan 14 02:56:00] WARNING[9169] chan_sip.c: Got a 408 response to our
REGISTER on call 0b74e9133af5cd9d032a3f516a40ddc1 at 127.0.1.1 after we had
destroyed the registry object
[Jan 14 02:56:00] WARNING[9169] chan_sip.c: Got a 408 response to our
REGISTER on call 4e6d2fb319ff613b7c840f355cd89b04 at 127.0.1.1 after we had
destroyed the registry object
[Jan 14 02:56:00] WARNING[9169] chan_sip.c: Got a 408 response to our
REGISTER on call 568b62eb24666c3575291c4a40757375 at 127.0.1.1 after we had
destroyed the registry object
[Jan 14 02:56:41] NOTICE[9169] chan_sip.c: -- Registration for
'16462487925 at soft1.ny.cordiaip.net' timed out, trying again (Attempt
http://bugs.digium.com/view.php?id=0)
[Jan 14 02:56:41] NOTICE[9169] chan_sip.c: -- Registration for
'442033553817 at soft1.ny.cordiaip.net' timed out, trying again (Attempt
http://bugs.digium.com/view.php?id=0)
[Jan 14 02:56:41] NOTICE[9169] chan_sip.c: -- Registration for
'33170615949 at soft1.ny.cordiaip.net' timed out, trying again (Attempt
http://bugs.digium.com/view.php?id=0)
but asterisk is up and running.
Why we arrive in a part of code where we try to free an already freed
block is a curiosity of mine but i don't have the time to learn the innards
of asterisk code to learn that.
Let me clarify: my programmer side does not like this situation at the
code level, it's a thing that suggests some other and more frightening
effects of locking, thread interactions, bad state machines and such. BUT
the simple fact the patch (as this is really a "patch") is confirmed to be
working for me, and that is all i can do this time due to my work levels.
I wish to thank you all for the quick resolution.
I hope this will be integrated in releasing 1.4.23
Issue History
Date Modified Username Field Change
======================================================================
2009-01-15 15:03 aborghi Note Added: 0097967
======================================================================
More information about the asterisk-bugs
mailing list