This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Calling other functions while concurrently calling exit?

Is it spelled out anywhere in POSIX or ISO C that calling
other functions concurrently with exit is going to result
in undefined behaviour?

It's obvious this is dangerous. There is global state being
shtudown and freed while threads are trying to use that
global state. However, I can't find anything that explicitly
forbids this.

Is it simply that one must read "Consequences of Process
Termination" and imply that problems might be caused by this?

It isn't entirely obvious that you can't have a thread call
dlclose while main calls exit. It will cause problems
because _dl_fini handles the link map l_init_called entries
without dl_load_lock held and so you might get both the
thread and main trying to run the finalizers. The call to
dlclose usually results in this interesting undocumented
assertion triggering:

803 void
804 _dl_close (void *_map)
805 {
806   struct link_map *map = _map;
808   /* First see whether we can remove the object at all.  */
809   if (__glibc_unlikely (map->l_flags_1 & DF_1_NODELETE))
810     {
811       assert (map->l_init_called);
812       /* Nope.  Do nothing.  */
813       return;
814     }

Here the exit function _dl_fini already set l_init_called to
zero because it's using that to mark finalizers as having
been run. A great and confusing use of this variable if I ever
saw one.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]