[test-results] [Bamboo] Asterisk - 1.4 > Ubuntu Lucid (10.04) > #20 > amd64 was SUCCESSFUL (with 42 tests). Change made by Tilghman Lesher.

[Bamboo]

-------------- next part --------------
----------------------------------------------------------------------------
Asterisk - 1.4 > Ubuntu Lucid (10.04) > #20 > amd64 was successful.
----------------------------------------------------------------------------
Code has been updated by Tilghman Lesher.
42 tests in total.

http://bamboo.asterisk.org/browse/AST14-LUCID-AMD64-20/        


--------------
Code Changes
--------------
Tilghman Lesher (296867):

>Get rid of the annoying startup and shutdown errors on OS X.
>
>This mainly deals with the problem of constructors on platforms where an
>explicit constructor order cannot be specified (any system with gcc 4.2
>or less).  However, this is only a problem on those systems where we need
>to initialize mutexes with a constructor, because we have other code that
>also relies upon constructors, and we cannot specify that mutexes are
>initialized first (and destroyed last).
>
>There are two approaches to dealing with this issue, related to whether the
>code exists in the core Asterisk binary or in a separate code module.  In the
>core case, constructors are run immediately upon load, and the file_versions
>list mutex needs to be already initialized, as it is referenced in the first
>constructor within each core source file.  In this case, we use pthread_once
>to ensure that the mutex is initialized immediately before it is used for the
>first time.  The only caveat is that the mutex is not ever destroyed, but
>because this is the core, it makes no real difference; the only time when
>destruction is safe would be just prior to process destruction, which takes
>care of that anyway.  And due to using pthread_once, the mutex will never be
>reinitialized, which means only one structure has leaked at the end of the
>process.  Hence, it is not a problematic leak.
>
>The second approach is to use the load_module and unload_module routines,
>which, for obvious reasons, exist only in loadable modules.  In this second
>case, we don't have a problem with the constructors, but only with destructor
>order, because mutexes can be destroyed before their final usage is employed.
>However, we need the mutexes to still be destroyed, in certain scenarios:  if
>the module is unloaded prior to the process ending, it should be clean, with
>no allocations by the module hanging around after that point in time.
>


--------------
Error Summary
--------------
   make[1]: *** [h323/libchanh323.a] Error 1
   make: *** [channels] Error 2


--
This message is automatically generated by Atlassian Bamboo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/test-results/attachments/20101130/c22fad9c/attachment.htm