I am now working on a fix for that issue. That will probably come with a testcase for dlopen, seems that whole code-path is not covered by any testcases.
Henning Am Mon, 12 Feb 2018 16:57:34 +0100 schrieb "[ext] Henning Schild" <[email protected]>: > Am Sat, 10 Feb 2018 11:33:00 +0100 > schrieb Philippe Gerum <[email protected]>: > > > On 02/09/2018 06:58 PM, Henning Schild wrote: > > > Am Fri, 9 Feb 2018 18:23:47 +0100 > > > schrieb "[ext] Henning Schild" <[email protected]>: > > > > > >> Am Fri, 9 Feb 2018 17:48:22 +0100 > > >> schrieb Jan Kiszka <[email protected]>: > > >> > > >>> On 2018-02-09 17:13, Henning Schild wrote: > > >>>> When using dlopen() to include xenomai libraries into an > > >>>> application, __xenomai_init could be running in multiple > > >>>> threads at a time. That happens if the application dlopens > > >>>> multiple libs in multiple threads. > > >>> > > >>> So, dlopen itself is thread-safe, but it does not guarantee > > >>> atomicity for the init functions it executes? Or would we run > > >>> xenomai_init_dso manually in that case? > > >> > > >> According to its man-page dlopen is MT-Safe, but i do not think > > >> that necessarily means it will serialize the init functions for > > >> us. I think i will have to read the code to answer this one. > > > > > > I just had a look at glibc, and it looks like dlopen contains a > > > big dlopen-lock as well. > > > > > > https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-open.c;h=0e37dd74b603ba07f677f2b4cf21661de5379529;hb=23158b08a0908f381459f273a984c6fd328363cb#l541 > > > > > > dl_open_worker will be called only under that lock and that is > > > where a function named _dl_init gets called. uclibc also uses a > > > big lock around all dlopen activity. > > > > > > It all looks like my patch is not required. > > > > > > > The MT-safety issue may be with the setup calls, which run on behalf > > of library constructors. Multiple threads calling > > __register_setup_call() concurrently may be a problem, which may > > happen when multiple DSOs are loaded concurrently (assuming their is > > nothing serializing the dl work). > > > > #define core_setup_call(__name) __setup_call(__name, > > 0) #define boilerplate_setup_call(__name) > > __setup_call(__name, 1) #define > > copperplate_setup_call(__name) __setup_call(__name, 2) > > #define interface_setup_call(__name) __setup_call(__name, 3) > > #define post_setup_call(__name) __setup_call(__name, > > 4) #define user_setup_call(__name) > > __setup_call(__name, 5) > > Found the problem, the setup_list was inconsistent because the > application did a dlclose() on one of the xenomai-libs. And there are > no destructors and no unregister_setup_call ... > > Now i am wondering whether the setup_call list would be the only thing > to consider when adding dtors. Or whether we could just have a dtor > that returns -EBUSY to prevent dlclose(). > > Henning > > _______________________________________________ > Xenomai mailing list > [email protected] > https://xenomai.org/mailman/listinfo/xenomai _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
