Re: [asterisk-dev] [Code Review] 4460: res_pjsip_refer: Fix occasional unexpected BYE sent after receiving a REFER.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4460/ --- (Updated March 6, 2015, 5:27 p.m.) Review request for Asterisk Developers. Changes --- Addressed feedback and pulled out other fixes into other commits. Bugs: ASTERISK-24755 https://issues.asterisk.org/jira/browse/ASTERISK-24755 Repository: Asterisk Description (updated) --- A race condition happened between initiating a transfer and requesting that a dialog termination be delayed. Occasionally, the transferrer channels would exit the bridge and hangup before the dialog termination was requested. * Made request dialog termination delay before initiating the transfer action. If the transfer fails then cancel the delayed dialog termination request. Diffs (updated) - /branches/13/res/res_pjsip_session.exports.in 432595 /branches/13/res/res_pjsip_session.c 432595 /branches/13/res/res_pjsip_refer.c 432595 /branches/13/include/asterisk/res_pjsip_session.h 432595 Diff: https://reviewboard.asterisk.org/r/4460/diff/ Testing --- The testsuite tests/channels/pjsip/ tests still pass with the patch. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4463: core: Introduce chaos into memory allocations
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- Introduce chaotic (random) failures into certain critical operations to force improvements to error handling. This patch introduces the DEBUG_CHAOS random failure mechanism and adds it to memory allocation wrappers in utils.h. To be activated, DEBUG_CHAOS must be enabled in menuselect. The failure rate (1 in X) is controlled by changing the define DEBUG_CHAOS_CHANCES_1IN in utils.h. Diffs - /branches/13/main/utils.c 432572 /branches/13/include/asterisk/utils.h 432572 /branches/13/build_tools/cflags.xml 432572 Diff: https://reviewboard.asterisk.org/r/4463/diff/ Testing --- I'm unable to get Asterisk to actually start with 1 in 100,000 failure rate. Thanks, Scott Griepentrog -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4460: res_pjsip_refer: Fix occasional unexpected BYE sent after receiving a REFER.
On March 5, 2015, 2:24 p.m., Ashley Sanders wrote: /branches/13/res/res_pjsip_refer.c, line 477 https://reviewboard.asterisk.org/r/4460/diff/1/?file=71745#file71745line477 For clarity, I suggest using a default case in the switch statement rather than representing the default value by an assignment outside of the switch statement. Not using a default case here is intentional. When a switch statement is used on an enum type, the compiler is configured to complain if the switch does not cover all enum values. Adding a default case in the switch statement here causes all enum values to be handled including any future values that get added later. On March 5, 2015, 2:24 p.m., Ashley Sanders wrote: /branches/13/res/res_pjsip_refer.c, line 808 https://reviewboard.asterisk.org/r/4460/diff/1/?file=71745#file71745line808 Here, also, is the same pattern I reported for the switch-statement bodies from lines 748 and 478. This could benefit from a common function for assigning the response value. Much more refactoring is beyond the scope of the issue. - rmudgett --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4460/#review14601 --- On March 4, 2015, 11:31 a.m., rmudgett wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4460/ --- (Updated March 4, 2015, 11:31 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24755 https://issues.asterisk.org/jira/browse/ASTERISK-24755 Repository: Asterisk Description --- A race condition happened between initiating a transfer and requesting that a dialog termination be delayed. Occasionally, the transferrer channels would exit the bridge and hangup before the dialog termination was requested. * Made request dialog termination delay before initiating the transfer action. If the transfer fails then cancel the delayed dialog termination request. * Made safely get the TRANSFER_CONTEXT channel value while the channel is locked in refer_incoming_attended_request() and refer_incoming_blind_request(). The pointer returned by pbx_builtin_getvar_helper() is only valid while the channel is locked. * Made refer_attended_alloc() not create the ao2 object with an unneeded lock. Diffs - /branches/13/res/res_pjsip_session.exports.in 432446 /branches/13/res/res_pjsip_session.c 432446 /branches/13/res/res_pjsip_refer.c 432446 /branches/13/include/asterisk/res_pjsip_session.h 432446 Diff: https://reviewboard.asterisk.org/r/4460/diff/ Testing --- The testsuite tests/channels/pjsip/ tests still pass with the patch. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4450: locatime.c file descriptor leak on kqueue(2) systems
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4450/ --- (Updated March 6, 2015, 10:59 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24739 https://issues.asterisk.org/jira/browse/ASTERISK-24739 Repository: Asterisk Description --- File descriptor leak on kqueue(2) systems (found on OpenBSD 5.5) on main/stdtime/localtime.c -- TZ data files change watch code within the time functions. (Issue at https://issues.asterisk.org/jira/browse/ASTERISK-24739.) Diffs - tags/11.7.0/main/stdtime/localtime.c 432443 Diff: https://reviewboard.asterisk.org/r/4450/diff/ Testing --- Patch initially developed against OpenBSD 5.5 ports package sources, and Asterisk in use. Subsequently developed test program that can run original or patched 11.7.0 code. File Attachments (updated) Test r3 https://reviewboard.asterisk.org/media/uploaded/files/2015/03/06/a29ea5c5-3253-429b-aa0f-873bbd652a6f__patchtest.tgz Thanks, Ed Hynan -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4460: res_pjsip_refer: Fix occasional unexpected BYE sent after receiving a REFER.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4460/#review14605 --- Logically, this looks sound. Structurally, I agree with Ashley's comments. However, I subscribe to the school of fixing bugs in one commit and making structural improvements in a separate commit if they're not directly related to the bug being fixed (in fact, I would eschew some of the formatting changes you've introduced in this review already). So I'd be okay if this got committed as-is and a separate commit were made after to address Ashley's findings. Or if you'd rather knock it all out in one go, do it that way. - Mark Michelson On March 4, 2015, 5:31 p.m., rmudgett wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4460/ --- (Updated March 4, 2015, 5:31 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24755 https://issues.asterisk.org/jira/browse/ASTERISK-24755 Repository: Asterisk Description --- A race condition happened between initiating a transfer and requesting that a dialog termination be delayed. Occasionally, the transferrer channels would exit the bridge and hangup before the dialog termination was requested. * Made request dialog termination delay before initiating the transfer action. If the transfer fails then cancel the delayed dialog termination request. * Made safely get the TRANSFER_CONTEXT channel value while the channel is locked in refer_incoming_attended_request() and refer_incoming_blind_request(). The pointer returned by pbx_builtin_getvar_helper() is only valid while the channel is locked. * Made refer_attended_alloc() not create the ao2 object with an unneeded lock. Diffs - /branches/13/res/res_pjsip_session.exports.in 432446 /branches/13/res/res_pjsip_session.c 432446 /branches/13/res/res_pjsip_refer.c 432446 /branches/13/include/asterisk/res_pjsip_session.h 432446 Diff: https://reviewboard.asterisk.org/r/4460/diff/ Testing --- The testsuite tests/channels/pjsip/ tests still pass with the patch. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4455: res_pjsip: conflicting endpoint identifiers
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4455/#review14606 --- Ship it! Ship It! - Mark Michelson On March 5, 2015, 11:40 p.m., Kevin Harwell wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4455/ --- (Updated March 5, 2015, 11:40 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24840 https://issues.asterisk.org/jira/browse/ASTERISK-24840 Repository: Asterisk Description --- It's possible to have a scenario that will create a conflict between endpoint identifiers. For instance an incoming call could be identified by two different endpoint identifiers and the one chosen depended upon which identifier module loaded first. This of course causes problems when, for example, the incoming call is expected to be identified by username, but instead is identified by ip. This patch adds a new 'global' option to res_pjsip called 'endpoint_identifier_order'. It is a comma separated list of endpoint identifier names that specifies the order by which identifiers are processed and checked. Diffs - branches/13/res/res_pjsip_endpoint_identifier_user.c 432482 branches/13/res/res_pjsip_endpoint_identifier_ip.c 432482 branches/13/res/res_pjsip_endpoint_identifier_anonymous.c 432482 branches/13/res/res_pjsip/config_global.c 432482 branches/13/res/res_pjsip.c 432482 branches/13/include/asterisk/res_pjsip.h 432482 branches/13/contrib/ast-db-manage/config/versions/45e3f47c6c44_add_pjsip_endpoint_identifier_order.py PRE-CREATION branches/13/configs/samples/pjsip.conf.sample 432482 branches/13/CHANGES 432482 Diff: https://reviewboard.asterisk.org/r/4455/diff/ Testing --- Added a testsuite test: https://reviewboard.asterisk.org/r/4456/ Thanks, Kevin Harwell -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4437: dns: Define a core DNS API with examples.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4437/ --- (Updated March 6, 2015, 6:45 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Repository: Asterisk Description --- A wiki page is present at: https://wiki.asterisk.org/wiki/display/~jcolp/Asterisk+DNS+API Which details a new DNS API for Asterisk. This exists as a thin wrapper over other resolver libraries. The core part provides a common interface and some additional features, such as NAPTR/SRV parsing and recurring lookups. Examples are provided which cover the common use cases for the API. Some stuff to think about: 1. Does this encompass everything we think a low level API should? 2. Are there any higher level APIs that would be useful to have? 3. Is the usage intuitive and easy? 4. Are there other examples which would help? 5. Do we want resolvers to be actual modules or keep them in-core? 6. Anything else you think of Have at it! Diffs - Diff: https://reviewboard.asterisk.org/r/4437/diff/ Testing --- I've logically run through the API and examples to ensure they provide what is needed for the future, to make them as easy as possible to use, and to ensure higher level APIs can be created. Thanks, Joshua Colp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4454: chan_sip: Fix realtime locking inversion when poking a just built peer.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4454/ --- (Updated March 6, 2015, 1:18 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 432526 Bugs: ASTERISK-24838 https://issues.asterisk.org/jira/browse/ASTERISK-24838 Repository: Asterisk Description --- When a realtime peer is built it can cause a locking inversion when the just built peer is poked. If the CLI command sip show channels is periodically executed a deadlock can happen because of the locking inversion. * Push the peer poke off onto the scheduler thread to avoid the locking inversion of the just built realtime peer. Diffs - /branches/11/channels/chan_sip.c 432422 Diff: https://reviewboard.asterisk.org/r/4454/diff/ Testing --- Compiling and code inspection. I don't have a realtime setup to test with. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4452: Testsuite: ARI channel subscription tests
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4452/ --- (Updated March 6, 2015, 1:45 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 6491 Bugs: ASTERISK-24586 https://issues.asterisk.org/jira/browse/ASTERISK-24586 Repository: testsuite Description --- This adds some local and non-local channel subscription tests for ARI. These tests ensure ARI events occur and/or don't occur for the appropriate stasis app(s). Due to the variations and small differences of these, the test-config.yaml descriptions of each is the best way to describe what they do. Four tests have been added under 'tests/rest_api/applications/channel-subscriptions/'. : * originate_to_dialplan/non_local_channels - Similiar to the existing test that this patch modifies as mentioned below. This required modifying pjsua_mod.py to allow more calls. * originate_to_other_stasis_app/local_channels - Creates two websockets, one for for each stasis app. Originates a local channel from AppA where half is sent into AppB and the other half send into the dialplan. * originate_to_other_stasis_app/non_local_channels - Creates two websockets, one for for each stasis app. Originates a PJSIP channel from AppA to a pjsua phone where is is placed into AppB. * originate_to_stasis_app/local_channels Note: The test 'tests/rest_api/applications/subscribe-channel' test has been renamed to 'basic-subscribe' under the same location as the new tests. The following test has been modified to ensure no ARI events are received: * tests/rest_api/channels/originate_to_dialplan Diffs - /asterisk/trunk/tests/rest_api/channels/originate_to_dialplan/test-config.yaml 6475 /asterisk/trunk/tests/rest_api/applications/tests.yaml 6475 /asterisk/trunk/tests/rest_api/applications/subscribe-channel/test-config.yaml 6475 /asterisk/trunk/tests/rest_api/applications/subscribe-channel/subscribe_channel.py 6475 /asterisk/trunk/tests/rest_api/applications/subscribe-channel/configs/ast1/extensions.conf 6475 /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_stasis_app/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_stasis_app/local_channels/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_stasis_app/local_channels/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/non_local_channels/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/non_local_channels/run-test PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/non_local_channels/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/non_local_channels/configs/ast1/http.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/local_channels/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/local_channels/run-test PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/local_channels/configs/ast1/http.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/local_channels/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_dialplan/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_dialplan/non_local_channels/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_dialplan/non_local_channels/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_dialplan/non_local_channels/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/lib/python/asterisk/pjsua_mod.py 6475 Diff: https://reviewboard.asterisk.org/r/4452/diff/ Testing --- * Executed each test successfully 30+ times. * Changed the code to force a failure to ensure tests properly failed. * Review logs to ensure operation is as expected. Thanks, jbigelow --
Re: [asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r// --- (Updated March 6, 2015, 1:52 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 432530 Bugs: ASTERISK-24825 https://issues.asterisk.org/jira/browse/ASTERISK-24825 Repository: Asterisk Description --- The distinctive ring feature interferes with detecting Caller ID and appears to have been broken for years. What happens is if you have a ring-ring cadence as used in the UK you get too many DAHDI events for the distinctive ring pattern array and Caller ID detection is aborted. I think when Zapata/DAHDI added the ring begin event it broke distinctive ring. More events happen than before and the code does no filtering of which event times are recorded in the pattern array. * Made distinctive ring only record the ringt count when the ring ends instead of on just any DAHDI event. Distinctive ring can be ring, ring-ring, ring-ring-ring, or different ring durations for the up to three rings. * Fixed the distinctive ring detection enable (chan_dahdi.conf option usedistinctiveringdetection) to be per port instead of somewhat per port and somewhat global. This has been broken since v1.8. * Fixed using the default distinctive ring context when the detected pattern does not match any configured dringX patterns. The default context did not get set when the previous call was a matched distinctive ring pattern and the current call is not matched. This has been broken since v1.8. * Made distinctive ring have no effect on Caller ID detection when it is disabled. Caller ID detection just monitors for 10 seconds before giving up. * Fixed leak of struct callerid_state memory when a polarity reversal during Caller ID detection causes the incoming call to be aborted. Diffs - /branches/11/channels/sig_analog.c 432422 /branches/11/channels/sig_analog.h 432422 /branches/11/channels/chan_dahdi.c 432422 /branches/11/UPGRADE.txt 432422 Diff: https://reviewboard.asterisk.org/r//diff/ Testing --- Tested the following scenarios for US (ring) and UK (ring-ring) ring cadences: 1) usedistinctiveringdetection=no 2) usedistinctiveringdetection=yes with distinctiveringaftercid=no 3) usedistinctiveringdetection=yes with distinctiveringaftercid=yes * Caller-ID was detected for each call * The configured distinctive ring dringX pattern was detected and the specified context set. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4462: DNS core unit tests
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4462/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- This provides unit tests for the DNS core as described here: https://wiki.asterisk.org/wiki/display/~jcolp/Asterisk+DNS+API By core this means the bare-bones functionality, such as being able to set and retrieve data on DNS queries. This also includes a mock resolver, whose intention is to ensure that resolver methods are called into when expected. If you have ideas for tests that have not been included here, please mention them in your reviews. Some things that are not covered here: * Recurring asynchronous queries, query sets, NAPTR, SRV, and TLSA are not covered by these tests. These are higher-level APIs on top of the DNS core and will be covered in separate test files. * Nominal asynchronous DNS cancellation is tested here, but off-nominal is not. Off-nominal asynchronous cancellation falls into two basic categories: canceling when there is no query in flight and canceling after a query has completed. You can't test canceling when there is no query in flight because putting the query in flight is what gives you the query object that you would attempt to cancel in the first place. Testing canceling after the query has completed does not test the DNS core as much as it does a specific resolver implementation. Since the resolver implementation is in charge of threading, the core does not try to make any determination of whether it makes sense to be canceling a query or not. Diffs - /trunk/tests/test_dns.c PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4462/diff/ Testing --- All tests pass consistently, and they do not leak memory (as evidenced by MALLOC_DEBUG) Thanks, Mark Michelson -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4450: locatime.c file descriptor leak on kqueue(2) systems
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4450/#review14608 --- Ship it! I've given this several looks, and I think it's good to be shipped. Thanks! - Mark Michelson On March 3, 2015, 3:25 p.m., Ed Hynan wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4450/ --- (Updated March 3, 2015, 3:25 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24739 https://issues.asterisk.org/jira/browse/ASTERISK-24739 Repository: Asterisk Description --- File descriptor leak on kqueue(2) systems (found on OpenBSD 5.5) on main/stdtime/localtime.c -- TZ data files change watch code within the time functions. (Issue at https://issues.asterisk.org/jira/browse/ASTERISK-24739.) Diffs - tags/11.7.0/main/stdtime/localtime.c 432443 Diff: https://reviewboard.asterisk.org/r/4450/diff/ Testing --- Patch initially developed against OpenBSD 5.5 ports package sources, and Asterisk in use. Subsequently developed test program that can run original or patched 11.7.0 code. File Attachments localtime.c (11.7.0) test program https://reviewboard.asterisk.org/media/uploaded/files/2015/02/25/f7a19f2a-4a8a-4aff-b7d6-44a4146c358c__patchtest.tgz Test r2: patchtest.tgz https://reviewboard.asterisk.org/media/uploaded/files/2015/03/03/e0cb7fb2-68b0-425a-b131-68406094e66e__patchtest.tgz Thanks, Ed Hynan -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4459: Asterisk terminates when playing a voicemail stored in LDAP
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4459/#review14609 --- Ship it! Ship It! - Mark Michelson On March 4, 2015, 9:07 p.m., Graham Barnett wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4459/ --- (Updated March 4, 2015, 9:07 p.m.) Review request for Asterisk Developers and mattjordan. Bugs: ASTERISK-24786 https://issues.asterisk.org/jira/browse/ASTERISK-24786 Repository: Asterisk Description --- Asterisk terminates when playing a voicemail stored in LDAP Diffs - http://svn.asterisk.org/svn/asterisk/trunk/apps/app_voicemail.c 432422 Diff: https://reviewboard.asterisk.org/r/4459/diff/ Testing --- Tested against Microsoft Exchange 2007 Thanks, Graham Barnett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4463: core: Introduce chaos into memory allocations
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/ --- (Updated March 7, 2015, 12:01 a.m.) Review request for Asterisk Developers. Changes --- Fixed several crashes on Asterisk startup. Added diagnostic output on initialization failures. Reworked CHAOS slightly to allow for use in other locations with different chance values. Repository: Asterisk Description --- Introduce chaotic (random) failures into certain critical operations to force improvements to error handling. This patch introduces the DEBUG_CHAOS random failure mechanism and adds it to memory allocation wrappers in utils.h. To be activated, DEBUG_CHAOS must be enabled in menuselect. The failure rate (1 in X) is controlled by changing the define DEBUG_CHAOS_CHANCES_1IN in utils.h. Diffs (updated) - /branches/13/main/xmldoc.c 432613 /branches/13/main/utils.c 432613 /branches/13/main/endpoints.c 432613 /branches/13/main/config.c 432613 /branches/13/main/codec_builtin.c 432613 /branches/13/main/asterisk.c 432613 /branches/13/include/asterisk/utils.h 432613 /branches/13/build_tools/cflags.xml 432613 Diff: https://reviewboard.asterisk.org/r/4463/diff/ Testing --- I'm unable to get Asterisk to actually start with 1 in 100,000 failure rate. Thanks, Scott Griepentrog -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
