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

[wdoekes]

> On April 15, 2011, 5:17 a.m., 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.
> 
> Tilghman Lesher wrote:
>     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.
> 
> Olle E Johansson wrote:
>     I still think this is good when debugging, it has helped me a lot. Remember, it's logged to the debug channel for developers, not for users. And it's a good start. I don't disagree that we should add a reason to the calls to the ast_hangup function, much like we have when unref'ing stuff. But that's another patch.
>     
>     I stubbornly propose that this small change should get committed. It's a good start.

I haven't had the need for this, but it sounds like something useful.

But, because I don't like extra code that few people use, I would indeed prefer a conditional compilation flag. Either under DONT_OPTIMIZE or a new generic one EXTRA_DEBUG.


- wdoekes


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


On April 7, 2011, 6:21 a.m., Olle E Johansson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1164/
> -----------------------------------------------------------
> 
> (Updated April 7, 2011, 6:21 a.m.)
> 
> 
> 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/jira/browse/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/20111104/7d8e8605/attachment.htm>