GNOME Bugzilla – Bug 731431
PCManFM hangs when Sidebar is in Directory Tree mode
Last modified: 2018-05-02 16:08:53 UTC
Initially I have reported the bug on the PCManFM tracker ( https://sourceforge.net/p/pcmanfm/bugs/857/ ) but it seems this is a GTK+ bug. As figured out in the linked ticket PCManFM hangs if the directoty tree is enabled and some special actions are done. The bug appears in GTK+ 2.24.23 but not in GTK+ 2.24.20.
When it hangs, is there a stacktrace available?
In the linked report is a log from GDB: sourceforge.net/p/pcmanfm/bugs/857/attachment/gdb.log
Edit: This was the older log. Here is the new one: sourceforge.net/p/pcmanfm/bugs/_discuss/thread/25f09343/262c/attachment/gdb.log
(In reply to comment #0) > Initially I have reported the bug on the PCManFM tracker ( > https://sourceforge.net/p/pcmanfm/bugs/857/ ) but it seems this is a GTK+ bug. The bug report does not mention GTK a single time. Could you explain why this might be GTK related? Copying the stacktrace content here, after manually fixing the broken link: sworddragon@ubuntu:~$ gdb pcmanfm GNU gdb (Ubuntu 7.7.1-0ubuntu1) 7.7.1 Reading symbols from pcmanfm...Reading symbols from /usr/lib/debug/.build-id/0b/afd06914c59bb5b49839d67f3100ab64c241a1.debug...done. done. (gdb) run Starting program: /usr/bin/pcmanfm [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Traceback (most recent call last): File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20-gdb.py", line 59, in <module> from libstdcxx.v6.printers import register_libstdcxx_printers File "/usr/lib/x86_64-linux-gnu/../../share/gcc-4.9/python/libstdcxx/v6/printers.py", line 392 raise ValueError, "Unsupported implementation for %s" % str(node.type) ^ SyntaxError: invalid syntax [New Thread 0x7fffeef93700 (LWP 6263)] ** (pcmanfm:6259): WARNING **: terminal x-terminal-emulator isn't known, consider report it to LibFM developers [New Thread 0x7fffee792700 (LWP 6264)] ** (pcmanfm:6259): DEBUG: starting modules initialization ** (pcmanfm:6259): WARNING **: modules directory is not accessible ** (pcmanfm:6259): WARNING **: modules directory is not accessible ** (pcmanfm:6259): DEBUG: done with modules [New Thread 0x7fffe6657700 (LWP 6265)] ** (pcmanfm:6259): DEBUG: reactivated gestures to page 0 ** (pcmanfm:6259): DEBUG: reactivated gestures to page 0 ** (pcmanfm:6259): DEBUG: unable to load icon . GThemedIcon application-octet-stream application-x-generic [Thread 0x7fffe6657700 (LWP 6265) exited] [New Thread 0x7fffe6657700 (LWP 6266)] ** (pcmanfm:6259): DEBUG: unable to load icon . GThemedIcon application-x-raw-disk-image application-x-generic [Thread 0x7fffe6657700 (LWP 6266) exited] [New Thread 0x7fffe6657700 (LWP 6267)] [Thread 0x7fffe6657700 (LWP 6267) exited] ** (pcmanfm:6259): DEBUG: reactivated gestures to page 1 ^C Program received signal SIGINT, Interrupt. 0x00007ffff5087fbd in poll () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) thread apply all bt full
+ Trace 233684
> The bug report does not mention GTK a single time. There is more than one site.
Question still stands: Could you explain why this might be GTK related? I see now that there is a comment "Unfortunately it seems to hang inside of gtk" in Sourceforge, but I'd love to know *where exactly* that can be seen.
> Question still stands: Could you explain why this might be GTK related? I can't give you more details as the linked ticket has. But likely you are looking for this part posted by one of the maintainers: > So it appear to be regression bug in GTK+ then. And they changed windows update between 2.24.20 and 2.24.23, that probably causes this.
Not a useful stacktrace, unfortunately. A quick test with sudo pcmanfm does not produce any obvious problem, compared to running it normally. In particular, no hang.
> A quick test with sudo pcmanfm does not produce any obvious problem, compared to running it normally. In particular, no hang. Maybe you want to try this from the linked ticket to see if it hangs: > Open PCManFM. > Go up to / and then down to /var. > Create a new tab. > Click the home button.
Hello there. I am the main developer of pcmanfm in meantime. So far in mentioned log I see GDK thread waits on the conditional:
+ Trace 233694
and it waits it forever (no further window update happens as it is clearly visible in screened video). There is no such problem in GTK+ 2.24.40 so only sane explanation of that is latest changes in gdk/gdkwindow.c which somehow broke GdkWindow updates, that explains why it happens not every time - the most probably if two updates for the same window are scheduled in single idle cycle, they are now handled incorrectly. That is just a supposition though, I never digged into GDK so much deeply. Thank you very much.
I meant 2.24.20, not 2.24.40, of course, just mistyped it, sorry.
(In reply to comment #10) > So far in mentioned log I see GDK thread waits on the conditional: Could somebody provide a trace with debug symbols (listing filenames and line numbers)?
Created attachment 278430 [details] GDB log with debug symbols Here is the log with debug symbols on PCManFM, GTK and GLib.
I'm now on PCManFM 1.2.2, LibFM 1.2.2.1, GLib 2.42.0 and GTK 2.24.24 but the issue still exists. Does the last trace I have posted probably give a hint what might cause this issue?
Still no luck in reproducing any hangs here. I'm trying with $ rpm -q pcmanfm pcmanfm-1.2.2-1.fc21.x86_64 Maybe this explains why we are seeing different behavior ? $ ldd /usr/bin/pcmanfm | grep gtk libfm-gtk3.so.4 => /lib64/libfm-gtk3.so.4 (0x00007f95e603b000) libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x00007f95e578d000) This pcmanfm is using gtk3
On executing "ldd /usr/bin/pcmanfm | grep gtk" I'm getting this: libfm-gtk.so.4 => /usr/lib/x86_64-linux-gnu/libfm-gtk.so.4 (0x00007fed36278000) libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007fed35c2a000) But I'm always on the development version of Ubuntu (x86_64).
I'm sorry to add my 5 cents but this bug is opened exactly against GTK+ 2.24, not against GTK+ 3.x. There are a lot of other bugs against GTK+ 3.x but they aren't relevant to this one which was introduced after version 2.24.20. Don't try to get issue subject shifted out, please, use GTK+ 3.x isn't a fix. Thank you.
A.G.: Please see https://wiki.gnome.org/CodeOfConduct before assuming bad intention. Assume people mean well. Thank you.
André Klapper, I am truly sorry if my comment was seemed as if I assumed bad intentions, I just wanted to point out that this issue is about version 2.24.x, nothing more, and I'm sorry if that offended you. In any case, thank you for your work, I know what it is to handle such project well.
I'm still seeing this issue with GTK+ 2.24.28. @Matthias Clasen: Was you maybe able to reproduce this issue in the meantime with a version of PCManFM which uses GTK+ 2?
fwiw, for me, running sudo pcmanfm, I don't get a freeze per se, but I do get broken responsiveness: * I can click on things in the sidebar Directory Tree, and the window title does update, but nothing else does - not the sidebar nor the main view * the folders 'selected' in this mode can get offset from what you're clicking * the main view becomes unresponsive too Turning off the Directory Tree (before you partially lock up the window) makes things seem OK, though I only tested that superficially.
-- 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/gtk/issues/493.