Hi Mikel, On Tue, Feb 21, 2012 at 1:02 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Mikel, > > On Tue, Feb 21, 2012 at 10:46 AM, Mikel Astiz <mikel.astiz.oss@xxxxxxxxx> wrote: >> From: Mikel Astiz <mikel.astiz@xxxxxxxxxxxx> >> >> This code path could lead to situations where the callback is later >> used, making the daemon crash. >> --- >> gobex/gobex.c | 3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/gobex/gobex.c b/gobex/gobex.c >> index 0665749..bc76e57 100644 >> --- a/gobex/gobex.c >> +++ b/gobex/gobex.c >> @@ -735,6 +735,9 @@ gboolean g_obex_cancel_req(GObex *obex, guint req_id, gboolean remove_callback) >> goto immediate_completion; >> } >> >> + if (remove_callback) >> + obex->pending_req->rsp_func = NULL; >> + > > I see the problem, so we are keeping the pending request because of > the abort response, Im just not sure why we need to report an error if > cancelled is set on handle_response. So perhaps the right place to fix > this is in handle_response as soon as it checks for cancelled it > should skip to the point it frees the pending call, in other words we > should never need to report G_OBEX_ERROR_CANCELLED for requests since > we are the ones cancelling them. Actually this is correct, since when remove_callback is FALSE we still call the callback so G_OBEX_ERROR_CANCELLED makes sense. Ack. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
