Just to summarize and "finish" this: It is definitely not an uclibc bug,
as I said I wrongly assumed that any executable can be dloaded. However
the described behavior by openssl should only apply if compiled as
dynamic lib, but not as a static one. A flag for this was added in
1.1.1b. However node.js did not use the flag yet, which I fixed with a
Am 03.06.19 um 17:40 schrieb Yann Sionneau:
And just out of curiosity, are you sure that you are
requirements described there:
Especially the "NOTES" part?
On 6/3/19 5:34 PM, Yann Sionneau wrote:
> For the record here are what I think are the corresponding threads:
> It seems those thread end up pointing that OpenSSL have invalid
> assumptions on atexit() in their code at least for Windows platform.
> (for the 2nd link)
> This also seems to be of interest
> In any case, I think it is hard to dig deeper in this topic without
> looking at the actual code and having more precise information about
> what is linked with what, and how (static? dynamic ?).
> And see some crash dumps (stack trace).
> On 6/3/19 5:16 PM, Luca Lindhorst wrote:
>> I meanwhile found the problem, it is already known, and they did
>> something about in the newest OpenSSL version. OpenSSL wants for be
>> sure, that their cleanup routines on atexit are executed. However if
>> it was loaded by dload and later closed by dlclose neccessary code
>> is not available anymore on exit. To achieve this they do a
>> (presumably second) dload on their library to keep it loaded. This
>> makes no sense if it is dynamically compile time linked, but does
>> not really harm. But when linked statically like in my case it does
>> something invalid, which doesn't really hurt either, but on uclibc
>> apparently leads to a printed error message.
>> This might actually be a thing to consider for uclibc, not printing
>> out an error, and only rely on the "normal" error handling
>> mechanisms, like in this case dload returning NULL.
>> Am 03.06.19 um 17:06 schrieb Rich Felker:
>>> On Mon, Jun 03, 2019 at 03:47:48PM +0200, Luca Lindhorst wrote:
>>>> Thanks for the help.
>>>> I guess there isn't a problem then. I didn't know that you can
>>>> load a "special" ET_DYN PIE elf, it makes sense though.
>>>> FYI: I am investigating a problem relating NodeJS on ARM. And after
>>>> some more investigating I found out that openssl tries to dlload
>>>> itself again, for a reason I don't fully understand yet
>>>> ("|Deliberately leak a reference to ourselves. This will force the
>>>> library to remain loaded until the atexit() handler is run at
>>>> process exit.|"). But since openssl is statically linked in node,
>>>> loads the binary again.
>>>> Therefore this certainly isn't a uclibc problem.
>>> I don't understand why it would dlopen the openssl binary rather than
>>> libssl for this purpose. It should not be doing that, and there's
>>> probably some other bug in openssl or in your integration of it that's
>>> making it do that. It also might be something you could consider a bug
>>> in uclibc -- attempting to dlopen the main program itself, rather than
>>> some other executable, should probably give a handle to the existing
>>> instance, rather than attempting to load it again.
>> -- Unsere Aussagen koennen Irrtuemer und Missverstaendnisse enthalten.
>> Bitte pruefen Sie die Aussagen fuer Ihren Fall, bevor Sie
>> Entscheidungen auf Grundlage dieser Aussagen treffen.
>> Wiesemann & Theis GmbH, Porschestr. 12, D-42279 Wuppertal
>> Geschaeftsfuehrer: Dipl.-Ing. Ruediger Theis
>> Registergericht: Amtsgericht Wuppertal, HRB 6377 Infos zum
>> Datenschutz: http://www.wut.de/datenschutz
>> Tel. +49-202/2680-0, Fax +49-202/2680-265, http://www.wut.de
> devel mailing list
-- Unsere Aussagen
koennen Irrtuemer und Missverstaendnisse enthalten.
Bitte pruefen Sie die Aussagen fuer Ihren Fall, bevor Sie Entscheidungen
auf Grundlage dieser Aussagen treffen.
Wiesemann & Theis GmbH, Porschestr. 12, D-42279 Wuppertal
Geschaeftsfuehrer: Dipl.-Ing. Ruediger Theis
Registergericht: Amtsgericht Wuppertal, HRB 6377
Infos zum Datenschutz:
Tel. +49-202/2680-0, Fax +49-202/2680-265,