[asterisk-dev] [Code Review] [patch] Improve debug of ast_hangup

[Tilghman Lesher]

> On 2011-04-15 05:17:36, Russell Bryant wrote:
> > The code is mostly fine here ... but I'm not entirely sure it's something that makes sense to go into Asterisk.  This is the kind of change that I would make (and have made many times) while debugging an issue, but just throw away when I'm done.  If we did it for this function, why not every API call in Asterisk?  Why not _every_ function?
> > 
> > Most cases where we have it today in the upstream code are for the purposes of resource tracking.  For example, track the real file/func/line that allocated memory.
> 
> Olle E Johansson wrote:
>     Because in so many cases, the hangup is a critical issue and we need to know why this happened and who issued it. I think it's important. Otherwise I would have thrown this away too, like many other debugging patches...
> 
> jrose wrote:
>     I really don't like the idea of adding many arguments to a function that takes one argument strictly for the sake of debugging.  Maybe you could add a debug-specific function that invokes this one as a helper method or something along those lines.  I guess it wouldn't be as convenient if you couldn't immediately see what the invoking function/channel were, but you might be able to get around that by using some fancy preprocessor definitions to automatically add some of that data to that data to the function and function call if some in specific debugging compilation flag is enabled.

jrose: you need to consider ast_mutex_init() in the context of that argument, which ostensibly takes a single argument, but actually takes 6.

Olle:  given that this is such a common utility function, I think it would be better served with a parallel call to ast_log describing the reason for the hangup.  Debug only gets us so far, but the reason would be better specified in the code.  At the time that ast_hangup is called, we're usually well beyond the point at which a reason can be discerned; it's just cleaning up at that point.


> On 2011-04-15 05:17:36, Russell Bryant wrote:
> > /trunk/include/asterisk/channel.h, lines 1381-1382
> > <https://reviewboard.asterisk.org/r/1164/diff/1/?file=16064#file16064line1381>
> >
> >     For consistency, I think most other instances of this do it in the order of file, func, line.
> >     
> >     Also, most code uses __PRETTY_FUNCTION__ instead of __func__.  I don't know what the difference is off of the top of my head though.
> 
> Olle E Johansson wrote:
>     Ok.

The difference in pure C code is minor, but if you use hybrid C++ modules, the __PRETTY_FUNCTION__ macro removes the extra cruft added to the function name by the compiler.


- Tilghman


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


On 2011-04-07 06:21:53, Olle E Johansson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1164/
> -----------------------------------------------------------
> 
> (Updated 2011-04-07 06:21:53)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> In many cases when I develop crazy code, I get weird hangups. It may only happen to me, but it does happen. I need to know when a hangup process is initiated and by whom. This small patch is a first step towards that goal.
> 
> 
> This addresses bug 19080.
>     https://issues.asterisk.org/view.php?id=19080
> 
> 
> Diffs
> -----
> 
>   /trunk/include/asterisk/channel.h 313005 
>   /trunk/main/channel.c 313005 
> 
> Diff: https://reviewboard.asterisk.org/r/1164/diff
> 
> 
> Testing
> -------
> 
> Tested in various versions of Asterisk. Seems to give me the output I need.
> 
> 
> Thanks,
> 
> Olle E
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110510/874b4349/attachment.htm>