[test-results] [Bamboo] Asterisk Testing > Asterisk Trunk > #1323 has FAILED (49 tests failed, 4 failures were new). Change made by dlee.

[Bamboo]

-----------------------------------------------------------------------
Asterisk Testing > Asterisk Trunk > #1323 failed.
-----------------------------------------------------------------------
Code has been updated by dlee.
1/2 jobs failed, with 49 failing tests, 4 failures were new.

http://bamboo.asterisk.org/browse/TESTING-ASTERISKTRUNK-1323/


--------------
Failing Jobs
--------------
  - Asterisk CentOS 6 32-Bit (CentOS 6): 49 of 546 tests failed.



--------------
Code Changes
--------------
dlee (390122):

>Avoid unnecessary cleanups during immediate shutdown
>
>This patch addresses issues during immediate shutdowns, where modules
>are not unloaded, but Asterisk atexit handlers are run.
>
>In the typical case, this usually isn't a big deal. But the
>introduction of the Stasis message bus makes it much more likely for
>asynchronous activity to be happening off in some thread during
>shutdown.
>
>During an immediate shutdown, Asterisk skips unloading modules. But
>while it is processing the atexit handlers, there is a window of time
>where some of the core message types have been cleaned up, but the
>message bus is still running. Specifically, it's still running
>module subscriptions that might be using the core message types. If a
>message is received by that subscription in that window, it will
>attempt to use a message type that has been cleaned up.
>
>To solve this problem, this patch introduces ast_register_cleanup().
>This function operates identically to ast_register_atexit(), except
>that cleanup calls are not invoked on an immediate shutdown. All of
>the core message type and topic cleanup was moved from atexit handlers
>to cleanup handlers.
>
>This ensures that core type and topic cleanup only happens if the
>modules that used them are first unloaded.
>
>This patch also changes the ast_assert() when accessing a cleaned up
>or uninitialized message type to an error log message. Message type
>functions are actually NULL safe across the board, so the assert was a
>bit heavy handed. Especially for anyone with DO_CRASH enabled.
>
>Review: https://reviewboard.asterisk.org/r/2562/
>



--------------
Tests
--------------
New Test Failures (4)
   - AsteriskTestSuite: S/bridge/atxfer nominal
   - AsteriskTestSuite: S/feature blonde transfer
   - AsteriskTestSuite: S/channels/ s i p/sip custom presence/multiple state change
   - AsteriskTestSuite: S/predial
Existing Test Failures (45)
   - AsteriskTestSuite: S/channels/ s i p/sip blind transfer/callee with reinvite
   - AsteriskTestSuite: S/channels/ s i p/sip hold
   - AsteriskTestSuite: S/bridge/blindxfer setup
   - AsteriskTestSuite: S/bridge/transfer failure
   - AsteriskTestSuite: S/apps/chanspy/chanspy w mixmonitor
   - AsteriskTestSuite: S/channels/ s i p/sip blind transfer/caller with reinvite
   - AsteriskTestSuite: S/bridge/blonde nominal
   - AsteriskTestSuite: S/channels/ s i p/acl call
   - AsteriskTestSuite: S/fax/local channel t38 queryoption
   - AsteriskTestSuite: S/masquerade
   - AsteriskTestSuite: S/feature attended transfer
   - AsteriskTestSuite: S/bridge/automon
   - AsteriskTestSuite: S/bridge/parkcall timeout/comebacktoorigin yes
   - AsteriskTestSuite: S/apps/directed pickup
   - AsteriskTestSuite: S/apps/mixmonitor audiohook inherit
   - AsteriskTestSuite: S/bridge/connected line update
   - AsteriskTestSuite: S/apps/confbridge/confbridge nominal
   - AsteriskTestSuite: S/hangup/handlers
   - AsteriskTestSuite: S/apps/queues/queue one paused no answer
   - AsteriskTestSuite: S/channels/ s i p/sip blind transfer/callee refer only
   - AsteriskTestSuite: S/bridge/parkcall blindxfer

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