[erlang-questions] Problem Loading Shared (.so) Library Within Linked-in Driver

[Mikael Pettersson]

Peter McCarthy writes:
 > Dear all
 > 
 > I've developed a linked-in driver which I load and unload using the
 > functions erl_ddll:load_driver / open_port and port_close /
 > erl_ddll:unload_driver respectively.
 > 
 > In the driver's start function (called when a port is opened), I load
 > a shared (.so) library using dlopen. Then, in the driver's command
 > function, I call various functions in that shared library. Finally, in
 > the driver's stop function (called when a port is closed), I use
 > dlclose to unload the shared library.
 > 
 > Now, everything works okay in general. However, I've noticed the
 > following problem. If I repeatedly load and unload the linked-in
 > driver within the same emulator instance, the dlopen function will
 > eventually fail (always on the 29th call) with the following error:
 > 
 >     "cannot allocate memory in static TLS block"
 > 
 > When this happen, a restart of the emulator is required. Does anyone
 > know what's happening here?

That message comes from glibc (so you're probably on Linux right?)
when it runs out of slots in the static thread-local-storage array.

This means that something leaks TLS slots. Could be Erlang, could be
glibc, or it could be your driver.

Unfortunately I know nothing about Erlang's driver interface or
erl_ddll, so I can't offer any insights on that.

I'd run it with gprof (and linked with gprof-enabled glibc) and
look for whoever calls glibc's TLS allocation routines.