[asterisk-dev] [Code Review] Crash in audiohook_write_list
Kaloyan Kovachev
kkovachev at varna.net
Fri Apr 23 05:18:14 CDT 2010
On Thu, 22 Apr 2010 20:56:41 -0000, "David Vossel" <dvossel at digium.com>
wrote:
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/623/
> -----------------------------------------------------------
>
> Review request for Asterisk Developers and Tilghman Lesher.
>
>
> Summary
> -------
>
> In audio_audiohook_write_list(), middle_frame represents the translated
> SLINEAR version of the input frame (that is if the input frame was not
> already SLINEAR to begin with, If that is the case, middle_frame is the
> input frame)
>
> The crash that is occurring is caused by r224856 in trunk which frees
the
> middle_frame if an audiohook manipulation callback fails. This is not
good
> for several reasons.
This it the crash mentioned in note 113581 for issue 14621
https://issues.asterisk.org/view.php?id=14621
Why not just check that there is a frame before proceeding with the
callback? This way in case of failure no manipulations will be made after
an error and the original frame will be passed unmodified.
>
> 1. middle_frame could be equal to the input frame, in that case whatever
> we are returning in this function is a pointer to freed memory
> 2. there may be additional audiohook manipulators in the list that could
> process the data, an audiohook manipulation callback failure can be as
> simple as the manipulator not caring about altering the data for that
> direction (example func_speex which was was altered to do that very
thing
> in the same revision), that shouldn't prevent other manipulators in the
> list from doing their thing.
> 3. middle_frame is set to end_frame before manipulation if chan_spy is
> used. This means it is possible for middle_frame to be freed while
> end_frame still points to the freed data which is later returned at the
end
> of the function. This could be avoided, but would add even additional
> complication to an already exceedingly complex function for no apparent
> benefit.
>
>
> This revision was added to fix something, but I can't figure out what it
> is. I'm suggesting we revert the audiohook.c part of it.
>
>
> This addresses bug 17052.
> https://issues.asterisk.org/view.php?id=17052
>
>
> Diffs
> -----
>
> /trunk/main/audiohook.c 258605
>
> Diff: https://reviewboard.asterisk.org/r/623/diff
>
>
> Testing
> -------
>
> chanspy can now work with other audiohook manipulators.
>
>
> Thanks,
>
> David
>
>
> --
> _____________________________________________________________________
> -- 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
More information about the asterisk-dev
mailing list