[Home]

Summary:ASTERISK-10647: [patch] *BSD mutex lock issue
Reporter:Yuri (ys)Labels:
Date Opened:2007-10-30 09:04:29Date Closed:2008-06-04 08:28:39
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/Portability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) lock.h.diff
( 1) lock.h.v2.diff
( 2) lock.h.v3.diff
Description:This is BSD specific issue.

If asterisk compiled on BSD, then used AST_MUTEX_INIT_W_CONSTRUCTORS definition.
In this case asterisk used gcc constructor/destructor for creation statically defined mutexes and linklists.

linklist struct may depend at external mutexes, by calling some function what use it (lock/unlock).
And. But constructor order of calls is unknown (chaotic), some statically mutex can be uninitialized at
the moment when these function was called.
In result we got sigfault in BSD, when ast_mutex_lock/ast_mutex_unlock are called with uninitialized
mutexes (reference to NULL pointer), except Linux (where used reference to structure) ast_mutex_lock
can use uninitialized mutex object.

The same may be applied to orders of destructors functions call.

As result I periodically see "Segmentation fault (core dumped)", mainly at load/unload/reload CLI commands.

To resolve this problem, as one of the possible ways: init uninitialized mutex on first request,
as in linux system for statically defined mutexes.

I upload the diff where realize these (BSD platform).
If someone tries to use not initialized mutex, initialize them.
If called init for already initialized mutex, function simply exit.
If try to destroy uninitialized mutex, function simply exit.

Also, I add some debug stuff into rwlock processing, if compiled with DEBUG_THREADS option.


Path affected this file:
include/asterisk/lock.h

****** ADDITIONAL INFORMATION ******

Debug info (DEBUG_THREADS & MALLOC_DEBUG enabled).

at start:

./sbin/asterisk -cvvvvd
astmm.c line 119 (__ast_alloc_region): Error: mutex '&reglock' is uninitialized.
asterisk.c line 270 (ast_register_file_version): Error: mutex '&(&file_versions)->lock' is uninitialized.
astmm.c line 84 (init_reglock): Error: mutex '&reglock' is already initialized.
asterisk.c line 252 (init_file_versions): Error: mutex '&(&file_versions)->lock' is already initialized.
(null) line 0 ((null)): Error: previously initialization of mutex '&(&file_versions)->lock'.
...


at stop:

*CLI>stop now
Beginning asterisk shutdown....
Executing last minute cleanups
 == Destroying musiconhold processes
Asterisk cleanly ending (0).
WARNING: Freeing unused memory at 0x0, in lock_info_destroy of utils.c, line 578
WARNING: Freeing unused memory at 0x0, in lock_info_destroy of utils.c, line 578
WARNING: Freeing unused memory at 0x0, in lock_info_destroy of utils.c, line 578
Thread 81de400 has exited with leftover thread-specific data after 4 deasterisk.c line 279 (ast_unregister_file_version): Error: mutex '&(&file_versions)->lock' is uninitialized.
structor iterations
astmm.c line 119 (__ast_alloc_region): Error: mutex '&reglock' is uninitialized.
[Oct 30 14:48:22] ERROR[96841]: /home/asterisk2/src/asterisk-1.4/include/asterisk/lock.h:315 __ast_pthread_mutex_lock: asterisk.c line 321 (ast_unregister_thread): Error: mutex '&(&thread_list)->lock' is uninitialized.
devicestate.c line 86 (fini_state_changes): Error destroying mutex: Device busy
WARNING: Freeing unused memory at 0x0, in lock_info_destroy of utils.c, line 578
WARNING: Freeing unused memory at 0x0, in lock_info_destroy of utils.c, line 578
loader.c line 161 (ast_module_unregister): Error: mutex '&(&module_list)->lock' is uninitialized.
threadstorage.c line 69 (__ast_threadstorage_object_add): Error: mutex '&(&tls_objects)->lock' is uninitialized.
WARNING: Freeing unused memory at 0x0, in lock_info_destroy of utils.c, line 578
Thread 818fe00 has exited with leftover thread-specific data after 4 destructor iterations
Comments:By: Yuri (ys) 2007-10-30 09:06:55

Incomplete "Summary", please correct: *BSD mutex lock issue


By: Yuri (ys) 2007-10-30 09:10:32

I'm use this patch on produktion office machine (1.4.13), 7 days with no core dumps.
By: Digium Subversion (svnbot) 2007-10-30 18:00:52

Repository: asterisk
Revision: 87739

U   branches/1.4/include/asterisk/lock.h

------------------------------------------------------------------------
r87739 | tilghman | 2007-10-30 18:00:52 -0500 (Tue, 30 Oct 2007) | 5 lines

Fix for uninitialized mutexes on *BSD
Reported by: ys
Fixed by: ys
Closes issue ASTERISK-10647

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-10-30 18:07:16

Repository: asterisk
Revision: 87740

_U  trunk/
U   trunk/include/asterisk/lock.h

------------------------------------------------------------------------
r87740 | tilghman | 2007-10-30 18:07:16 -0500 (Tue, 30 Oct 2007) | 13 lines

Merged revisions 87739 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r87739 | tilghman | 2007-10-30 18:02:22 -0500 (Tue, 30 Oct 2007) | 5 lines

Fix for uninitialized mutexes on *BSD
Reported by: ys
Fixed by: ys
Closes issue ASTERISK-10647

........

------------------------------------------------------------------------
By: Russell Bryant (russell) 2007-11-06 08:23:41.000-0600

I reverted changes from here because they broke the build on mac, and they did not appear to be the right way to fix the problem.  I will investigate the issue further later today.
By: Yuri (ys) 2007-11-06 12:25:46.000-0600

I upload _test_ patch, only for DEBUG_THREADS options.
By: Yuri (ys) 2007-11-07 08:04:56.000-0600

I upload new patch for compiling with DEBUG_THREADS options.
There I replace comparison with != and == operators to binary safe memcmp() funtion.

memcmp() can compare pointer and structore memory region, independently at, how to pthread_mutex_t defined in system.
By: jmls (jmls) 2008-05-03 14:15:50

ping. housekeeping
By: Yuri (ys) 2008-05-20 07:31:32

please, delete file lock.v4.diff - wrong issue.
By: Michiel van Baak (mvanbaak) 2008-05-20 07:43:22

done
By: Yuri (ys) 2008-06-04 08:22:18

Please close this issue.
resolved in ASTERISK-1121279
By: Michiel van Baak (mvanbaak) 2008-06-04 08:28:36

closed on reporters request