SETRANS + libavg = SIGSEGV on Hardy

The issue also happens outside of libavg, as this discussion shows:

http://ubuntuforums.org/showthread.php?t=762228

The crash occurs when the libselinux1 library is trying to do its 'fini' destructor functions when unloading.
It references some thread local storage variables that were statically initialized to NULL.
That first reference fails when it actually tries to allocate the variables.
This patch explicity initializes those variables during the init function, making the fini function work.
It seems that the real defect is in a corner case of the implementation of "__thread" feature.
But changing libselinux1 this way is a practical workaround.

I confirm that this issue has nothing to do with libavg, I'm experiencing it with gst-inspect too.
The sigsegv happens in fini_contex_translations function (setrans_client.c) because it free a couple of uninitialized contexts.
Mike's patch doesn't seem to solve the issue here (current intrepid) though, it makes it crash on init function.. Removing __thread keywords from contexts initialization seems to do the trick but I doubt it's the right fix.
Is there an upstream tracker to report the issue?

See also http://mail.gnome.org/archives/gnome-shell-list/2008-November/msg00001.html

I was playing with opencv capture via jni (processing.org), i was able to acquire the v4l source, but after a couple of minutes(detecting faces) java crashed ... :(

examining the given crash logs stacktrace, i was suspicious about libselinux and applied the above "WORKAROUND" -- thanks by the way , since it fixed those occasional crashes, at least i didn't experienced them anymore ... :)

i run ibex with libselinux1 version 2.0.65-2

for the interested i attach javas crashlog... (no libavg involved i think?)

Hi all,
I ran into the same problem. After applying the patch posted by Mike Stroyan it seem to work, but after recompiling the whole thing without debug flags I got a new SIGSEGV:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb4cfdb90 (LWP 6839)]
0xb1080b18 in init_context_translations () at setrans_client.c:222
222 prev_r2t_trans = NULL;
Current language: auto; currently c
(gdb) bt
#0 0xb1080b18 in init_context_translations () at setrans_client.c:222
#1 0xb1079ccc in init_lib () at init.c:119
#2 0xb108234d in __do_global_ctors_aux () from /lib/libselinux.so.1
#3 0xb1071b5c in _init () from /lib/libselinux.so.1
#4 0xb802bae4 in call_init () from /lib/ld-linux.so.2
#5 0xb802bc14 in _dl_init_internal () from /lib/ld-linux.so.2
#6 0xb802fb3b in dl_open_worker () from /lib/ld-linux.so.2
#7 0xb802b716 in _dl_catch_error () from /lib/ld-linux.so.2
#8 0xb802f2ee in _dl_open () from /lib/ld-linux.so.2
#9 0xb7b57bec in dlopen_doit () from /lib/tls/i686/cmov/libdl.so.2
#10 0xb802b716 in _dl_catch_error () from /lib/ld-linux.so.2
#11 0xb7b5801c in _dlerror_run () from /lib/tls/i686/cmov/libdl.so.2
#12 0xb7b57b21 in dlopen@@GLIBC_2.1 () from /lib/tls/i686/cmov/libdl.so.2

I really can't see how this can happen...

Still having the same problem here, used the attached patch to work around it. (Inspired by http://patch-tracking.debian.net/patch/misc/view/libselinux/1.32-3/src/setrans_client.c).
Not sure if this is a valid solution.

To elaborate on my previous post:
There seems to be some problem with TLS (Thread-local storage, __thread keyword). This workaround just replaces TLS with a locking mechanism, but this doesn't fix the original problem - no idea where that problem originates.

(libselinux_2.0.65-2 on Intrepid, gcc 4.3.2 [4.3.2-1ubuntu11])

kees, could you look at the patch: https://bugs.edge.launchpad.net/ubuntu/+source/libselinux/+bug/237156/comments/2

TRF, bug 357965 is maybe a dupe of this and the patch helped there.

I'm waiting to get some input from Tresys on this issue, but so far, the patch seems sane to me.

Just for the record, the clutter module (package python-clutter, pyclutter) seems to trigger this as well.

Please apply this fix from upstream. The patch has been altered to apply to this version of libselinux.

Which releases of Ubuntu does this apply to, and are there any easy reproducers? The diff in comment 13 seems to be against jaunty, rather than hardy -- does it still work as expected on Hardy?

Looks like this has been fixed for a while

Feel free to reopen if it's not the case