Hi, as one can see, there is not much xfburn code active when the SIGSEGV happens. I guess it is thread 1 which suffers it.
Now while there is still the possibility that xfburn started the problem by subtle corruption of memory management, it is strange that this does not happen on arch "amd64". xfburn source code itself makes no differences between processor types. In may 2014 i had a semi-private (german) conversation with an Ubuntu "i386" user who experienced SIGSEGV in the GTK libraries when starting a burn run. We involved the memory checker program valgrind and the developer of xfburn. Regrettably the case could not be solved because valgrind did not find any wrongdoing in xfburn code, and because the entrails of GTK are too complicated for me, valgrind, and the developer of xfburn. Valgrind detected the memory problems earlier than the SIGSEGV happened, but it could not show us the initial trigger in GTK. (I'm glad that my own sports only deals with burner drives and ISO 9660 filesystem entrails. It's so relaxing if you depend only on command line, core operating system, and own code.) If you feel apt to do in a shell session (aka terminal window): sudo apt-get install valgrind valgrind $(which xfburn) 2>&1 | tee -i /tmp/valgrind_messages and then replay the user input which leads to the crash, then please post the resulting file /tmp/valgrind_messages. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org