[Home]

Summary:ASTERISK-16453: Asterisk crashes with a segmentation fault in timing.c [ast_timer_ack]
Reporter:Jeff Hoppe (jhoppebugs)Labels:
Date Opened:2010-07-28 13:07:02Date Closed:2010-07-28 13:49:44
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) backtrace0727.txt
( 1) backtrace0728.txt
Description:This issue has happened twice, both backtrace.txt files are attached.

Possible Clue: So far this issue only happens about 10 - 11 hours after we restart asterisk or stop and start asterisk.   Two days in a row, we would restart asterisk at mid-night then between 10:00 am to 11:00 am we would get the error that crashes Asterisk.  If we don't restart asterisk we can go days without a crash.

FYI - other crashes we have had over the last two weeks are issues, 0017686 and 0017687.

****** ADDITIONAL INFORMATION ******

This looks very similar to the closed issue 0016470.

I did not see any changes in 1.6.2.10 with regards to this issue.  But I will upgrade to it and try it out as well.
Comments:By: Leif Madsen (lmadsen) 2010-07-28 13:46:45

Really?

Per your backtrace:

#4  0x00a65a7e in do_timing (arg=0x0) at res_timing_pthread.c:468

Per the 1.6.2.10 ChangeLog:

2010-07-22  Leif Madsen <lmadsen@digium.com>

* Release Asterisk 1.6.2.10

* Included a fix for res_timing_pthread per the description below:

 r278465 | russell | 2010-07-21 11:15:00 -0500 (Wed, 21 Jul 2010) | 41 lines

 Use poll() instead of select() in res_timing_pthread to avoid stack corruption.
 This code did not properly check FD_SETSIZE to ensure that it did not try to
 select() on fds that were too large.  Switching to poll() removes the limitation
 on the maximum fd value.
By: Leif Madsen (lmadsen) 2010-07-28 13:49:44

Should be fixed in 1.6.2.10.