Package: epiphany-browser Version: 3.4.2-2 Severity: serious Tags: patch
Machine: Dell PowerEdge 3250 Processor: 2x Itanium Madison 1.5GHz 6M Memory: 16GWhile working on bug#642750, I realized a failing assertion in the epiphany browser:
at lib/history/ephy-history-service.c:363 g_assert (priv->history_thread == g_thread_self ());The assertion failed almost often upon the start of epiphany browser; sometimes epiphany could start with success.
The ephy_history_service_init() function creates a new thread (using g_thread_new()); run_history_service_thread() is the starting function of the thread.
static void ephy_history_service_init (EphyHistoryService *self) { self->priv = EPHY_HISTORY_SERVICE_GET_PRIVATE (self);self->priv->history_thread = g_thread_new ("EphyHistoryService", (GThreadFunc) run_history_service_thread, self);
self->priv->queue = g_async_queue_new (); } static gpointer run_history_service_thread (EphyHistoryService *self) { EphyHistoryServicePrivate *priv = self->priv; EphyHistoryServiceMessage *message; g_assert (priv->history_thread == g_thread_self ()); if (ephy_history_service_open_database_connections (self) == FALSE) return NULL; do { message = g_async_queue_try_pop (priv->queue); if (!message) { /* Schedule commit if needed. */ if (ephy_history_service_is_scheduled_to_commit (self)) ephy_history_service_commit (self); /* Block the thread until there's data in the queue. */ message = g_async_queue_pop (priv->queue); } /* Process item. */ ephy_history_service_process_message (self, message); } while (!ephy_history_service_is_scheduled_to_quit (self)); ephy_history_service_close_database_connections (self); ephy_history_service_execute_quit (self, NULL, NULL); return NULL; }The third non-empty line of run_history_service_thread() is the failing assertion.
The assertion fails because the created thread can execute its code before g_thread_new() returns and before the history_thread member is initialized. Whether it happens or not depends on how the operating system schedules the processors to the threads.
The history_thread member isn't any problem; it is used just for the assertions. But there is also an async queue (->queue) which is initialized *after* creating the new thread in ephy_history_service_init(). This means that the code in run_history_service_thread() touches the queue when it isn't initialized or while the queue is being initialized by the main thread.
That isn't healthy; this can result in data corruption. The patch - fixes the issue with the queue, and - fixes the mentioned assertion. Although it was experienced on ia64, the bug affects all archs. You can find a link to the built debs on bug report#642750. Stephan
history-thread-startup-race.patch
Description: history-thread-startup-race.patch