[asterisk-dev] [Code Review] 3765: astobj2: debug backtrace and assert on invalid refcount

[rmudgett]

> On July 13, 2014, 4:22 p.m., rmudgett wrote:
> > ast_assert() already outputs a backtrace using ao2_bt() even if DO_CRACH is not enabled.
> > 
> > We also seem to have two backtrace generation functions:
> > ao2_bt()
> > ast_log_bactrace()
> 
> Matt Jordan wrote:
>     We could consolidate these two functions easily; ast_log_backtrace should just use ast_verbose instead of ast_debug.
>     
>     ast_verbose has a bit more functionality in the logger that works hard to get its output seen - if there are no verbosers registered, it will output to stdout.
>     
>     I don't think printing out a backtrace should live in ao2.

* ao2_bt() exists in v1.8+.
* ast_log_backtrace() exists in v1.8 & v11 as ast_backtrace().
* Neither are referenced in v1.8 and v11 for anything.
* v12+ only uses ao2_bt() for ast_assert()
* Ironically v12+ only uses ast_log_backtrace() in __ao2_ref_debug() before ast_assert(0).

Of course merging them should be done in trunk and maybe v12 with the winner being ast_log_backtrace() using ast_verbose() to log the backtrace.


- rmudgett


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3765/#review12609
-----------------------------------------------------------


On July 13, 2014, 3:05 p.m., Scott Griepentrog wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3765/
> -----------------------------------------------------------
> 
> (Updated July 13, 2014, 3:05 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> On an invalid refcount, rather than just log the message and continue executing normally, provide a backtrace and an assert to stop on DO_CRASH.  This can help to catch the first case of an invalid refcount rather than being distracted from the problem with a flurry additional logs from other threads encountering already mangled data.
> 
> 
> Diffs
> -----
> 
>   /trunk/main/astobj2.c 418447 
> 
> Diff: https://reviewboard.asterisk.org/r/3765/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140713/a06c4b3c/attachment.html>