Post AV31is4OSLhsijuwZE by a1ba@suya.place
 (DIR) More posts by a1ba@suya.place
 (DIR) Post #AV1ILEO78WOTtSXEuW by krh@fosstodon.org
       2023-04-25T19:11:20Z
       
       1 likes, 0 repeats
       
       Does creating a thread in a dlopened shared object take a reference on the shared object that prevents destructors from running the the module is dlclosed? I'm going to have to read the source, aren't I...
       
 (DIR) Post #AV1OJxA0InOLtli1XE by pid_eins@mastodon.social
       2023-04-25T19:14:12Z
       
       0 likes, 0 repeats
       
       @krh it does not.
       
 (DIR) Post #AV1OJxtjYlyIBb6XoW by krh@fosstodon.org
       2023-04-25T19:17:03Z
       
       0 likes, 0 repeats
       
       @pid_eins So why don't the static C++ destructors run at `dlclose` time when I start a thread in the module and do when I dont?
       
 (DIR) Post #AV1OJyeAm77OVcpdCK by a1ba@suya.place
       2023-04-25T20:25:06.706227Z
       
       0 likes, 0 repeats
       
       @krh @pid_eins you better not rely on dlclose. It's not guaranteed to success or even do anything at all, musl for example doesn't even implement it and in some cases glibc linker may silently do nothing (there was a bug when dlclose() caused memory leaks when GCC generated STB_GNU_UNIQUE kind of symbols).I believe threads somehow increment internal reference counter and dlclose() does nothing in your case. You may test it by printing something in __attribute__((constructor)) and destructor function, if it ever gets called.
       
 (DIR) Post #AV1OR2U2uPGmR3SjDs by a1ba@suya.place
       2023-04-25T20:26:24.461748Z
       
       0 likes, 0 repeats
       
       @krh @pid_eins if this is true, you probably could do dlclose() at the end of thread routine, as a temporary hack before eliminating all dlclose() calls.
       
 (DIR) Post #AV2yuA2lfeDnmvqhAu by krh@fosstodon.org
       2023-04-26T07:11:00Z
       
       1 likes, 0 repeats
       
       @a1ba @pid_eins I'm relying on the shared object destructors running before loader unmaps the memory the .so was loaded into. If that's unreliable, that seems like a bug in the implementation. But of course, never unloading and running dtors at exit seems valid.
       
 (DIR) Post #AV31is4OSLhsijuwZE by a1ba@suya.place
       2023-04-26T15:21:19.880594Z
       
       0 likes, 0 repeats
       
       @krh @pid_eins you may try to file a bug to glibc.but dlclose was never reliable, in any implementation.