Thunar assigns date stamp of deleted file when previous (e.g. original) copy of file copied or moved into directory

[Kim Tucker]

video demonstrating the bug: http://youtu.be/9rU_5IUuMqM

While changing directory structures and trying to reduce the number of duplicate files on an external usb drive - dragging, dropping and deleting files manually with Thunar - I noticed the above (title/one line summary) in the following situation:

(e.g.) I have 2 identical files 'filename.ext' in two folders:
'folder-to-delete/' contains the original file with the original date stamp,
'folder-to-keep/' has the same file but a different (later) date stamp as it was copied previously (with this problem).

If I delete the file 'folder-to-keep/filename.ext' and then copy or move (drag/drop) the file 'folder-to-delete/filename.ext' into 'folder-to-keep/', the file now in 'folder-to-keep/' acquires a new date stamp (matching the deleted file).

However, if I drag or drop the file into an empty folder which has not previously contained a version of it, the original date stamp is retained (as I require/expect).

If I first move (by drag and drop) the unwanted file 'folder-to-keep/filename.ext' elsewhere, and then copy/move 'folder-to-delete/filename.ext' into 'folder-to-keep/', the original date stamp is retained (as I require/expect).

The problem is independent of whether I empty trash after deleting.

A quick test with Nautilus also in a Xubuntu session on the same system: no. Nautilus works as I would expect: copying, moving and replacing all retain the date stamp whether the unwanted file was previously deleted or moved or not (i.e. replaced).

