[asterisk-dev] [Code Review] Fix for parking lot settings not being respected with unit test
Mark Michelson
mmichelson at digium.com
Wed Mar 3 11:17:49 CST 2010
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/539/#review1625
-----------------------------------------------------------
Let me add a disclaimer to the top of this review that I am not intimately familiar with the goings-on in the call parking code, so if I say something that is not true down below, please feel free to put me in my place and tell me how wrong I am.
/trunk/main/features.c
<https://reviewboard.asterisk.org/r/539/#comment3637>
Is this safe? I ask because you will have args pointing to the pu that is created in park_space_reserve. I'm wondering if it is possible for manage_parkinglot to free this pointer out from under you.
Or is such a problem protected by the (terribly-named) notquiteyet field of the pu struct?
/trunk/main/features.c
<https://reviewboard.asterisk.org/r/539/#comment3638>
Is there a potential for multiple copies of args->pu to be in the list? If not, then you can break at this point instead of continuing.
/trunk/main/features.c
<https://reviewboard.asterisk.org/r/539/#comment3639>
I'm a bit curious why you only unref the parkinglot and free args->pu if you find the pu in the parkinglot.
Shouldn't you unref the parkinglot and free memory unconditionally?
- Mark
On 2010-03-02 20:47:45, Jeff Peeler wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/539/
> -----------------------------------------------------------
>
> (Updated 2010-03-02 20:47:45)
>
>
> Review request for Asterisk Developers.
>
>
> Summary
> -------
>
> This verifies a change in parking to ensure the channel variable PARKINGLOT is respected. Kind of overkill for an obvious change, but many more parking scenarios can be added later.
>
>
> This addresses bug 16592.
> https://issues.asterisk.org/view.php?id=16592
>
>
> Diffs
> -----
>
> /trunk/main/features.c 250288
>
> Diff: https://reviewboard.asterisk.org/r/539/diff
>
>
> Testing
> -------
>
> Verified proposed fix works and that all created channels are properly destroyed. It seems though that I do actually have a ref count problem with the dynamic lot used for testing, which I haven't been able to track down yet. I went ahead and posted the review so the rest of the test can be examined.
>
>
> Thanks,
>
> Jeff
>
>
More information about the asterisk-dev
mailing list