Re: glibc and dopen'ing modules with static TLS problem, question

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Tue, Nov 19, 2013 at 10:51 PM, Andrey Erschov
<andrey.erschov@gmail.com> wrote:
> Hello!
>
> On Fedora 19 (64-bit) I'm getting error "cannot load any more object
> with static TLS" while running proprietary accounting program, which
> tries to load libMagickWand.so, which, in it's order, depends on
> libgomp.so compiled with static TLS.
>
> On Ubuntu 13.04 (64-bit) same program works ok.
>
> Running program with LD_PRELOAD=libgomp.so.1 helps, but this is not so
> accurate solution, as I think.
>
> Looking into sources of glibc, i've found code responsible for this message:
> elf/dl-open.c:541:
>   if (! RTLD_SINGLE_THREAD_P && imap->l_tls_modid > DTV_SURPLUS)
>     _dl_signal_error (0, "dlopen", NULL, N_("\
> cannot load any more object with static TLS"));
>
> So I have a question: shouldn't the right part of && operator be like this:
> imap->l_tls_modid >= GL(dl_tls_max_dtv_idx) + DTV_SURPLUS
>
> If no, could you help me with next steps to adress the problem?

No, the code is correct.

You have 3 options:

Rebuild glibc with more default static TLS storage.
e.g. Increase DTV_SURPLUS until it works.

Rebuild your dependent libraries so that they don't use initial-exec
TLS model. It's a good optimization but it makes those DSOs unloadable
when you run out of surplus slots to load them into (and no you can't
expand the number of slots because of the way initial-exec optimizes
the TLS accesses).

Rebuild your application so it doesn't dlopen those libraries and instead
links against them (which makes the static linker size the required number
of slots correctly).

Hopefully that answers your question.

Cheers,
Carlos.