After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 748642 - Issue with g_source finalize callback
Issue with g_source finalize callback
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: mainloop
2.40.x
Other Linux
: Normal major
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-04-29 13:47 UTC by Tirpak Balazs
Modified: 2018-05-24 17:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
call trace (6.44 KB, text/plain)
2015-04-29 13:47 UTC, Tirpak Balazs
Details

Description Tirpak Balazs 2015-04-29 13:47:45 UTC
Created attachment 302566 [details]
call trace

Hi!

We have an issue with g_source's finalize callback. It seems that it is called from two different threads with the same source. See attachment.

It also seems that this patch aaaaab91de10445a178e8183a95d98189249e868 (relevant bugid: 619329) though not causing it, triggers it very frequently.

We also found this patch b358202856682e5cdefb0b4b8aaed3a45d9a85fa (relevant bug ids: 586432, 626702, 634239), which seems to be a bad idea. Every time the finalize callback called, the context lock is released and g_main_context_check->g_source_iter_next->g_source_unref_internal will be able to grab the lock immediately. (Hence the trace we have).
Comment 2 Dan Winship 2015-05-01 13:30:10 UTC
(In reply to Tirpak Balazs from comment #0)
> We also found this patch b358202856682e5cdefb0b4b8aaed3a45d9a85fa (relevant
> bug ids: 586432, 626702, 634239), which seems to be a bad idea. Every time
> the finalize callback called, the context lock is released and
> g_main_context_check->g_source_iter_next->g_source_unref_internal will be
> able to grab the lock immediately. (Hence the trace we have).

Anyone that is keeping a pointer to the source needs to have their own ref on it (or at least, needs to be sure that someone else will be holding a ref on it for longer than they need to refer to it). So if the ref count has reached 0 and the finalize function gets called in one thread, that implies that no other thread should still have a pointer to that source. (In particular, in order to get the backtrace here, someone had to have called g_source_ref() on the source when it already had a ref count of 0.)

I can't tell from the trace if the bug is in your code or in GLib, although the fact that no one else has hit this in the 3 years since bug 619329 was closed suggests it's probably your code.

Can you come up with a simple reproducer? If not, I think this is NOTGNOME.
Comment 3 GNOME Infrastructure Team 2018-05-24 17:48:21 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1031.