ctypes.cdll.LoadLibrary() freezes when loading a .so that contains dlopen()

[Ian Kelly]

On Fri, Feb 13, 2015 at 8:39 AM, Russell <russell at infiniteio.com> wrote:
> I have a shared library, libfoo.so, that references another .so which isn't linked but instead loaded at runtime with myso=dlopen("/usr/local/lib/libbar.so", RTLD_NOW); when I try to load it with ctypes, the call hangs and I have to ctl-c.
>
> (build)[dev]$ export LD_LIBRARY_PATH=/usr/local/bin
> (build)[dev]$ python
> Python 2.7.6 (default, Mar 22 2014, 22:59:56)
> [GCC 4.8.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import ctypes
>>>> ctypes.cdll.LoadLibrary ('/usr/local/lib/libfoo.so')   <--- This call hangs and have to ctl-C
> ^CTraceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/usr/lib/python2.7/ctypes/__init__.py", line 443, in LoadLibrary
>    return self._dlltype(name)
>   File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
>     self._handle = _dlopen(self._name, mode)
> KeyboardInterrupt
>>>>
>
>
> My first thought was that It couldn't find libbar.so, but if I remove that file, python seg faults: /usr/local/lib/libbar.so: cannot open shared object file: No such file or directorySegmentation fault (core dumped), so it appears that it finds the dlopen() file but freezes waiting for ???
>
> This is on ubuntu 14.4 server. C code is compiled with -std=gnu11 -Wall -Werror -m64 -march=x86-64 -mavx -g -fPIC

This seems to work for me (Mint 17).


$ cat a.c
#include <dlfcn.h>
#include <stdio.h>

void _init() {
  printf("a.so._init\n");
  dlopen("./b.so", RTLD_NOW);
}
$ cat b.c
#include <stdio.h>

void _init() {
  printf("b.so._init\n");
}
$ gcc -std=gnu11 -Wall -Werror -m64 -march=x86-64 -mavx -g -fPIC
-shared -nostartfiles -o a.so a.c
$ gcc -std=gnu11 -Wall -Werror -m64 -march=x86-64 -mavx -g -fPIC
-shared -nostartfiles -o b.so b.c
$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.cdll.LoadLibrary('./a.so')
a.so._init
b.so._init
<CDLL './a.so', handle 2860060 at 7f795ad936d0>


Can you boil down the issue that you're seeing into a minimal
reproducible example?