Fedora Account System
Red Hat Associate
Red Hat Customer
abrt 1.1.1 detected a crash. architecture: i686 Attached file: backtrace cmdline: par2 v -- /capture/shaolintemple.par2 component: par2cmdline crash_function: __TBB_rel_acq_fence executable: /usr/bin/par2 global_uuid: f18de417506a3374a7d940909a972894b55cd2f0 kernel: 2.6.33.5-112.fc13.i686 package: par2cmdline-0.4.tbb.20100203-1.fc13 rating: 4 reason: Process /usr/bin/par2 was killed by signal 4 (SIGILL) release: Fedora release 13 (Goddard) How to reproduce ----- 1. Invoked from PyPar2 2. Request to verify files 3. New terminal window opens for cmd line, then aborts
Created attachment 421425 [details] File: backtrace
There's quite a lot of frames in that backtrace which contain functions from tbb. Re-assiging to the tbb maintainer. Perhaps he has a clue about what goes wrong here.
I've been experiencing the same issue. The problem is due to this: Program terminated with signal 4, Illegal instruction. #0 __TBB_rel_acq_fence (this=<value optimized out>, parent=<value optimized out>, child=<value optimized out>) at ../../include/tbb/machine/linux_ia32.h:42 42 inline void __TBB_rel_acq_fence() { __asm__ __volatile__("mfence": : :"memory"); } Note the mfence instruction. I'm running this on a Pentium III which doesn't support this instruction hence SIGILL: #UD If CPUID.01H:EDX.SSE2[bit 26] = 0 (says Intel Arch. Soft. Dev.'s Manual) Not sure if it's a compiler bug or a tbb bug... I will look into the code to know more...
Hmm, seems like TBB assumes that all i686 machines have the mfence instruction: inline void __TBB_rel_acq_fence() { __asm__ __volatile__("mfence": : :"memory"); } I found this thread where this problem is discussed for windows: http://software.intel.com/en-us/forums/showthread.php?t=73293 I'll look into porting the last ("green") advice to GCC.
... or actually all ia32 machines, as the line that I quoted is from include/tbb/machine/linux_ia32.h.
Created attachment 422957 [details] Fix Replace mfence with xchg of a local variable, as described in the link that I posted. I'm afraid there might be more problems of the same kind. The project's FAQ says that "the project is dedicated to supporting [...] all processors," but I'm not sure whether that doesn't mean "all SSE2 processors".
tbb-2.2-2.20090809.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/tbb-2.2-2.20090809.fc13
In this instance of the bug the code is called via TBB function and it should be enough to update from testing. But if the code gets exposed somewhere in header files, it may be also necessary to rebuild par2cmdline. You'll have to try and see.
FYI I had opened a bug upstream too (http://www.threadingbuildingblocks.org/bug_desc.php?id=171) but the resolution was set to "LATER" and was directed to the same forum thread: http://software.intel.com/en-us/forums/showthread.php?t=73293. In the long run, I guess they should implement CPU feature discovery at runtime... FYI your new TBB build fixes the problem. I guess you can resolve this bug! Thanks much!
tbb-2.2-2.20090809.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update tbb'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/tbb-2.2-2.20090809.fc13
Updated from updates-testing - working fine now.
tbb-2.2-2.20090809.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.