Summary: | ASTERISK-12481: Incoming ISDN call gives segfault in manager_isdn_handler | ||
Reporter: | Thomas Omerzu (t-o) | Labels: | |
Date Opened: | 2008-07-29 17:02:31 | Date Closed: | 2011-06-07 14:00:38 |
Priority: | Critical | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_misdn |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) bt.txt ( 1) bt-2009-03-05.txt ( 2) malloc_debug.txt ( 3) valgrind.txt | |
Description: | An incoming ISDN call that is forwarded to a SIP connection by "exten => 295,1,Dial(SIP/2000)" and hung up immediately after the first ring (before the call was accepted) crashes asterisk. ****** ADDITIONAL INFORMATION ****** This is on a Slackware 12.1 with Kernel 2.6.24.5, mISDN-1.1.8, mISDNuser-1.1.8. The ISDN card is a AVM Fritz PCI in te_ptmp mode, connected to an Ascotel PBX. | ||
Comments: | By: Thomas Omerzu (t-o) 2008-11-06 04:07:35.000-0600 Additional Information: This problem is still present in 1.4.22. It also occurs when an incoming mISDN connection cannot be connected to the destination because it is busy. Most important notice: This seems ONLY TO HAPPEN if a CLI (asterisk -r) is connected!!! By: Matt Riddell (zx81) 2008-11-06 13:38:53.000-0600 Do you answer the call before sending it to the SIP connection? I.E. exten => 123,1,Answer() exten => 123,2,Dial(SIP/123) If not, does doing so fix it? By: Tilghman Lesher (tilghman) 2009-02-26 11:54:13.000-0600 This backtrace doesn't make any sense. Please turn on DONT_OPTIMIZE and produce another backtrace, as specified in doc/backtrace.txt. It may be that you need to run this under valgrind, as specified in doc/valgrind.txt. By: Thomas Omerzu (t-o) 2009-03-05 06:55:15.000-0600 Sorry, yes, you're right: the DONT_OPTIMIZE wasn't set in the first backtrace. I just uploaded a new one. Please note: the core was produced running an Asterisk 1.4.22; as the system is running productively, I'm unfortunately unable to roll it back to 1.4.21.2. The crash here occured when forwarding in incoming ISDN call to a busy ISDN destination. By: Thomas Omerzu (t-o) 2009-03-05 08:56:16.000-0600 Now I was also able to reproduce the problem while running under valgrind, see the respective uploads. By: Jeff Peeler (jpeeler) 2009-08-17 17:47:03 Is this still an issue? By: Thomas Omerzu (t-o) 2009-08-18 03:05:50 It surely is. Just last Friday we had several reproducible crashes due to that bug. We are currently running Asterisk 1.4.25 on mISDN 1.1.9 (the latter including the deadlock patch http://bugs.digium.com/view.php?id=14030). By: Jeff Peeler (jpeeler) 2009-08-18 14:57:23 Can you provide more information about how to reproduce? I'd like to see complete console output with verbosity level of at least 3 as well. If you can, show the case of "It also occurs when an incoming mISDN connection cannot be connected to the destination because it is busy." That eliminates the hang up timing from the mix. By: Russell Bryant (russell) 2009-09-10 22:21:52 I am suspending this issue for now. Feel free to reopen with the requested information. |