GNOME Bugzilla – Bug 101571
use of asm/atomic.h on i386 SMP machines can result in random segfaults
Last modified: 2004-12-22 21:47:04 UTC
The use of #include <asm/atomic.h> in gst/gstatomic.h is problematic. It can lead to the atomic code being compiled without the use of the "lock" instruction. This is a critical error on SMP machines. Random crashes can happen without "lock". This has been observed for me as a crash when a subbuffer is alive but it's parent has been unrefed and freed. Accessing this subbuffers data then causes a segfault at some random later time. Can be very confusing as the first cause would appear to be unmatched ref/unref. When compiling on a Debian machine with recent libc6-dev the following path is taken: #include <gst/gstatomic.h> -> #include <asm/atomic.h> -> #include <linux/config.h> -> #include <linux/autoconf.h> -> #undef CONFIG_SMP This #undef causes asm/atomic.h to NOT use the "lock" instruction. One approach to solve this is to always use "lock" in the appropriate atomic operations. This will make compiled code portable to SMP machines and work as expected on UP as well. I'm not sure what, if any, performance cost this has on UP machines. It appears to be difficult to ensure that "lock" is always used when including <asm/atomic.h>. Copying Linux include/asm-*/atomic.h files to the core may be a problem if we wish to keep the GStreamer core LGPL. Another option is to use libatomic which is in the codecs.org CVS repository. Yet another option is to add code to (by default?) disable the HAVE_ATOMIC_H check and asm/atomic.h usage. Code would then fallback on to the GMutex atomic operations. This would probably cause performance hit on some archs. Marked as critical due to segfaults at random locations on SMP machines. This is probably not an issue at all on UP machines.
I should note this is a problem on i386 SMP. Does anyone know if this is also a problem on other SMP architectures?
<wtay> Uraeus: you can close that one, we don't use kernel headers anymore