SETRANS + libavg = SIGSEGV on Hardy

Bug #237156 reported by OXullo Intersecans on 2008-06-03
This bug affects 5 people
Affects Status Importance Assigned to Milestone
libselinux (Debian)
Fix Released
libselinux (Ubuntu)
Nominated for Intrepid by Jacques Frechet

Bug Description

I'm experiencing a problem that seems to involve libselinux1 while using python-libavg package, a boost.Python based C++ library.

Simplest testcase:

1. install python-libavg w/ deps
2. from python cli:
>>> import libavg
>>> CTRL-D

distro: Ubuntu hardy heron / 8.04
arch: both i386 (Intel core duo) and amd64 (AMD Athlon64 X2)

  Installed: 2.0.55-0ubuntu4
  Candidate: 2.0.55-0ubuntu4
  Version table:
     2.0.55-0ubuntu4 0
        500 hardy/main Packages
 *** 2.0.55-0ubuntu4 0
        100 /var/lib/dpkg/status

  Installed: 0.7.0-4ubuntu1
  Candidate: 0.7.0-4ubuntu1
  Version table:
 *** 0.7.0-4ubuntu1 0
        500 hardy/universe Packages
        100 /var/lib/dpkg/status

Valgrind reports:

=29183== Invalid read of size 8
==29183== at 0xE29B9DD: fini_context_translations (setrans_client.c:211)
==29183== by 0xE28F1F1: (within /lib/
==29183== by 0xE29D040: (within /lib/
==29183== by 0x570010F: exit (exit.c:75)
==29183== by 0x56E91CA: (below main) (libc-start.c:252)
==29183== Address 0x80 is not stack'd, malloc'd or (recently) free'd
==29183== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==29183== Access not within mapped region at address 0x80
==29183== at 0xE29B9DD: fini_context_translations (setrans_client.c:211)
==29183== by 0xE28F1F1: (within /lib/
==29183== by 0xE29D040: (within /lib/ by 0x570010F: exit (exit.c:75)
==29183== by 0x56E91CA: (below main) (libc-start.c:252)

GDB says:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f3af10916e0 (LWP 15047)]
0x00007f3ae812a9dd in fini_context_translations () at setrans_client.c:211
211 free(prev_r2t_trans);
(gdb) bt
#0 0x00007f3ae812a9dd in fini_context_translations () at setrans_client.c:211
#1 0x00007f3ae811e1f2 in __do_global_dtors_aux () from /lib/
#2 0x00007ffff9097700 in ?? ()
#3 0x00007f3ae812c041 in _fini () from /lib/
#4 0x00007ffff9097700 in ?? ()
#5 0x00007f3af0e88796 in _dl_fini () from /lib64/
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

**** Workaround: disable SETRANS

$ apt-get source libselinux1
$ cd libselinux-2.0.55
$ DISABLE_SETRANS=y dpkg-buildpackage -rfakeroot -uc -b
$ cd ..
$ sudo dpkg -i libselinux1_2.0.55-0ubuntu4_amd64.deb (or i386 one)

Is this workaround going to break some enforcing policy aspects?

description: updated
Ulrich von Zadow (uzadow) wrote :

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

Mike Stroyan (stroyan) wrote :

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.

Filippo Argiolas (fargiolas) wrote :

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?

hatori (noltemedia) wrote :

I was playing with opencv capture via jni (, 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?)

Christof Rath (christof-rath) wrote :

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/
#3 0xb1071b5c in _init () from /lib/
#4 0xb802bae4 in call_init () from /lib/
#5 0xb802bc14 in _dl_init_internal () from /lib/
#6 0xb802fb3b in dl_open_worker () from /lib/
#7 0xb802b716 in _dl_catch_error () from /lib/
#8 0xb802f2ee in _dl_open () from /lib/
#9 0xb7b57bec in dlopen_doit () from /lib/tls/i686/cmov/
#10 0xb802b716 in _dl_catch_error () from /lib/
#11 0xb7b5801c in _dlerror_run () from /lib/tls/i686/cmov/
#12 0xb7b57b21 in dlopen@@GLIBC_2.1 () from /lib/tls/i686/cmov/

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

Tobias Kellner (cybot) wrote :

Still having the same problem here, used the attached patch to work around it. (Inspired by
Not sure if this is a valid solution.

Changed in libselinux:
status: New → Confirmed
Tobias Kellner (cybot) wrote :

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])

Changed in libselinux (Debian):
status: Unknown → New
Alexander Sack (asac) wrote :

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

Kees Cook (kees) wrote :

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

Changed in libselinux (Debian):
status: New → Confirmed
Martin Soto (soto255) wrote :

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

Changed in libselinux (Ubuntu):
importance: Undecided → Medium
Caleb Case (calebcase) wrote :

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

Kees Cook (kees) wrote :

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?

Kees Cook (kees) on 2009-09-08
Changed in libselinux (Ubuntu):
status: Confirmed → Incomplete
David Futcher (bobbo) on 2010-06-11
tags: added: patch-accepted-debian
Changed in libselinux (Debian):
status: Confirmed → Fix Released
Laurent Bigonville (bigon) wrote :

Looks like this has been fixed for a while

Feel free to reopen if it's not the case

Changed in libselinux (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.