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 682950 - GFileMonitor crashing on high event count when running in different thread
GFileMonitor crashing on high event count when running in different thread
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-08-29 14:26 UTC by shuerhaaken
Modified: 2012-10-06 14:42 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
testcase in C language (4.18 KB, text/plain)
2012-08-29 14:26 UTC, shuerhaaken 		  Details
GFileMonitor: thread-safety fix for non-default-main-context monitors (2.78 KB, patch)
2012-10-05 13:34 UTC, Dan Winship 		committed Details | Review

Description shuerhaaken 2012-08-29 14:26:34 UTC 
Created attachment 222782 [details]
testcase in C language

Hello

I'm trying to monitor a folder and it's decendant folders with GFileMonitor in a thread seperate from the main thread. A high number of events leads to a crash in the program.

I set up a testcase in C so it is possible to reproduce the problem.
To trigger the crash, I used a media player called xnoise: It has a function to scan a directory (in this case the music folder) with Taglib. Taglib accesses the files in -rw mode, so a lot of G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT signals are created. 
In my case ~600 folders are scanned. At some point my testcase program crashes.
Strange is that the crash can be avoided, if some prints are added to the signal handler.

Output in gdb:
Program received signal SIGSEGV, Segmentation fault.

+ Trace 230755

Thread 140737317189376 (LWP 8582)

  • #0 magazine_cache_trim
    at /build/buildd/glib2.0-2.32.3/./glib/gslice.c line 635
  • #1 magazine_cache_push_magazine
    at /build/buildd/glib2.0-2.32.3/./glib/gslice.c line 703
  • #2 thread_memory_magazine2_unload
    at /build/buildd/glib2.0-2.32.3/./glib/gslice.c line 802
  • #3 g_slice_free_chain_with_offset
    at /build/buildd/glib2.0-2.32.3/./glib/gslice.c line 1173
  • #4 emit_cb
    at /build/buildd/glib2.0-2.32.3/./gio/gfilemonitor.c line 394
  • #0 type_check_is_value_type_U
    at /build/buildd/glib2.0-2.32.3/./gobject/gtype.c line 4106
  • #1 g_type_check_is_value_type
    at /build/buildd/glib2.0-2.32.3/./gobject/gtype.c line 4134
  • #2 g_value_init
    at /build/buildd/glib2.0-2.32.3/./gobject/gvalue.c line 173
  • #3 g_object_newv
    at /build/buildd/glib2.0-2.32.3/./gobject/gobject.c line 1701
  • #4 g_object_new
    at /build/buildd/glib2.0-2.32.3/./gobject/gobject.c line 1542 
4101	in /build/buildd/glib2.0-2.32.3/./gobject/gtype.c
(gdb) 



Running the program in Valgrind with 
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --log-file=vgdump ./testcase
doesn't trigger the crash in the testcase.
Comment 1 shuerhaaken 2012-10-05 09:26:55 UTC 
This is a total disappointment!

As usually nobody ever reacts on a bug report. No confirmation, no fixes no questions. 
It's always the same.
I could also write a bug report on a piece of paper and throw it out of the window.

I am willing to help but as usually I am locked out.
Comment 2 Dan Winship 2012-10-05 13:34:27 UTC 
sorry, that's just how free software is; the only way to guarantee a bug gets fixed is to fix it yourself. In particular, there are some parts of glib that no one really "owns", so bugs filed against them aren't going to get looked at right away...
Comment 3 Dan Winship 2012-10-05 13:34:37 UTC 
Created attachment 225881 [details] [review]
GFileMonitor: thread-safety fix for non-default-main-context monitors

When queuing events to another thread, we need a mutex around
priv->pending_file_changes and priv->pending_file_change_source.
Comment 4 shuerhaaken 2012-10-05 15:49:16 UTC 
Thank you for taking care of this!
I almost gave up.
Comment 5 Colin Walters 2012-10-05 20:50:48 UTC 
Review of attachment 225881 [details] [review]:

This looks correct.
Comment 6 Dan Winship 2012-10-06 14:42:15 UTC 
Attachment 225881 [details] pushed as 7e6fa55 - GFileMonitor: thread-safety fix for non-default-main-context monitors