NB Info above previously posted as a question:
https://answers.launchpad.net/ubuntu/+question/239397
http://askubuntu.com/questions/378793/thunar-assigns-date-stamp-of-deleted-file-when-original-copy-is-moved-into-that

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: thunar 1.6.3-1ubuntu1
ProcVersionSignature: Ubuntu 3.11.0-13.20-generic 3.11.6
Uname: Linux 3.11.0-13-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
Date: Tue Nov 19 09:49:22 2013
InstallationDate: Installed on 2012-11-04 (379 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64+mac (20121017.3)
MarkForUpload: True
SourcePackage: thunar
UpgradeStatus: Upgraded to saucy on 2013-10-24 (25 days ago)

[Alistair Buxton (a-j-buxton)]

I can't reproduce this with thunar, 13.10, and a ext4 filesystem.

Perhaps this is related to the USB drive being a FAT filesystem? Could you try to reproduce this on your homedir?

[Kim Tucker (ktucker)]

Yes, it does seem to be related to fat32, though the problem is still evident when Thunar is showing a directory on ext4.

When retesting I also had a few surprises (unable at first to reproduce). It is tricky because one has to check with 'ls -al' that what Thunar shows corresponds the actual date stamp.

A few more tests copying/moving/replacing only on the ext4 drive seem fine, a few tests only on fat32 seemed fine, but if I copy/move from fat32 to ext4 (or vice-versa), then what Thunar displays does not agree with 'ls -al'. View Reload and ctrl-r do not help (they should).

It seems that Thunar caches some info about the file. If I exit Thunar completely and then view the same folder again (on ext4, or fat32) it displays the correct date modified.

[Alistair Buxton (a-j-buxton)]

I see: I misunderstood the problem at first. The incorrect date is only shown in Thunar, not anywhere else. I can reproduce this just using regular files/filesystems.

[Alistair Buxton (a-j-buxton)]

If you delete a file, and then copy in another file with the same name, the old file's modification date is shown. For example:

 mkdir -p ~/test/del/ ~/test/keep/
 touch -d 20120103 ~/test/del/foo.txt
 touch -d 20090103 ~/test/keep/foo.txt

Now open a thunar window on each directory. Delete either file, and copy over the other one. The timestamp is "sticky". This isn't reflected at the filesystem level, and the error does not persist after thunar is restarted.

Here is a video demonstrating the bug:

http://youtu.be/9rU_5IUuMqM

This might be related to the other thunar timestamp bugs, but opening a new bug because this is a specific, easily reproducible case.

[Alistair Buxton (a-j-buxton)]

This bug was reported downstream at https://bugs.launchpad.net/thunar/+bug/1252655

[Richardbrucebaxter-8 (richardbrucebaxter-8)]

When replacing a file the Date Modified does not update. The user must exit and re-enter the folder for the correct Date Modified to be shown.

Note this bug has been around in some form for at least 2 years and probably longer. I believe it started to occur between Thunar's release on EL5 (~Thunar-1.0.2-2) and EL6 (~Thunar-1.3.0-4), although my first record of this bug is January 2013 (EL6.3).

I have marked this bug as "major" because the display of correct files dates is crucial when transferring data between folders (e.g. replacing backups).

[Richardbrucebaxter-8 (richardbrucebaxter-8)]

There exists another related issue;

Sometimes even when exiting and re-entering the folder the date modified will remain the same (e.g. when browsing an external drive). The user must open a new instance of Thunar for the correct modified date to be displayed.

[Goth Queen (artistbraab)]

I see the same bug in Thunar (Xfce, Trusty 14.04, 3.13.0-36). This is really striking in an example like this (was done as root): replaced a symlink. The new symlink had the same name as the old one, but points to a totally different file. Original symlink was deleted. New symlink copied into drectory. According to Thunar, the new symlink points to the old (original) file. Also the size and date of the original file, and not the new file are shown. Right click on the (new!) symlink and viewing the properties gives the details of the original (old) symlink.

Refreshing does not solve the issue.

Killing all Thunar sessions and starting Thunar again, navigating to the previous directory: symlink will now display correct/ new properties.

This behaviour is seen in Thunar both as user and as root.
Did not test whether, if 2 Thunar sessions open, only one is killed and restarted, the properties displayed will differ between the two...

Although this describes a procedure with a symlink, I have seen similar behaviour with files.

[Rik (riksoft)]

The same problem happens with the file size
https://bugzilla.xfce.org/show_bug.cgi?id=11468
and that's even more dangerous than file date.

[Matt Thirtytwo (LinuxMatt) (matt-59491)]

I haven't found yet how to properly fix this bug.
A temporary and ugly patch is here:
https://gist.github.com/LinuxMatt/640ed8b1dda47794b458

[Matt Thirtytwo (LinuxMatt) (matt-59491)]

Does this bug look similar to bug 11008 ?

[Rik (riksoft)]

Meanwhile waiting for a fix to come out, I've shifted to PCManFM (and Nemo because PCManFM is lighter but has some bugs as well and once in a while it crashes on smb://).

[Alistair Buxton (a-j-buxton)]

Yes it's the same bug.

*** This bug has been marked as a duplicate of bug 11008 ***

[Alistair Buxton (a-j-buxton)]

*** Bug 10504 has been marked as a duplicate of this bug. ***

[Peter de Ridder (cavalier)]

*** Bug 11468 has been marked as a duplicate of this bug. ***

[Peter de Ridder (cavalier)]

Created attachment 5903
Assume file changed while in cache

This might be a performance penalty, but this seems to refresh the file info on copy.

[Steve Dodier-Lazaro (sidi)]

Tested, works.

[Hjudt-l (hjudt-l)]

Pushed to master: http://git.xfce.org/xfce/thunar/commit/?id=cc8d1331e305f2af5842607d885eb96608b8fce7

[Hjudt-l (hjudt-l)]

Created attachment 6089
Fix-updating-file-info-for-moved-files-bug-11008.patch

The previous solution in attachment #5903 causes crashes because of freeing and accessing file info in parallel threads, spawned by thunar jobs. An easy way to reproduce such a crash, or at least to create critical errors, is to drag & drop move lots of files into a subfolder one by one.

This needs to be reverted and replaced by a proper fix. The attached patch fixes this for me.

[Hjudt-l (hjudt-l)]

GFileMonitor Test application:

Download and compile https://gist.githubusercontent.com/dmatveev/2295597/raw/973da911a653550d762cffea20153db9ca52400b/gistfile1.c

gcc -o gfilemonitor gistfile1.c $(pkg-config --cflags glib-2.0) $(pkg-config --libs glib-2.0) $(pkg-config --libs gio-2.0)

Now for a file or folder to watch, execute it with the path as argument:
(1) gfilemonitor test/first
(2) gfilemonitor test/second

touch test/first/a test/first/b
(1) Received event CREATED: (code 3), first file "a", second file "--"
    Received event ATTRIBUTE_CHANGED: (code 4), first file "a", second file "--"
    Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--"
    Received event CREATED: (code 3), first file "b", second file "--"
    Received event ATTRIBUTE_CHANGED: (code 4), first file "b", second file "--"
    Received event CHANGES_DONE_HINT: (code 1), first file "b", second file "--"

Test case 1: Move a file to another folder
mv test/first/a to test/second/a
(1) Received event DELETED: (code 2), first file "a", second file "--"
(2) Received event CREATED: (code 3), first file "a", second file "--"
    Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--"

Test case 2: Move a file in the same folder
Recreate test/first/a: touch test/first/a
mv test/first/a test/first/b
(1) Received event MOVED: (code 7), first file "a", second file "b"
(2) --

Test case 3: Copy a file to another folder (does not exist there)
cp test/first/a test/second/a
(1) --
(2) Received event CREATED: (code 3), first file "a", second file "--"
    Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--"

Test case 4: Move a file using thunar cut & paste (target file does not exist)
(1) Received event DELETED: (code 2), first file "a", second file "--"
(2) Received event CREATED: (code 3), first file "a", second file "--"
Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--"

Test case 5: Move a file using thunar cut & paste (target file exists)
(1) Received event DELETED: (code 2), first file "a", second file "--"
(2) Received event CREATED: (code 3), first file ".goutputstream-97BSVX", second file "--"
    Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--"
    Received event MOVED: (code 7), first file ".goutputstream-97BSVX", second file "a"
    Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--"
    Received event ATTRIBUTE_CHANGED: (code 4), first file "a", second file "--"

[Hjudt-l (hjudt-l)]

Using both a file monitor and a dir monitor on both directories, and additionally a file monitor and a dir monitor on the moved file, it looks like everything is ok with gio.

Just for the record, if SEND_MOVED was not used, the following gio bug could have been triggered, but thunar uses SEND_MOVED in 1.6.6:
https://bugzilla.gnome.org/show_bug.cgi?id=742849

[Hjudt-l (hjudt-l)]

*** Bug 11734 has been marked as a duplicate of this bug. ***

[Hjudt-l (hjudt-l)]

Created attachment 6118
Always-reload-info-for-files-that-might-have-been-changed-by-jobs.patch

This patch obsoletes the previous patches (though parts of my previous patch might still be correct to apply) and fixes the update issues for me.

[Hjudt-l (hjudt-l)]

Created attachment 6119
Fix-updating-file-info-for-moved-files-bug-11008.patch

This patch is still necessary for updates caused by move operations. I have corrected one check so it should work properly now.

[Hjudt-l (hjudt-l)]

There is still the problem that the folder monitor does not receive any events for the following scenario:

1) touch x
2) mkdir test
3) open test in thunar
4) mv x test

