[Gstreamer-bugs] [Bug 101571] New - use of asm/atomic.h on SMP machines can result in random segfaults

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=101571

Changed by dlehn at vt.edu.

--- shadow/101571	Wed Dec 18 21:15:23 2002
+++ shadow/101571.tmp.31871	Wed Dec 18 21:15:23 2002
@@ -0,0 +1,54 @@
+Bug#: 101571
+Product: GStreamer
+Version: 0.5.0
+OS: Linux
+OS Details: Debian unstable, i386, SMP
+Status: NEW   
+Resolution: 
+Severity: critical
+Priority: Normal
+Component: gstreamer (core)
+AssignedTo: gstreamer-maint at bugzilla.gnome.org                            
+ReportedBy: dlehn at vt.edu               
+QAContact: gstreamer-maint at bugzilla.gnome.org
+TargetMilestone: 0.4.0
+URL: 
+Summary: use of asm/atomic.h on SMP machines can result in random segfaults
+
+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.