|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|
|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|
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!