| Summary: | ASTERISK-17686: [patch] Deadlock ao2_callback / ast_write / handle_incoming | ||
| Reporter: | Gregory Hinton Nietsky (irroot) | Labels: | |
| Date Opened: | 2011-04-13 03:10:05 | Date Closed: | 2011-05-23 09:48:58 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | 1.8.3 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) sip_lock.diff ( 1) sip_lock2.diff | |
| Description: | Channel walk is contending a lock on a channel held by ast_write while sip_write is contending a private lock held by handle incoming that is contending the channel lock held by the write ... now if i was holding the channel lock in handle_incoming before i locked private this would not happen ... ****** ADDITIONAL INFORMATION ****** === Thread ID: 0xb3cf7b70 (do_devstate_changes started at [ 724] devicestate.c ast_device_state_engine_init()) === ---> Lock #0 (astobj2.c): MUTEX 657 internal_ao2_callback c 0x85fe1b8 (1) === ---> Waiting for Lock #1 (channel.c): MUTEX 1641 ast_channel_cmp_cb chan 0xabb7a558 (1) === --- ---> Locked Here: channel.c line 4690 (ast_write) === ------------------------------------------------------------------- === === Thread ID: 0xabf3fb70 (do_monitor started at [24621] chan_sip.c restart_monitor()) === ---> Lock #0 (chan_sip.c): MUTEX 24593 do_monitor &monlock 0xb314fde0 (1) === ---> Lock #1 (chan_sip.c): MUTEX 23781 handle_incoming p 0xab7c94a8 (1) === ---> Waiting for Lock #2 (channel.c): MUTEX 1361 __ast_queue_frame chan 0xabb7a558 (1) === --- ---> Locked Here: channel.c line 4690 (ast_write) === ------------------------------------------------------------------- === === Thread ID: 0xab6c3b70 (pbx_thread started at [ 5038] pbx.c ast_pbx_start()) === ---> Lock #0 (channel.c): MUTEX 4690 ast_write chan 0xabb7a558 (1) === ---> Waiting for Lock #1 (chan_sip.c): MUTEX 6083 sip_write p 0xab7c94a8 (1) === --- ---> Locked Here: chan_sip.c line 23781 (handle_incoming) === ------------------------------------------------------------------- === | ||
| Comments: | By: Gregory Hinton Nietsky (irroot) 2011-04-13 05:25:34 the first patch was a quick and dirty does not work and breaks things bad ... the second patch is a bit better thought out and may fix this and ASTERISK-17681 By: Steve Davies (one47) 2011-05-19 06:55:04 The patch is probably a reasonable response, but is fixing "innocent" functions, which are getting the locks in the correct order, and therefore should be safe. Since this issue was raised, https://reviewboard.asterisk.org/r/1182/ looks as if it may fix the root cause, and this is already applied to 1.8 trunk AFAIK. This has prompted me to provide a 1.6 equivalent patch, which I will raise separately. By: Leif Madsen (lmadsen) 2011-05-23 09:48:58 I'm closing this issue as it appears the core issue has already been resolved in Asterisk 1.8. Thanks! | ||