Re: [uclibc-ng-devel] __LDSO_STANDALONE_SUPPORT__ applies to dlopen

And just out of curiosity, are you sure that you are following all requirements described there: https://github.com/openssl/openssl/blob/df1f538f28c10f2954757164b17781040d2… ? 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: > > https://github.com/openssl/openssl/issues/654 > > https://github.com/curl/curl/issues/1055 > > 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 > https://github.com/openssl/openssl/issues/653 > > 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 only >>>> 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, it >>>> 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. >>> >>> Rich >> -- 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 > devel(a)uclibc-ng.org > https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel