This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Calling other functions while concurrently calling exit?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>, Torvald Riegel <triegel at redhat dot com>, Rich Felker <dalias at aerifal dot cx>
- Date: Fri, 18 Sep 2015 23:06:35 -0400
- Subject: Calling other functions while concurrently calling exit?
- Authentication-results: sourceware.org; auth=none
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;
807
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.
Thoughts?
Cheers,
Carlos.