| Summary: | ASTERISK-11437: asterisk crashes when trying to make a call from SIP endpoint to h323 endpoint registered to gnugk | ||
| Reporter: | Ganbold (tsgan) | Labels: | |
| Date Opened: | 2008-02-14 03:44:39.000-0600 | Date Closed: | 2009-02-02 14:39:01.000-0600 |
| Priority: | Critical | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_h323 |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | asterisk crashes and segmentation faults with core dump when trying to make a call from SIP endpoint to h323 endpoint registered to gnugk. ****** ADDITIONAL INFORMATION ****** (gdb) bt #0 0x29057fbe in pthread_mutex_lock () from /lib/libthr.so.3 #1 0x080c6ed7 in ast_rtp_make_compatible () #2 0x29bfc23e in dial_exec_full (chan=0x29aea000, data=0xbef0fb38, peerflags=0xbef0dae4, continue_exec=0x0) at app_dial.c:1255 #3 0x29c00999 in dial_exec (chan=0x29aea000, data=0xbef0fb38) at app_dial.c:1808 #4 0x080bad86 in ast_add_extension2 () ASTERISK-1 0x080bc345 in ast_async_goto_by_name () ASTERISK-2 0x080bd012 in ast_pbx_run () ASTERISK-3 0x080e5c35 in ast_wait_for_input () ASTERISK-4 0x29053b1f in pthread_getprio () from /lib/libthr.so.3 ASTERISK-5 0x00000000 in ?? () (gdb) where #0 0x29057fbe in pthread_mutex_lock () from /lib/libthr.so.3 #1 0x080c6ed7 in ast_rtp_make_compatible () #2 0x29bfc23e in dial_exec_full (chan=0x29aea000, data=0xbef0fb38, peerflags=0xbef0dae4, continue_exec=0x0) at app_dial.c:1255 #3 0x29c00999 in dial_exec (chan=0x29aea000, data=0xbef0fb38) at app_dial.c:1808 #4 0x080bad86 in ast_add_extension2 () ASTERISK-1 0x080bc345 in ast_async_goto_by_name () ASTERISK-2 0x080bd012 in ast_pbx_run () ASTERISK-3 0x080e5c35 in ast_wait_for_input () ASTERISK-4 0x29053b1f in pthread_getprio () from /lib/libthr.so.3 ASTERISK-5 0x00000000 in ?? () (gdb) | ||
| Comments: | By: Ganbold (tsgan) 2008-02-14 03:51:48.000-0600 I'm on FreeBSD: daemon1# uname -an FreeBSD daemon1.micom.mng.net 7.0-RC1 FreeBSD 7.0-RC1 #0: Mon Dec 24 12:18:24 UTC 2007 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 daemon1# By: Sergey Tamkovich (sergee) 2008-02-14 04:45:44.000-0600 Related parts of sip.conf, h323.conf and extensions conf are required, also Asterisk's CLI output would be helpfull. To generate CLI output: 1. check your logger.conf, find a line starting with "console =>" and change it to "console => notice,warning,error,debug" 2. Start your asterisk with "asterisk -vvvvvc" 3. in asterisk CLI type "core set debug 10" 4. make a call 5. capture all output to a file and put it here By: Ganbold (tsgan) 2008-02-14 04:56:13.000-0600 h323.conf ; The NuFone Network's ; Open H.323 driver configuration ; [general] port = 1720 bindaddress=192.168.0.233 disallow=all allow=gsm ; Always allow GSM, it's cool :) allow=ulaw ; see doc/rtp-packetization for framing options allow=alaw allow=g723 allow=g729 allow=gsm gatekeeper = 192.168.0.18 sip.conf [general] context=default ; Default context for incoming calls allowoverlap=no ; Disable overlap dialing support. (Default is yes) bindport=5060 ; UDP Port to bind to (SIP standard port is 5060) bindaddr=0.0.0.0 ; IP address to bind to (0.0.0.0 binds to all) srvlookup=yes ; Enable DNS SRV lookups on outbound calls relaxdtmf=yes ; Relax dtmf handling [1100051] type=friend username=1100051 ;secret=4321 ;nat=yes host=dynamic context=default ;defaultip=192.168.0.120 canreinvite=no callerid=1100051 mailbox=1100051@local disallow=all allow=alaw allow=ulaw ;allow=gsm ;allow=g729 ;allow=g723 extention.conf [general] static=yes writeprotect=no clearglobalvars=no [globals] CONSOLE=Console/dsp ; Console interface for demo IAXINFO=guest ; IAXtel username/password TRUNK=Zap/g0 ; Trunk interface TRUNKMSD=1 ; MSD digits to strip (usually 1 or 0) [default] exten => s,1,Wait(2) exten => s,2,NoOp exten => s,3,NoOp(${CALLERID(all)}) exten => s,4,NoOp(${CALLERID(num)}) exten => s,5,Dial(SIP/804,45) exten => s,6,Hangup ; used to record prompts exten => 205,1,Wait(2) exten => 205,2,Record(/tmp/greetings:alaw) exten => 205,3,Wait(2) exten => 205,4,Playback(/tmp/greetings) exten => 205,5,Wait(2) exten => 205,6,Hangup exten => _001.,1,Dial(H323/${EXTEN}) exten => _10.,1,Dial(OOH323/${EXTEN}) exten => _5555.,1,Dial(OOH323/${EXTEN}) exten => _1111.,1,Dial(OOH323/${EXTEN}) exten => _005.,1,Dial(OOH323/${EXTEN}) exten => _11xxxxx,1,Dial(SIP/${EXTEN},3600,t) By: Ganbold (tsgan) 2008-02-14 04:58:44.000-0600 *CLI> core set debug 10 Core debug was 0 and is now 10 *CLI> [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: MWU1MTE4M2ExMWY4YzJlNTgxZTFjOTY3MGRjZWE3MWE. Their Tag 6562226e Our tag: as48b85f99 [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: 0faeb1f77aa740cf553f0ee20b60768a@192.168.0.233 Their Tag Our tag: as081a4aa1 [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: 099064814767f49327483c0c068e6278@192.168.0.233 Their Tag Our tag: as02800ee4 [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: 3b20c7bc50457bdc0f65290a626713cb@192.168.0.233 Their Tag Our tag: as56fe45f7 [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: 5ad3051b3dce62ac07a0ec525b68a0bf@192.168.0.233 Their Tag Our tag: as6e755389 [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: 4661e6b06c5f600170ae1f10368bf3e6@192.168.0.233 Their Tag Our tag: as02114351 [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: 4a7c19df602269665cfd96c9526ebd1e@192.168.0.233 Their Tag Our tag: as010be152 [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: 5f46266b34af8c8c4cdc5b9d5ac4e37e@192.168.0.233 Their Tag Our tag: as7544f211 [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: 5301eac03ae1b886653742933893157f@192.168.0.233 Their Tag Our tag: as7e85f5db [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: 53c7b46c05094cee768c584a6b81a274@192.168.0.233 Their Tag Our tag: as12b086af [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: 45ddd4d64495bbf97353a3aa103e8456@192.168.0.233 Their Tag Our tag: as432f33b7 [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: 757126553260e86a7d419dc87c934003@192.168.0.233 Their Tag Our tag: as3c2bb7bb [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:4506 sip_alloc: Allocating new SIP dialog for fXtmgphVKQDTvl8t@192.168.0.38 - REGISTER (No RTP) [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:15163 handle_request: **** Received REGISTER (2) - Command in SIP REGISTER -- Saved useragent "PHONE" for peer 1100051 [Feb 14 19:01:12] DEBUG[4681]: devicestate.c:304 __ast_device_state_changed_literal: Notification of state change to be queued on device/channel SIP/1100051 [Feb 14 19:01:12] DEBUG[4681]: devicestate.c:161 ast_device_state: No provider found, checking channel drivers for SIP - 1100051 [Feb 14 19:01:12] DEBUG[4681]: chan_sip.c:15797 sip_devicestate: Checking device state for peer 1100051 [Feb 14 19:01:12] DEBUG[4681]: devicestate.c:287 do_state_change: Changing state for SIP/1100051 - state 1 (Not in use) [Feb 14 19:01:12] DEBUG[4681]: app_queue.c:589 handle_statechange: Device 'SIP/1100051' changed to state '1' (Not in use) but we don't care because they're not a member of any queue. *CLI> [Feb 14 19:01:17] DEBUG[4681]: chan_sip.c:4506 sip_alloc: Allocating new SIP dialog for (No Call-ID) - NOTIFY (No RTP) [Feb 14 19:01:17] DEBUG[4681]: chan_sip.c:4559 find_call: = Found Their Call ID: 7d4f57dc787107bc66e65b45659a3325@192.168.0.233 Their Tag Our tag: as70d2f149 [Feb 14 19:01:17] DEBUG[4681]: chan_sip.c:2169 __sip_ack: Stopping retransmission on '7d4f57dc787107bc66e65b45659a3325@192.168.0.233' of Request 102: Match Not Found Really destroying SIP dialog '7d4f57dc787107bc66e65b45659a3325@192.168.0.233' Method: NOTIFY [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog '757126553260e86a7d419dc87c934003@192.168.0.233' [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog 757126553260e86a7d419dc87c934003@192.168.0.233 Really destroying SIP dialog '757126553260e86a7d419dc87c934003@192.168.0.233' Method: NOTIFY [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog '45ddd4d64495bbf97353a3aa103e8456@192.168.0.233' [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog 45ddd4d64495bbf97353a3aa103e8456@192.168.0.233 Really destroying SIP dialog '45ddd4d64495bbf97353a3aa103e8456@192.168.0.233' Method: NOTIFY [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog '53c7b46c05094cee768c584a6b81a274@192.168.0.233' [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog 53c7b46c05094cee768c584a6b81a274@192.168.0.233 Really destroying SIP dialog '53c7b46c05094cee768c584a6b81a274@192.168.0.233' Method: NOTIFY [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog '5301eac03ae1b886653742933893157f@192.168.0.233' [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog 5301eac03ae1b886653742933893157f@192.168.0.233 Really destroying SIP dialog '5301eac03ae1b886653742933893157f@192.168.0.233' Method: NOTIFY [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog '5f46266b34af8c8c4cdc5b9d5ac4e37e@192.168.0.233' [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog 5f46266b34af8c8c4cdc5b9d5ac4e37e@192.168.0.233 Really destroying SIP dialog '5f46266b34af8c8c4cdc5b9d5ac4e37e@192.168.0.233' Method: NOTIFY [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog '4a7c19df602269665cfd96c9526ebd1e@192.168.0.233' [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog 4a7c19df602269665cfd96c9526ebd1e@192.168.0.233 Really destroying SIP dialog '4a7c19df602269665cfd96c9526ebd1e@192.168.0.233' Method: NOTIFY [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog '4661e6b06c5f600170ae1f10368bf3e6@192.168.0.233' [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog 4661e6b06c5f600170ae1f10368bf3e6@192.168.0.233 Really destroying SIP dialog '4661e6b06c5f600170ae1f10368bf3e6@192.168.0.233' Method: NOTIFY [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog '5ad3051b3dce62ac07a0ec525b68a0bf@192.168.0.233' [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog 5ad3051b3dce62ac07a0ec525b68a0bf@192.168.0.233 Really destroying SIP dialog '5ad3051b3dce62ac07a0ec525b68a0bf@192.168.0.233' Method: NOTIFY [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog '3b20c7bc50457bdc0f65290a626713cb@192.168.0.233' [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog 3b20c7bc50457bdc0f65290a626713cb@192.168.0.233 Really destroying SIP dialog '3b20c7bc50457bdc0f65290a626713cb@192.168.0.233' Method: NOTIFY [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog '099064814767f49327483c0c068e6278@192.168.0.233' [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog 099064814767f49327483c0c068e6278@192.168.0.233 Really destroying SIP dialog '099064814767f49327483c0c068e6278@192.168.0.233' Method: NOTIFY [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog '0faeb1f77aa740cf553f0ee20b60768a@192.168.0.233' [Feb 14 19:01:25] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog 0faeb1f77aa740cf553f0ee20b60768a@192.168.0.233 Really destroying SIP dialog '0faeb1f77aa740cf553f0ee20b60768a@192.168.0.233' Method: NOTIFY [Feb 14 19:01:26] DEBUG[4681]: chan_sip.c:2090 __sip_autodestruct: Auto destroying SIP dialog 'MWU1MTE4M2ExMWY4YzJlNTgxZTFjOTY3MGRjZWE3MWE.' [Feb 14 19:01:26] DEBUG[4681]: chan_sip.c:3280 sip_destroy: Destroying SIP dialog MWU1MTE4M2ExMWY4YzJlNTgxZTFjOTY3MGRjZWE3MWE. Really destroying SIP dialog 'MWU1MTE4M2ExMWY4YzJlNTgxZTFjOTY3MGRjZWE3MWE.' Method: REGISTER [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:4559 find_call: = No match Their Call ID: fXtmgphVKQDTvl8t@192.168.0.38 Their Tag NXUSwtKMEQge1EyN Our tag: as17cccbf3 [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:2732 do_setnat: Setting NAT on RTP to Off [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:4506 sip_alloc: Allocating new SIP dialog for qxiNiMz1gt6w4V0i@192.168.0.38 - INVITE (With RTP) [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:15163 handle_request: **** Received INVITE (5) - Command in SIP INVITE [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:2732 do_setnat: Setting NAT on RTP to Off [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:5399 process_sdp: T38 state changed to 0 on channel <none> [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:5488 process_sdp: We're settling with these formats: 0xc (ulaw|alaw) [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:13843 handle_request_invite: Checking SIP call limits for device 1100051 [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:3171 update_call_counter: Updating call counter for incoming call [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:4025 sip_new: This channel will not be able to handle video. [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:8279 build_route: build_route: Contact hop: <sip:1100051@192.168.0.38:5060> [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:13922 handle_request_invite: SIP/1100051-29ad0000: New call is still down.... Trying... [Feb 14 19:01:27] DEBUG[4681]: devicestate.c:304 __ast_device_state_changed_literal: Notification of state change to be queued on device/channel SIP/1100051-29ad0000 [Feb 14 19:01:27] DEBUG[4681]: devicestate.c:161 ast_device_state: No provider found, checking channel drivers for SIP - 1100051 [Feb 14 19:01:27] DEBUG[4681]: chan_sip.c:15797 sip_devicestate: Checking device state for peer 1100051 [Feb 14 19:01:27] DEBUG[4681]: devicestate.c:287 do_state_change: Changing state for SIP/1100051 - state 1 (Not in use) [Feb 14 19:01:27] DEBUG[4681]: pbx.c:1831 pbx_extension_helper: Launching 'Dial' -- Executing [0011002@default:1] Dial("SIP/1100051-29ad0000", "H323/0011002") in new stack [Feb 14 19:01:27] DEBUG[4681]: app_queue.c:589 handle_statechange: Device 'SIP/1100051' changed to state '1' (Not in use) but we don't care because they're not a member of any queue. Segmentation fault (core dumped) daemon1# By: Ganbold (tsgan) 2008-02-14 20:46:43.000-0600 calling from h323 to sip endpoint makes core dump again. *CLI> [Feb 15 10:48:06] DEBUG[8324]: pbx.c:1831 pbx_extension_helper: Launching 'Dial' -- Executing [1100051@default:1] Dial("H323/ip$192.168.0.18:20001/1636", "SIP/1100051|3600|t") in new stack [Feb 15 10:48:06] DEBUG[8324]: chan_sip.c:4506 sip_alloc: Allocating new SIP dialog for (No Call-ID) - INVITE (With RTP) [Feb 15 10:48:06] DEBUG[8324]: chan_sip.c:2732 do_setnat: Setting NAT on RTP to Off [Feb 15 10:48:06] DEBUG[8324]: chan_sip.c:4025 sip_new: This channel will not be able to handle video. Segmentation fault (core dumped) daemon1# gdb asterisk asterisk.core (gdb) bt #0 0x29057fbe in pthread_mutex_lock () from /lib/libthr.so.3 #1 0x080c6ee8 in ast_rtp_make_compatible () #2 0x29bfc23e in dial_exec_full (chan=0x29e3a000, data=0xbed4ab38, peerflags=0xbed48ae4, continue_exec=0x0) at app_dial.c:1255 #3 0x29c00999 in dial_exec (chan=0x29e3a000, data=0xbed4ab38) at app_dial.c:1808 #4 0x080bad86 in ast_add_extension2 () ASTERISK-1 0x080bc345 in ast_async_goto_by_name () ASTERISK-2 0x080bd012 in ast_pbx_run () ASTERISK-3 0x080e5c35 in ast_wait_for_input () ASTERISK-4 0x29053b1f in pthread_getprio () from /lib/libthr.so.3 ASTERISK-5 0x00000000 in ?? () (gdb) By: Digium Subversion (svnbot) 2008-02-29 17:30:56.000-0600 Repository: asterisk Revision: 105409 U branches/1.4/main/autoservice.c ------------------------------------------------------------------------ r105409 | russell | 2008-02-29 17:30:48 -0600 (Fri, 29 Feb 2008) | 23 lines Fix a major bug in autoservice. There was a race condition in the handling of the list of channels in autoservice. The problem was that it was possible for a channel to get removed from autoservice and destroyed, while the autoservice was still messing with the channel. This led to memory corruption, and caused crashes. This explains multiple backtraces I have seen that have references to autoservice, but do to the nature of the issue (memory corruption), could cause crashes in a number of areas. (fixes the crash in BE-386) (closes issue ASTERISK-11165) (closes issue ASTERISK-11391) The following issues could be related. If you are the reporter of one of these, please update to include this fix and try again. (potentially fixes issue ASTERISK-10713) (potentially fixes issue ASTERISK-11545) (potentially fixes issue ASTERISK-11058) (potentially fixes issue ASTERISK-11453) (potentially fixes issue ASTERISK-10713) (potentially fixes issue ASTERISK-11437) (potentially fixes issue ASTERISK-11259) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=105409 By: Digium Subversion (svnbot) 2008-02-29 17:33:02.000-0600 Repository: asterisk Revision: 105410 _U trunk/ U trunk/main/autoservice.c ------------------------------------------------------------------------ r105410 | russell | 2008-02-29 17:33:00 -0600 (Fri, 29 Feb 2008) | 31 lines Merged revisions 105409 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105409 | russell | 2008-02-29 17:34:32 -0600 (Fri, 29 Feb 2008) | 23 lines Fix a major bug in autoservice. There was a race condition in the handling of the list of channels in autoservice. The problem was that it was possible for a channel to get removed from autoservice and destroyed, while the autoservice was still messing with the channel. This led to memory corruption, and caused crashes. This explains multiple backtraces I have seen that have references to autoservice, but do to the nature of the issue (memory corruption), could cause crashes in a number of areas. (fixes the crash in BE-386) (closes issue ASTERISK-11165) (closes issue ASTERISK-11391) The following issues could be related. If you are the reporter of one of these, please update to include this fix and try again. (potentially fixes issue ASTERISK-10713) (potentially fixes issue ASTERISK-11545) (potentially fixes issue ASTERISK-11058) (potentially fixes issue ASTERISK-11453) (potentially fixes issue ASTERISK-10713) (potentially fixes issue ASTERISK-11437) (potentially fixes issue ASTERISK-11259) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=105410 By: Digium Subversion (svnbot) 2008-02-29 17:57:04.000-0600 Repository: asterisk Revision: 105409 U branches/1.4/main/autoservice.c ------------------------------------------------------------------------ r105409 | russell | 2008-02-29 17:34:32 -0600 (Fri, 29 Feb 2008) | 23 lines Fix a major bug in autoservice. There was a race condition in the handling of the list of channels in autoservice. The problem was that it was possible for a channel to get removed from autoservice and destroyed, while the autoservice thread was still messing with the channel. This led to memory corruption, and caused crashes. This explains multiple backtraces I have seen that have references to autoservice, but do to the nature of the issue (memory corruption), could cause crashes in a number of areas. (fixes the crash in BE-386) (closes issue ASTERISK-11165) (closes issue ASTERISK-11391) The following issues could be related. If you are the reporter of one of these, please update to include this fix and try again. (potentially fixes issue ASTERISK-10713) (potentially fixes issue ASTERISK-11545) (potentially fixes issue ASTERISK-11058) (potentially fixes issue ASTERISK-11453) (potentially fixes issue ASTERISK-10713) (potentially fixes issue ASTERISK-11437) (potentially fixes issue ASTERISK-11259) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=105409 By: Digium Subversion (svnbot) 2008-02-29 17:57:35.000-0600 Repository: asterisk Revision: 105410 _U trunk/ U trunk/main/autoservice.c ------------------------------------------------------------------------ r105410 | russell | 2008-02-29 17:36:46 -0600 (Fri, 29 Feb 2008) | 31 lines Merged revisions 105409 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105409 | russell | 2008-02-29 17:34:32 -0600 (Fri, 29 Feb 2008) | 23 lines Fix a major bug in autoservice. There was a race condition in the handling of the list of channels in autoservice. The problem was that it was possible for a channel to get removed from autoservice and destroyed, while the autoservice thread was still messing with the channel. This led to memory corruption, and caused crashes. This explains multiple backtraces I have seen that have references to autoservice, but do to the nature of the issue (memory corruption), could cause crashes in a number of areas. (fixes the crash in BE-386) (closes issue ASTERISK-11165) (closes issue ASTERISK-11391) The following issues could be related. If you are the reporter of one of these, please update to include this fix and try again. (potentially fixes issue ASTERISK-10713) (potentially fixes issue ASTERISK-11545) (potentially fixes issue ASTERISK-11058) (potentially fixes issue ASTERISK-11453) (potentially fixes issue ASTERISK-10713) (potentially fixes issue ASTERISK-11437) (potentially fixes issue ASTERISK-11259) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=105410 By: Ganbold (tsgan) 2008-03-03 04:35:26.000-0600 do you have patch for asterisk-1.4.17 ? thanks By: Ganbold (tsgan) 2008-03-03 22:48:49.000-0600 #0 0x2939755b in pthread_testcancel () from /lib/libpthread.so.2 [New Thread 0x86d0800 (runnable)] [New Thread 0x86d0400 (runnable)] [New Thread 0x8683c00 (runnable)] [New Thread 0x8683a00 (runnable)] [New Thread 0x8683800 (runnable)] [New Thread 0x8683600 (runnable)] [New Thread 0x8683400 (runnable)] [New Thread 0x8683200 (runnable)] [New Thread 0x8683000 (runnable)] [New Thread 0x8666e00 (runnable)] [New Thread 0x8666c00 (runnable)] [New Thread 0x8666a00 (runnable)] [New Thread 0x8666800 (runnable)] [New Thread 0x8666600 (sleeping)] [New Thread 0x8666400 (sleeping)] [New Thread 0x8666200 (sleeping)] [New Thread 0x8666000 (sleeping)] [New Thread 0x8646e00 (sleeping)] [New Thread 0x8646c00 (sleeping)] [New Thread 0x8646a00 (sleeping)] [New Thread 0x8646800 (sleeping)] [New Thread 0x8646600 (sleeping)] [New Thread 0x8646400 (sleeping)] [New Thread 0x8646200 (sleeping)] [New Thread 0x81a8a00 (runnable)] [New Thread 0x81a8e00 (runnable)] [New Thread 0x81a8800 (sleeping)] [New Thread 0x81a8200 (runnable)] [New Thread 0x8189e00 (sleeping)] [New Thread 0x8189400 (runnable)] [New Thread 0x8148e00 (sleeping)] [New Thread 0x8148800 (runnable)] [New Thread 0x8148400 (LWP 100087)] [New Thread 0x8148000 (runnable)] [New LWP 100106] (gdb) bt #0 0x2939755b in pthread_testcancel () from /lib/libpthread.so.2 #1 0x08067a2c in ast_console_puts () #2 0x080e41c3 in ast_inet_ntoa () #3 0x293883c9 in pthread_create () from /lib/libpthread.so.2 #4 0x29446837 in _ctx_start () from /lib/libc.so.6 (gdb) where #0 0x2939755b in pthread_testcancel () from /lib/libpthread.so.2 #1 0x08067a2c in ast_console_puts () #2 0x080e41c3 in ast_inet_ntoa () #3 0x293883c9 in pthread_create () from /lib/libpthread.so.2 #4 0x29446837 in _ctx_start () from /lib/libc.so.6 (gdb) By: Jason Parker (jparker) 2008-05-01 17:09:47 Please retest with the revisions specified in the comments, and report back with results. By: Ganbold (tsgan) 2008-05-01 21:51:23 Which revision? I tried rev 105409, 105410, and it didn't work that time. By: Leif Madsen (lmadsen) 2008-10-07 13:35:21 Is this still an issue on the latest version of Asterisk 1.4.x? There appears to be fixes for several bugs, one of which is this one that is still open with no update for a long time. If you are still getting crashes, please attach a new backtrace with the DONT_OPTIMIZE flag enabled in menuselect. I will leave this open for a couple of weeks before closing. Thanks! By: Sergey Tamkovich (sergee) 2008-10-21 06:20:28 tsgan, any feedback? Have you tryed latest version of asterisk from 1.4 branch? i'm very interested in your results too. By: Leif Madsen (lmadsen) 2008-10-22 09:58:02 tsgan: Can I tempt you into doing some more testing here for some karma? :) By: Leif Madsen (lmadsen) 2009-02-02 14:39:00.000-0600 This issue has been open for a very long time with no feedback. If you are able to produce the information required, then please find a bug marshal to reopen the issue in #asterisk-bugs on the Freenode IRC network at irc.freenode.net. Thanks! | ||