Aug 21 02:30:23 t520 kernel: pid 78250 (thunar), uid 1000: exited on signal 6
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.
This is 11.1-RELEASE-p1 with THUNAR from official packages.
Created attachment 185622 [details]
% truss -o thunar.truss.txt thunar
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Resource deadlock avoided. Aborting.
Same as this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221680
Please, can you test bug #220407
(In reply to Olivier Duchateau from comment #6)
With 1.6.12 from the link You gave its the save behaviour, instant crash.
(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
(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?
(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.
(In reply to Olivier Duchateau from comment #10)
IMHO instant crash every time is more PITA.
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.
(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.
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.
You may CLOSE this bug as it has been fixed in GLIB:
fixed in r460052