[asterisk-dev] Astobj2 debugging change proposal

[George Joseph]

On Mon, Jun 9, 2014 at 11:22 AM, Corey Farrell <git at cfware.com> wrote:

> One thing I dislike about AST_DEVMODE is that changing it requires
> rerunning ./configure.  I feel ./configure should be restricted as much as
> possible to checking dependencies.  Any build configuration that is not
> directly enabled/disabled by an external dependency should be in menuselect.
>
> If we are going to make it so TEST_FRAMEWORK doesn't enable AO2_DEBUG, I
> think we should allow Bamboo to run without AO2_DEBUG once.  This way if
> any tests actually require it we can update dependencies.
>

I ran the testsuite last night without AO2_DEBUG and didn't notice anything
different but I'm going to run it again now.


> I'm not sure how I feel about AO2_DEBUG being combined with REF_DEBUG.
> AO2_DEBUG doesn't appear to add much overhead, but REF_DEBUG adds
> significant overhead through output to the refs log.  I'm not sure someone
> who specifically wants AO2_DEBUG would want REF_DEBUG.  Especially since
> REF_DEBUG can change timing and that could change results.
>
> Agreed.  REF_DEBUG seems more aimed at debugging the use of astobj2
whereas AO2_DEBUG is more aimed at debugging astobj2 itself.  2 different
purposes.

>
> On Mon, Jun 9, 2014 at 12:46 PM, Matthew Jordan <mjordan at digium.com>
> wrote:
>
>> On Sun, Jun 8, 2014 at 10:03 AM, George Joseph
>> <george.joseph at fairview5.com> wrote:
>> > Right now, the non-ref debugging code in astobj2 is triggered by a mix
>> of
>> > AST_DEVMODE and AO2_DEBUG and both get set if you want to run the test
>> > framework.  I've noticed though that the inclusion of the debugging
>> code can
>> > actually hide problems as well as highlight them, especially related to
>> > performance and locking.   Case in point:  Try running 'test execute
>> > category /main/astobj2 name thrash' with REF_DEBUG turned on and off.
>>  While
>> > the test passes both ways, the timing is significantly different (and
>> not
>> > what you'd expect).  Luckily, you can turn REF_DEBUG on and off from
>> > menuselect.
>> >
>> > To provide a little more flexibility and visibility, I'd like to
>> propose the
>> > following...
>> >
>> > 1.  Change astobj2 so the non-ref debugging code is dependent on
>> AO2_DEBUG
>> > solely instead of the mix of AST_DEVMODE and AO2_DEBUG.  (REF_DEBUG
>> would
>> > remain as is)
>>
>> Having two different 'dev' or 'debug' compilation flags is confusing.
>> I'd be happy with having them collapsed down to one.
>>
>> > 2.  Remove the code that automatically sets AO2_DEBUG if TEST_FRAMEWORK
>> is
>> > defined.
>>
>> Richard may want to chime in on this, since I'm pretty sure that was a
>> change he initiated.
>>
>> Personally, I think it is okay if they are decoupled. We can always
>> enable AO2_DEBUG from menuselect in Bamboo build plans, and I'm not
>> aware of any Asterisk Test Suite functionality that explicitly relies
>> on AO2_DEBUG being defined.
>>
>> > 3.  Add AO2_DEBUG to the menuselect extended compiler flags right next
>> to
>> > REF_DEBUG.
>>
>> I'm okay with this too... although is there a reason why REF_DEBUG and
>> AO2_DEBUG shouldn't be combined? Do they absolutely have to be
>> separate compilation flags?
>>
>> > This way you can run the test framework in either production or
>> debugging
>> > mode.  The code change to do this is trivial but I thought I'd run it
>> by you
>> > guys first.
>> >
>> > Thoughts?
>>
>>
>> --
>> Matthew Jordan
>> Digium, Inc. | Engineering Manager
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> Check us out at: http://digium.com & http://asterisk.org
>>
>> --
>> _____________________________________________________________________
>> -- 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
>>
>
>
> --
> _____________________________________________________________________
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140609/77171d8a/attachment.html>