|Summary:||x11-fm/thunar: Crash on Directory Delete (exited on signal 6)|
|Product:||Ports & Packages||Reporter:||vermaden|
|Component:||Individual Port(s)||Assignee:||freebsd-xfce mailing list <xfce>|
|Severity:||Affects Many People||CC:||duchateau.olivier, madpilot, vermaden|
Description vermaden 2017-08-21 00:29:29 UTC
Aug 21 02:30:23 t520 kernel: pid 78250 (thunar), uid 1000: exited on signal 6
Comment 1 vermaden 2017-08-21 00:32:18 UTC
To reproduce: 1. Create new directory. 2. Enter that directory. 3. Get back to level up (..) where You were while creating it. 4. Right click on created directory and delete it. 5. Instant crash everytime.
Comment 2 vermaden 2017-08-21 00:33:02 UTC
This is 11.1-RELEASE-p1 with THUNAR from official packages.
Comment 3 vermaden 2017-08-21 01:07:49 UTC
Created attachment 185622 [details] thunar.truss.txt Truss output.
Comment 4 vermaden 2017-08-21 01:08:08 UTC
% truss -o thunar.truss.txt thunar GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Resource deadlock avoided. Aborting.
Comment 5 vermaden 2017-08-21 01:12:22 UTC
Same as this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221680
Comment 7 vermaden 2017-08-21 12:25:08 UTC
(In reply to Olivier Duchateau from comment #6) With 1.6.12 from the link You gave its the save behaviour, instant crash. Regards, vermaden
Comment 8 Olivier Duchateau 2017-08-21 15:12:37 UTC
(In reply to vermaden from comment #7) I think problem comes from GLib currently there are 2 patches (not tested, the GNOME team waits a review from upstream) using: - inotify kqueue backend bug #199872, comment #11. - another kqueue backend bug #214338
Comment 9 vermaden 2017-08-21 15:21:19 UTC
(In reply to Olivier Duchateau from comment #8) Its almost 2 years for the first one and several months for the second one. Can You guess how much longer would it take to apply the GLIB fix?
Comment 10 Olivier Duchateau 2017-08-21 18:22:45 UTC
(In reply to vermaden from comment #9) I don't know, kqueue backend is used by all BSD. Changing or modifying can occur side effects (e.g., for the Xfce desktop) panel events are not anymore monitored, menu is not updated (when we add new application) and so on.
Comment 11 vermaden 2017-08-21 19:21:31 UTC
(In reply to Olivier Duchateau from comment #10) IMHO instant crash every time is more PITA.
Comment 12 Guido Falsi 2017-09-30 14:13:18 UTC
Created attachment 186813 [details] xfdesktop crash backtrace I'm analyzing this crash. First thing I compiled a system with debugging symbols and extracted a backtrace from the core file. I'm adding here in case anyone find the information useful. I can try to extract more data form the crash if needed.
Comment 13 Guido Falsi 2017-09-30 14:34:11 UTC
(In reply to Guido Falsi from comment #12) > Created attachment 186813 [details] > xfdesktop crash backtrace > > I'm analyzing this crash. Disclaimer: I have very little experience with multi-threaded programming and mutexes. My first analysis is that in the specific code path glib is trying to acquire the same mutex lock twice in a row in the same thread, which is clearly a bad thing. The lock is acquired in process_kqueue_notifications (kqueue-helper.c:292) and again in _kh_cancel_sub (kqueue-helper.c:509), causing the abort and core dump. More testing needed before I can suggest a patch.
Comment 14 Guido Falsi 2017-11-16 23:17:21 UTC
The problems reported in this bug are at least in part addressed in the patch I posted on bug 199872. The actual problem is in glib. Please test that patch and send feedback is it works for you too or not.
Comment 15 vermaden 2018-01-27 20:16:37 UTC
You may CLOSE this bug as it has been fixed in GLIB: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199872
Comment 16 Guido Falsi 2018-01-27 21:37:17 UTC
fixed in r460052