Summary:	ASTERISK-07817: Asterisk startup hangs when registering first function
Reporter:	Steven Sokol (ssokol)	Labels:
Date Opened:	2006-09-25 08:58:42	Date Closed:	2006-10-06 16:29:56
Priority:	Blocker	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) linkedlists.h.patch
Description:	When starting Asterisk on my MacBook Pro (MacIntel) the load process hangs when processing the first module which registers a custom function.  The system does not "lock up" (i.e. you can still connect using asterisk -r) but the loading thread hangs. Kevin looked at this at VON a few weeks ago and decided it was likely some difference between the lock initialization method used on Mac vs. other -nix variants. ****** ADDITIONAL INFORMATION ****** Jared Smith, who's running Mac OS X on PPC indicates that the same occurs on that platform as well.
Comments:	By: Jason Parker (jparker) 2006-09-25 20:25:37 and Solaris By: timrobbins (timrobbins) 2006-09-28 18:13:05 It really does look like a difference in the way mutexes are initialized. Asterisk deadlocks on startup when ast_custom_function_register() calls ast_custom_function_find() while holding the acf_root list lock held. ast_custom_function_find() then goes to lock the list again, but this results in deadlock presumably because the mutex somehow has not been initialized as a recursive mutex. I'll investigate further. By: timrobbins (timrobbins) 2006-09-28 19:18:47 I've uploaded a patch that fixes the problem for me (on Solaris). The mutexes in lists defined with AST_LIST_HEAD_STATIC were not being initialized with a call to ast_mutex_init(), which is required in the AST_MUTEX_INIT_W_CONSTRUCTORS case (Solaris, BSD). The patch adds static constructors and destructors that call AST_LIST_HEAD_INIT and AST_LIST_HEAD_DESTROY; these two macros do result in calls to ast_mutex_init(), which initializes the mutex correctly and allows recursion. By: Jason Parker (jparker) 2006-09-28 20:40:47 timrobbins, can you verify you have a disclaimer on file? By: timrobbins (timrobbins) 2006-09-28 20:49:53 No disclaimer, sorry, and probably not able to sign one at this point :( Someone else who has filed a disclaimer might have to redo this patch. It's fairly trivial - the list is initialized using the same technique that lock.h uses to initialize mutexes. By: Kevin P. Fleming (kpfleming) 2006-10-06 16:29:55 Patch committed to branch 1.4 in revision 44631 and trunk revision 44632. No disclaimer was needed for this patch. Thanks for the fix!