test is not updated to reflect the move.

If you open another window with the source directory before 4), then the changes will propagate and the views will update correctly.

[Hjudt-l (hjudt-l)]

It seems the issues with filemonitor events not being triggered have to do with the shortcut side pane. Turning the sidepane off (but also switching to tree-view sidepane probably) will make the test cases work as expected. However, these new findings may not completely invalidate the previous patches.

[Hjudt-l (hjudt-l)]

Created attachment 6126
0001-Add-function-to-reload-parent-file-of-a-file.patch

Another patchset for reloading issues (1/3)

[Hjudt-l (hjudt-l)]

Created attachment 6127
0002-Rework-thunar_file_monitor-to-properly-register-move.patch

Another patchset for reloading issues (2/3)

[Hjudt-l (hjudt-l)]

Created attachment 6128
0003-Refactor-code-for-moving-thumbnail-cache-file-on-ren.patch

Another patchset for reloading issues (3/3)

[Hjudt-l (hjudt-l)]

Created attachment 6129
0004-Reload-parent-folder-of-changed-file.patch

Fix update of parent folder in folder-monitor.c

[Hjudt-l (hjudt-l)]

Comment on attachment 6129
0004-Reload-parent-folder-of-changed-file.patch

This patch is bad and should not be applied.

[Hjudt-l (hjudt-l)]

Unfortunately, there is another test case that doesn't work:

1) echo 2000 > x; mkdir test; touch test/x
2) open thunar
3) cut x
4) change into test
5) select x
6) paste

There are delete events for the source folder, but the destination folder does not receive any events. Also, reloading the folder does not help.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

*** Bug 11707 has been marked as a duplicate of this bug. ***

[Hjudt-l (hjudt-l)]

Created attachment 6132
Fix-updating-file-info-for-moved-files-bug-11008.patch

Update patch to protect against unreadable files.

[Hjudt-l (hjudt-l)]

(In reply to Harald Judt from comment #23)
> Unfortunately, there is another test case that doesn't work:
>
> 1) echo 2000 > x; mkdir test; touch test/x
> 2) open thunar
> 3) cut x
> 4) change into test
> 5) select x
> 6) paste
>
> There are delete events for the source folder, but the destination folder
> does not receive any events. Also, reloading the folder does not help.

