| Summary: | ASTERISK-14249: crash - address out of bounds | ||
| Reporter: | pj (pj) | Labels: | |
| Date Opened: | 2009-06-02 04:37:02 | Date Closed: | 2011-06-07 14:00:55 |
| Priority: | Critical | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) gdb.txt | |
| Description: | asterisk crashed during call ringing state, it was sip2sip call, so it's probably bug in chan_sip, but I'm also using chan_skinny, so please look at bugreport ASTERISK-12960 if it can't be related. | ||
| Comments: | By: David Woolley (davidw) 2009-06-02 05:51:41 It helps to know which thread crashed (and the failing instruction). At a guess, it is thread 1, in which case it is a skinny problem. By: pj (pj) 2009-06-02 06:13:04 error "Address out of bounds" is in thread 21, which is chan_sip, chan_skiny was "idle" (it had no call) when this crash happen By: David Woolley (davidw) 2009-06-02 06:24:38 Thread 21 is in the kernel. Kernel detected errors are normally reported as return codes, not as signals. Thread 1 appears to be in a run state and is executing from handle_stimulus_message in chan_skinny.c. A much more plausible situation for a crash. "Address out of bounds" is not a normal Unix signal. It is more likely to be gdb reporting that it cannot fully interpret what it has been given. When you start gdb, it should tell you the signal that caused the crash. By: pj (pj) 2009-06-02 06:52:08 I have following message, when gdb starts: Program terminated with signal 11, Segmentation fault. #0 0x0808474a in INTERNAL_OBJ (user_data=0x3731332a) at astobj2.c:115 115 if (AO2_MAGIC != (p->priv_data.magic) ) { By: David Woolley (davidw) 2009-06-02 06:56:55 Definitely thread 1, the skinny one. By: pj (pj) 2009-06-02 07:12:21 Thanks for analysis! Do you think, that this backtrace brings some new info for help to solve bug in skinny ASTERISK-1367777 ? After you point me to Thread 1, it seems for me, that both backtraces are similar, so if this bugreport brings nothing new to ASTERISK-1367777, it can be closed. By: Leif Madsen (lmadsen) 2009-06-24 12:04:33 Closing as this is not a crash in chan_sip. I have marked it as related to 13777 just in case the backtrace information is useful here for that bug report. Thanks! | ||