Created attachment 8096 Patch On the FreeBSD mailing lists it's been reported that xfburn 0.5.5 crashes when trying to burn an audio CD. Here is a link to the mailing list thread: https://lists.freebsd.org/pipermail/freebsd-xfce/2018-November/002205.html I'm pasting here a backtrace of the crash: ** (xfburn:6198): WARNING **: 15:32:13.999: unknown profile, assuming BD ** (xfburn:6198): WARNING **: 15:32:14.001: unknown profile, assuming BD [New LWP 100802 of process 6198] GLib (gthread-posix.c): Unexpected error from C library during 'pthread_cond_timedwait': Operation not permitted. Aborting. Thread 35 received signal SIGABRT, Aborted. [Switching to LWP 100802 of process 6198] 0x00000008013b957a in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x00000008013b957a in thr_kill () from /lib/libc.so.7 #1 0x00000008013b7974 in raise () from /lib/libc.so.7 #2 0x000000080132afa9 in abort () from /lib/libc.so.7 #3 0x00000008011f05d0 in g_thread_abort (status=1, function=0x8010b8821 "pthread_cond_timedwait") at gthread-posix.c:78 #4 0x00000008011f0f13 in g_cond_wait_until (cond=0x804f93860, mutex=0x804f93870, end_time=1180297413) at gthread-posix.c:916 #5 0x0000000000222fe4 in prepare (trans=0x804f938b0, error=0x7fffdfffdf28) at xfburn-transcoder-gst.c:846 #6 0x00000000002207e1 in xfburn_transcoder_prepare (trans=0x804f938b0, error=0x7fffdfffdf28) at xfburn-transcoder.c:173 #7 0x000000000021ff15 in thread_burn_composition (params=0x80561b5b0) at xfburn-burn-audio-cd-composition-dialog.c:388 #8 0x00000008011c24bd in g_thread_proxy (data=0x8050b5cf0) at gthread.c:784 #9 0x0000000800b16775 in ?? () from /lib/libthr.so.3 #10 0x0000000000000000 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 (gdb) Analysis shows that FreeBSD's pthread_cond_timedwait is more restrictive than linux one. It strictly requires the current thread to hold a lock to the mutex passed to it. At present xfburn code performs the locking in the main thread when constructing the bst_transcoder object. This causes the crash in FreeBSD since the g_cond_wait_until function is called on a mutex not locked by that thread. I have created a patch (attached) which modifies the locking to actually call g_cond_wait_until with the lock held by the transcoding thread. I also posted it on facebook, on a fork of the xfburn code: https://github.com/madpilot78/xfburn/commit/6b557bba49fc075718788594c3488a01a32091f8 in my opinion present code locking practices are wrong, and do end up in "undefined behavior" working just on linux, but my patch does need review since I could have made mistakes myself. Hope it can be included in the official sources. If some further step is required for me to have it included (like a pull request), please tell me so. Thanks!
Thank you for your bug report and the patch. I can't test it right now because I don't have any burner, and no FreeBSD setup. Does FreeBSD changed the behavior of its pthread implementation ? This part of code in xfburn hasn't changed in years so it's surprising it start to fail now. If people can try this patch and confirm that everything still works, that would be awesome :)
(In reply to Skunnyk from comment #1) > Thank you for your bug report and the patch. > I can't test it right now because I don't have any burner, and no FreeBSD > setup. The bug was reported to me by users. I could not notice it since I've not been burning audio CDs for a long time. When I did burn audio CDs in the past I was doing it from the command line. > Does FreeBSD changed the behavior of its pthread implementation ? This part > of code in xfburn hasn't changed in years so it's surprising it start to > fail now. Looking at the FreeBSD repositories I can't find significant changes to the threading library done very recently. There was activity in 2016 which maybe is relevant. I'm unable to tell exactly by looking at the diffs though. (I can point you to them if required). It is quite possible the issue was unreported for some time. > If people can try this patch and confirm that everything still works, that > would be awesome :) I have tested it in FreeBSD and the user reporting it in the thread I linked did test it successfully on his system. The patch I provided is also included by default in the FreeBSD port, so binaries being distributed to users include it. If it actually breaks I should get it reported. I understand you need reports also from users on Linux systems before including it. Thanks for your quick reply!
Any news about this?
Guido Falsi referenced this bugreport in commit 81ca7f2a6badb6d559a1970ae481a4b0bcf88ab5 Bug #14857 : Fix crashing on FreeBSD https://git.xfce.org/apps/xfburn/commit?id=81ca7f2a6badb6d559a1970ae481a4b0bcf88ab5
Commited, Thank you !