[asterisk-dev] Astobj2 debugging change proposal

[Corey Farrell]

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'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.


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140609/fde8f49f/attachment.html>