Summary:ASTERISK-07817: Asterisk startup hangs when registering first function
Reporter:Steven Sokol (ssokol)Labels:
Date Opened:2006-09-25 08:58:42Date Closed:2006-10-06 16:29:56
Versions:Frequency of
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.


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!