Summary:	ASTERISK-14685: [patch] Thread debugging version of DEADLOCK_AVOIDANCE: wrong line number if re-lock fails.
Reporter:	David Woolley (davidw)	Labels:
Date Opened:	2009-08-20 13:33:45	Date Closed:	2011-06-07 14:07:49
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20090903__issue15752.diff.txt
Description:	As described in ASTERISK-14304, if the mutex referenced by DEADLOCK_AVOIDANCE goes away, the "Error obtaining mutex: Invalid argument" error message reports the line number where the lock was originally obtained, not that of the failure. This is because DEADLOCK_AVOIDANCE takes special steps to retain the original line number.  I believe the intent of this is for accurate tracing of deadlock origins, but I believe that it should be reporting the actual line number if the actual re-lock call fails. ****** ADDITIONAL INFORMATION ****** This resulted in a lot of time being spent looking for failure scenarios that could result in a crash at the original locking point.  In the case in question, there were non-local errors that could have actually produced that effect, so it was not possible to eliminate the case by looking at just the code around the actual failure. Version was 1.6.1.0.
Comments:	By: David Woolley (davidw) 2009-09-07 12:19:10 Failed to build on 1.6.1.0.  (Applied at offset -7.) [root@centos code]# LANG=C make -k menuselect/menuselect --check-deps menuselect.makeopts   Generating embedded module rules ...   [CC] astobj2.c -> astobj2.o astobj2.c: In function '_ao2_lock': astobj2.c:160: warning: passing argument 5 of '__ast_pthread_mutex_lock' makes integer from pointer without a cast astobj2.c:160: error: too few arguments to function '__ast_pthread_mutex_lock' astobj2.c:162: warning: control reaches end of non-void function astobj2.c: In function '_ao2_trylock': astobj2.c:200: warning: passing argument 5 of '__ast_pthread_mutex_trylock' makes integer from pointer without a cast astobj2.c:200: error: too few arguments to function '__ast_pthread_mutex_trylock' make[1]: *** [astobj2.o] Error 1 make[1]: Target `all' not remade because of errors. make: *** [utils] Error 2   [CC] chan_dahdi.c -> chan_dahdi.o chan_dahdi.c: In function 'dahdi_bridge': chan_dahdi.c:4171: warning: passing argument 5 of '__ast_pthread_mutex_lock' makes integer from pointer without a cast chan_dahdi.c:4171: error: too few arguments to function '__ast_pthread_mutex_lock' chan_dahdi.c:4341: warning: passing argument 5 of '__ast_pthread_mutex_lock' makes integer from pointer without a cast chan_dahdi.c:4341: error: too few arguments to function '__ast_pthread_mutex_lock' chan_dahdi.c: In function 'dahdi_handle_event': chan_dahdi.c:4881: warning: passing argument 5 of '__ast_pthread_mutex_lock' makes integer from pointer without a cast chan_dahdi.c:4881: error: too few arguments to function '__ast_pthread_mutex_lock' chan_dahdi.c: In function 'dahdi_read': chan_dahdi.c:5632: warning: passing argument 5 of '__ast_pthread_mutex_lock' makes integer from pointer without a cast chan_dahdi.c:5632: error: too few arguments to function '__ast_pthread_mutex_lock' make[1]: *** [chan_dahdi.o] Error 1   [CC] chan_local.c -> chan_local.o chan_local.c: In function 'local_queue_frame': chan_local.c:223: warning: passing argument 5 of '__ast_pthread_mutex_lock' makes integer from pointer without a cast chan_local.c:223: error: too few arguments to function '__ast_pthread_mutex_lock' make[1]: *** [chan_local.o] Error 1 make[1]: Target `all' not remade because of errors. make: *** [channels] Error 2 make: Target `all' not remade because of errors. By: David Woolley (davidw) 2010-02-26 05:52:52.000-0600 Just a reminder.  This would not build for testing. By: Paul Belanger (pabelanger) 2010-07-24 21:25:15 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.6.0 and 1.6.1 branches has ended. For continued maintenance support please move to the 1.6.2 branch. More information on this change can be found in the release announcement: http://www.asterisk.org/node/49924 By: David Woolley (davidw) 2010-07-26 04:20:13 At the time I tried to test this, 1.6.1.0 was not EOL. The benefit in fixing this is for the wider Asterisk community, as it will help in debugging; I'm not sure that I can justify setting up a 1.6.2 test rig for an issue that is relatively unlikely to affect us in future (we now know the line numbers are unreliable and can compensate). By: Paul Belanger (pabelanger) 2010-09-04 14:14:26 Unless somebody moves this forward into trunk, the issue will likely get suspended. By: David Woolley (davidw) 2010-09-06 05:52:00 As this compromises debugging, rather than operation, and will need faults simulating to test it, I don't think I will be able to justify spending time on a version we are unlikely to use in the near future.  Our current policy is not to consider changing the base Asterisk version at least until 1.8 is mature. By: Leif Madsen (lmadsen) 2011-04-06 08:09:43 I'm suspending this issue, but if it is run into in the future please reopen.