GNOME Bugzilla – Bug 778002
race in gdbusprivate.c detected by the ThreadSanitizer
Last modified: 2017-02-05 13:20:51 UTC
Created attachment 344665 [details] AddressSanitizer output I initially found a refcount problem with a GDBusMessage object, as decribed in this AddressSanitizer output.
Created attachment 344666 [details] ThreadSanitizer log the ThreadSanitizer gives a hint where a data race occurs, that may explain the problem : * schedule_writing_unlocked() is called while holding the worker->write_lock lock in the main thread, and worker->pending_close_attempts in written in this context. * schedule_pending_close() is called from the gdbus thread, without the protection the the write_lock, and read the same memory location.
Created attachment 344667 [details] [review] Grab the write_lock before calling schedule_writing_unlocked() This patch fixes the race.
Review of attachment 344667 [details] [review]: Looks good to me. This bug was introduced in commit 512e9b3b, which moved that code out of continue_writing(), which held the write_lock at the time.
Review of attachment 344667 [details] [review]: Thanks for the patch, and thanks Philip for the extra detective work. This is fine to merge, with an appropriate commit message (bug reference, and mentioning the commit that introduced the issue).
Created attachment 344875 [details] [review] gdbus: make sure to stay locked when sending message This patch fixes a case where schedule_writing_unlocked() was called without holding the write lock. The bug was introduced in commit 512e9b3b.
Review of attachment 344875 [details] [review]: Great! Do you have git access to push this yourself?
I went ahead and pushed it. Thanks for the patch. Attachment 344875 [details] pushed as c457ec0 - gdbus: make sure to stay locked when sending message