[test-results] [Bamboo] Asterisk Testing > Asterisk 1.8 Branch > #474 has FAILED (1 tests failed, no failures were new). Change made by Matthew Jordan.

[Bamboo]

-----------------------------------------------------------------------
Asterisk Testing > Asterisk 1.8 Branch > #474 failed.
-----------------------------------------------------------------------
Code has been updated by Matthew Jordan.
1/191 tests failed, no failures were new.

http://bamboo.asterisk.org/browse/TESTING-ASTERISK18BRANCH-474/


--------------
Failing Jobs
--------------
  - Asterisk 1.8 CentOS 6 64-Bit (CentOS 6): 1 of 191 tests failed.



--------------
Code Changes
--------------
Matthew Jordan (376428):

>Reorder startup sequence to prevent lockups when process is sent to background
>
>Although it is very rare and timing dependent, the potential exists for the
>call to 'daemon' to cause what appears to be a deadlock in Asterisk during
>startup.  This can occur when a recursive mutex is obtained prior to the
>daemon call executing.  Since daemon uses fork to send the process into the
>background, any threading primitives are unsafe to re-use after the call.
>Implementations of pthread recursive mutexes are highly likely to store the
>thread identifier of the thread that previously obtained the mutex.  If
>the mutex was locked prior to the fork, a subsequent unlock operation will
>potentially fail as the thread identifier is no longer valid.  Since the
>mutex is still locked, all subsequent attempts to grab the mutex by other
>threads will block.
>
>This behavior exhibited itself most often when DEBUG_THREADS was enabled, as
>this compile time option surrounds the mutexes in Asterisk with another
>recursive mutex that protects the storage of thread related information.  This
>made it much more likely that a recursive mutex would be obtained prior to
>daemon and unlocked after the call.
>
>This patch does the following:
>a) It backports a patch from Asterisk 11 that prevents the spawning of the
>   localtime monitoring thread.  This thread is now spawned after Asterisk has
>   fully booted.
>b) It re-orders the startup sequence to call daemon earlier during Asterisk
>   startup.  This limits the potential of threading primitives being accessed
>   by initialization calls before daemon is called.
>c) It removes calls to ast_verbose/ast_log/etc. prior to daemon being called.
>   Developers should send error messages directly to stderr prior to daemon,
>   as calls to ast_log may access recursive mutexes that store thread related
>   information.
>d) It reorganizes when thread local storage is created for storing lock
>   information during the creation of threads.  Prior to this patch, the
>   read/write lock protecting the list of threads in ast_register_thread would
>   utilize the lock in the thread local storage prior to it being initialized;
>   this patch prevents that.
>
>On a very related note, this patch will *greatly* improve the stability of the
>Asterisk Test Suite.
>
>Review: https://reviewboard.asterisk.org/r/2197
>
>(closes issue ASTERISK-19463)
>Reported by: mjordan
>Tested by: mjordan
>
>



--------------
Tests
--------------
Existing Test Failures (1)
   - AsteriskTestSuite: S/cdr/batch cdrs

--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20121118/a0964032/attachment.htm>