[asterisk-bugs] [Asterisk 0011116]: [patch] *BSD

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11116 
====================================================================== 
Reported By:                ys
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11116
Category:                   Core-General
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 87498 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-30-2007 09:04 CDT
Last Modified:              10-30-2007 09:06 CDT
====================================================================== 
Summary:                    [patch] *BSD
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
====================================================================== 

---------------------------------------------------------------------- 
 ys - 10-30-07 09:06  
---------------------------------------------------------------------- 
Incomplete "Summary", please add: *BSD mutex lock issue 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-30-07 09:06  ys             Note Added: 0072724                          
======================================================================