After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 101571 - use of asm/atomic.h on i386 SMP machines can result in random segfaults
use of asm/atomic.h on i386 SMP machines can result in random segfaults
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.5.0
Other Linux
: Normal critical
: 0.4.0
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-12-19 02:15 UTC by David I. Lehn
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David I. Lehn 2002-12-19 02:15:22 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.
Comment 1 David I. Lehn 2002-12-19 02:38:26 UTC
I should note this is a problem on i386 SMP.  Does anyone know if this
is also a problem on other SMP architectures?
Comment 2 Christian Fredrik Kalager Schaller 2003-01-12 21:00:55 UTC
<wtay> Uraeus: you can close that one, we don't use kernel headers anymore