Note that thunar-job.c signal-emits new_files for the new_files closure, but the standard-view does not call thunar_standard_view_new_files.

There is something else strange here: After step 6), the following happens:
thunar_file_monitor: event_path=/home/user/x, other_path=/home/user/(null)/x, file=user, event_type=7

What happened to test (other_path=...(null))???

[Hjudt-l (hjudt-l)]

Further observations:

1) File moves via cut & paste into the same window do not receive the new_files signals, thus thunar_standard_view_new_files will NOT be called. Therefore, file info for an existing target file will not be updated. If the target file does not exist, the file will of course have the correct attributes, but after the folder reload thunar_file_monitor will be invoked with the target folder being (null) in other_path (e.g. /home/user/(null)/x).

2) File moves via cut & paste using two windows, one serving as source and one as target, do receive the new_files signals, thus thunar_standard_view_new_files will be called in the target window and the info for the target file will be updated for an existing file.

In the source window, there will be no MOVED event emitted for the source window, only two DELETEs, one logged by thunar_folder_monitor and one by thunar_file_monitor.

If the target file does not exist, the new target file will have the correct attributes in the target window, but as in 1), after folder reload thunar_file_monitor will be invoked in the target window with the target folder being (null) in other_path (e.g. /home/user/(null)/x).

3) With copy & paste there are no such bugs, the new_files signals will be received and the files reloaded properly. With cut & paste, thunar_clipboard_manager_clear_callback gets called before the end of tsv_action_paste, while with copy & paste, it gets called on window close. In both cases, it releases all pending files.

[Hjudt-l (hjudt-l)]

thunar_file_monitor: event_path=/home/user/x, other_path=/home/user/(null)/x, file=user, event_type=7

This happens even without any of the patches, so it is not caused by them.

[Hjudt-l (hjudt-l)]

*** Bug 11763 has been marked as a duplicate of this bug. ***

[Hjudt-l (hjudt-l)]

I stand corrected, it also happens with copy&paste. But I got a bit further to a solution: Indeed, this seems to be a timing problem.

http://git.xfce.org/xfce/thunar/tree/thunar/thunar-job.c#n573
Adding sleep (1); before this line solves the problem for me:

--
      /* emit the "new-files" signal */
      sleep (1);
      exo_job_emit (EXO_JOB (job), job_signals[NEW_FILES], 0, file_list);
--

The move event is also properly triggered, with no "(null)" in other_path.

[Hjudt-l (hjudt-l)]

Interestingly, with the sleep(1) https://bugzilla.xfce.org/attachment.cgi?id=6118 is rendered unnecessary, and the standard view is updated properly.

[Hjudt-l (hjudt-l)]

An additional test case for verification (though it does not bring any new revelations):

1) Generate lots of files:
for i in $(seq 1 1000); do echo "$i" > "$i".txt; done

2) Cut files using thunar Edit->Cut

3) Create a new directory test

4) Change dir to test in thunar

5) Paste files in thunar

Behold the many object_unref errors:

(thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(thunar:31965): GLib-GObject-WARNING **: invalid uninstantiatable type '(null)' in cast to 'GObject'

(thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(thunar:31965): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GObject'

(thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(thunar:31965): GLib-GObject-WARNING **: invalid uninstantiatable type '<invalid>' in cast to 'GObject'

(thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

[Hjudt-l (hjudt-l)]

The final piece of the puzzle: The new-files closure gets invalidated by thunar_standard_view_selection_changed while still being in use. Because of this, the signals sent by the job cannot be received and get lost. This also causes the g_object_ref/unref errors in comment #32.

Treatment of the new-files closure needs to be changed, maybe tsv can be extended to allow multiple closures so that all running jobs can finally send their list of changed files. The new-files closure is used by tsv_selection_changed to select new files after a job has finished (e.g. after file move select the moved files in the target folder).

[Hjudt-l (hjudt-l)]

A better solution than reloading the file info for all files in the new-files closure is to move/copy the file info in thunar-transfer-job.c for cached files only.

[Hjudt-l (hjudt-l)]

Created attachment 6180
reload-files-changed-by-jobs-in-an-idle-loop.patch

This builds on top of the other patches and obsoletes attachment #6118.

With this, complicated changes to the closures system are unnecessary and all files will get scheduled for reload in idle before the new-files signal is emitted.

[Hjudt-l (hjudt-l)]

A temporary repository with all necessary patches based on up-to-date master is here: http://git.xfce.org/users/hjudt/thunar/log/?h=fix-bug-11008

[Hjudt-l (hjudt-l)]

*** Bug 9340 has been marked as a duplicate of this bug. ***

[Hjudt-l (hjudt-l)]

*** Bug 9446 has been marked as a duplicate of this bug. ***

[Hjudt-l (hjudt-l)]

*** Bug 11829 has been marked as a duplicate of this bug. ***

[Hjudt-l (hjudt-l)]

The patches have been merged to master. So far, all tests have turned up nothing bad, and the reload seems working fine.

[Hjudt-l (hjudt-l)]

BTW: What has not been fixed yet is the issue described in bug #9245. It's a minor issue though and hitting F5 / reload is a usable workaround.

[Hjudt-l (hjudt-l)]

*** Bug 10955 has been marked as a duplicate of this bug. ***

[Geoffrey De Belie (computergeoffrey)]

(In reply to Harald Judt from comment #40)
> The patches have been merged to master. So far, all tests have turned up
> nothing bad, and the reload seems working fine.

Not sure if this is related to this patch set, but scrolling up in a directory (with detailed view) when Thunar is reloading the file list scrolls down automatically, to the position before the reloading started.

[Ahoka-2 (ahoka-2)]

This recent patch causes Thunar to crash when you have two windows or tabs open in the same directory and then delete a file inside of that directory.
Here is a backtrace for it:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004367da in thunar_file_info_reload (file=file@entry=0xdd2210, cancellable=cancellable@entry=0x0) at thunar-file.c:976
976 if (strcmp (file->basename, "kmsg") == 0
(gdb) bt
#0 0x00000000004367da in thunar_file_info_reload (file=file@entry=0xdd2210, cancellable=cancellable@entry=0x0) at thunar-file.c:976
#1 0x0000000000436c41 in thunar_file_load (file=file@entry=0xdd2210, error=error@entry=0x0, cancellable=0x0) at thunar-file.c:1178
#2 0x000000000043893b in thunar_file_get (gfile=gfile@entry=0x0, error=error@entry=0x0) at thunar-file.c:1237
#3 0x0000000000438c92 in thunar_file_monitor (monitor=<optimized out>, event_path=0xe178e0, other_path=0x0, event_type=<optimized out>, user_data=<optimized out>)
    at thunar-file.c:802
#4 0x00007fffefdef04c in ffi_call_unix64 () from /usr/lib64/libffi.so.6
#5 0x00007fffefdeea1a in ffi_call () from /usr/lib64/libffi.so.6
#6 0x00007ffff4e4b535 in g_cclosure_marshal_generic_va (closure=0xc275d0, return_value=0x0, instance=0xbae380, args_list=<optimized out>, marshal_data=0x0, n_params=3,
    param_types=0xc24170) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gobject/gclosure.c:1594
#7 0x00007ffff4e4aac7 in _g_closure_invoke_va (closure=closure@entry=0xc275d0, return_value=return_value@entry=0x0, instance=instance@entry=0xbae380,
    args=args@entry=0x7fffffffc2c8, n_params=3, param_types=0xc24170) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gobject/gclosure.c:864
#8 0x00007ffff4e63988 in g_signal_emit_valist (instance=0xbae380, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffc2c8)
    at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gobject/gsignal.c:3216
#9 0x00007ffff4e645da in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0)
    at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gobject/gsignal.c:3363
#10 0x00007ffff50e4efb in g_file_monitor_emit_event (monitor=<optimized out>, child=<optimized out>, other_file=<optimized out>, event_type=<optimized out>)
    at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gio/gfilemonitor.c:275
#11 0x00007ffff5189879 in g_file_monitor_source_dispatch (source=0xc1c620, callback=<optimized out>, user_data=<optimized out>)
    at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gio/glocalfilemonitor.c:546
#12 0x00007ffff4b4bae4 in g_main_dispatch (context=0x73d3b0) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/glib/gmain.c:3122
#13 g_main_context_dispatch (context=context@entry=0x73d3b0) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/glib/gmain.c:3737
#14 0x00007ffff4b4bd38 in g_main_context_iterate (context=0x73d3b0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/glib/gmain.c:3808
#15 0x00007ffff4b4bffa in g_main_loop_run (loop=0x74ddc0) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45....

[Sean Davis (bluesabre)]

Reportedly fixed upstream.