Blame SOURCES/0002-Remove-all-queues-before-dleyna_task_processor_t-on_.patch

653a74
From 1de3325c201dc0e1132bd34ea6f952ff8acbcf80 Mon Sep 17 00:00:00 2001
653a74
From: Debarshi Ray <debarshir@freedesktop.org>
653a74
Date: Fri, 16 Sep 2016 08:41:48 +0200
653a74
Subject: [PATCH 2/2] Remove all queues before
653a74
 dleyna_task_processor_t->on_quit_cb is run
653a74
653a74
If dleyna_task_processor_t->on_quit_cb is run while there are still
653a74
queues present in the processor, it can lead to a crash if one of the
653a74
queue's task_queue_finally_cb handler didn't expect to be run after
653a74
the control point has been stopped. For example,
653a74
dleyna-renderer-service crashes with this backtrace:
653a74
653a74
%0  __GI_raise (sig=sig@entry=6)
653a74
    at ../sysdeps/unix/sysv/linux/raise.c:54
653a74
%1  __GI_abort () at abort.c:89
653a74
%2  g_assertion_message (domain="GLib",
653a74
                         file="ghash.c",
653a74
                         line=373,
653a74
                         func="g_hash_table_lookup_node",
653a74
                         message="assertion failed:
653a74
                                  (hash_table->ref_count > 0)")
653a74
    at gtestutils.c:2429
653a74
%3  g_assertion_message_expr (domain="GLib",
653a74
                              file="ghash.c",
653a74
                              line=373,
653a74
                              func="g_hash_table_lookup_node",
653a74
                              expr="hash_table->ref_count > 0")
653a74
    at gtestutils.c:2452
653a74
%4  g_hash_table_lookup_node (hash_return=<synthetic pointer>,
653a74
                              key=0x561e98ca21c0,
653a74
                              hash_table=0x561e985899e0)
653a74
    at ghash.c:373
653a74
%5  g_hash_table_insert_internal (hash_table=0x561e985899e0,
653a74
                                  key=0x561e98ca21c0,
653a74
                                  value=0x561e98a581f0,
653a74
                                  keep_new_key=0)
653a74
    at ghash.c:1227
653a74
%6  prv_device_chain_end (cancelled=<optimized out>,
653a74
                          data=0x561e98e3acb0)
653a74
    at upnp.c:85
653a74
%7  prv_free_cb (data=0x561e98b97280)
653a74
    at libdleyna/core/task-processor.c:103
653a74
%8  g_hash_table_remove_all_nodes (hash_table=0x561e98549240,
653a74
                                   notify=<optimized out>,
653a74
                                   destruction=<optimized out>)
653a74
    at ghash.c:548
653a74
%9  g_hash_table_remove_all_nodes (destruction=1,
653a74
                                   notify=1,
653a74
                                   hash_table=0x561e98549240)
653a74
    at ghash.c:1093
653a74
%10 g_hash_table_unref (hash_table=0x561e98549240) at ghash.c:1097
653a74
%11 dleyna_task_processor_free (processor=0x561e985543a0)
653a74
    at libdleyna/core/task-processor.c:136
653a74
%12 prv_context_free () at libdleyna/core/main-loop.c:108
653a74
%13 dleyna_main_loop_start (server=<optimized out>,
653a74
                            control_point=<optimized out>,
653a74
                            user_data=0x0)
653a74
    at libdleyna/core/main-loop.c:167
653a74
%14 __libc_start_main (main=0x561e97db5990 <main>,
653a74
                       argc=1,
653a74
                       argv=0x7fff905cb0a8,
653a74
                       init=<optimized out>,
653a74
                       fini=<optimized out>,
653a74
                       rtld_fini=<optimized out>,
653a74
                       stack_end=0x7fff905cb098)
653a74
    at ../csu/libc-start.c:289
653a74
%15 _start ()
653a74
653a74
The processor's on_quit_cb handler is set to prv_context_quit_cb,
653a74
which calls control_point->stop_service and quits the GMainLoop. Then
653a74
the processor is destroyed, which in turn destroys any queues that
653a74
might have been left inside it. Unfortunately, a queue's
653a74
task_queue_finally_cb handler might be set to something that assumes
653a74
that the control_point has not been stopped. For example,
653a74
dleyna-renderer-service sets task_queue_finally_cb to
653a74
prv_device_chain_end, which will crash due to accessing invalid memory
653a74
(specifically the dlr_upnp_t) if prv_control_point_stop_service has
653a74
already been invoked. We see the same problem in dleyna-server-service
653a74
too.
653a74
653a74
Therefore, let's remove any leftover queues from the processor just
653a74
before dleyna_task_processor_t->on_quit_cb is scheduled to run. We are
653a74
about to terminate the process anyway, so it shouldn't hurt to do it
653a74
slightly earlier in the sequence.
653a74
653a74
https://bugzilla.redhat.com/show_bug.cgi?id=1360209
653a74
---
653a74
 libdleyna/core/task-processor.c | 2 ++
653a74
 1 file changed, 2 insertions(+)
653a74
653a74
diff --git a/libdleyna/core/task-processor.c b/libdleyna/core/task-processor.c
653a74
index 6d7f5b87de3d..89f0386c3f98 100644
653a74
--- a/libdleyna/core/task-processor.c
653a74
+++ b/libdleyna/core/task-processor.c
653a74
@@ -257,6 +257,7 @@ void dleyna_task_processor_set_quitting(dleyna_task_processor_t *processor)
653a74
 		g_idle_add(processor->on_quit_cb, NULL);
653a74
 
653a74
 	prv_cancel_all_queues(processor);
653a74
+	g_hash_table_remove_all(processor->task_queues);
653a74
 
653a74
 	DLEYNA_LOG_DEBUG("Exit");
653a74
 }
653a74
@@ -460,6 +461,7 @@ void dleyna_task_queue_task_completed(const dleyna_task_queue_key_t *queue_id)
653a74
 
653a74
 	if (processor->quitting && !processor->running_tasks) {
653a74
 		g_idle_add(processor->on_quit_cb, NULL);
653a74
+		g_hash_table_remove_all(processor->task_queues);
653a74
 	} else if (queue->defer_remove) {
653a74
 		DLEYNA_LOG_DEBUG("Removing queue <%s,%s>",
653a74
 				 queue_id->source, queue_id->sink);
653a74
-- 
653a74
2.7.4
653a74