This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug sanitizer/81493] New: python fails to load libtsan.so: cannot allocate memory in static TLS block
- From: "wangzhijun2005 at hotmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 20 Jul 2017 12:09:15 +0000
- Subject: [Bug sanitizer/81493] New: python fails to load libtsan.so: cannot allocate memory in static TLS block
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81493
Bug ID: 81493
Summary: python fails to load libtsan.so: cannot allocate
memory in static TLS block
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: wangzhijun2005 at hotmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
I compiled a dynamic library with Thread sanitizer, then loaded it with python,
but got an error "libtsan.so: cannot allocate memory in static TLS block". I
tried to load libtsan.so directly, the same issue occurred.
$ cat try.py
#!/usr/bin/env python
from ctypes import *
CDLL("/usr/lib/gcc/x86_64-linux-gnu/5/libtsan.so")
$ ./try.py
Traceback (most recent call last):
File "./try.py", line 3, in <module>
CDLL("/usr/lib/gcc/x86_64-linux-gnu/5/libtsan.so")
File "/usr/lib/python2.7/ctypes/__init__.py", line 362, in __init__
self._handle = _dlopen(self._name, mode)
OSError: /usr/lib/gcc/x86_64-linux-gnu/5/libtsan.so: cannot allocate memory in
static TLS block
$ ldd /usr/lib/gcc/x86_64-linux-gnu/5/libtsan.so
linux-vdso.so.1 => (0x00007ffdde9a3000)
libachk.so => /lib/libachk.so (0x00007f29c4963000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f29c4746000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f29c4542000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f29c4239000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f29c3e6f000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f29c3c59000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f29c3a51000)
/lib64/ld-linux-x86-64.so.2 (0x000056148e62f000)
Below is my test env.
$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
$ ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu3) 2.23
$ python --version
Python 2.7.12
$ uname -a
Linux SZX1000317010 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04 LTS (Xenial Xerus)"