mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: [PATCH] fix atexit when it is called from an atexit handler
Date: Thu, 23 Jul 2015 05:07:21 +0200	[thread overview]
Message-ID: <20150723030719.GB382@port70.net> (raw)
In-Reply-To: <20150723011816.GT1173@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

* Rich Felker <dalias@libc.org> [2015-07-22 21:18:16 -0400]:
> On Thu, Jul 23, 2015 at 01:44:06AM +0200, Szabolcs Nagy wrote:
> >  void __funcs_on_exit()
> >  {
> >  	int i;
> >  	void (*func)(void *), *arg;
> >  	LOCK(lock);
> > -	for (; head; head=head->next) for (i=COUNT-1; i>=0; i--) {
> > -		if (!head->f[i]) continue;
> > +	for (;;) {
> > +		i = next();
> > +		if (i<0) break;
> >  		func = head->f[i];
> >  		arg = head->a[i];
> >  		head->f[i] = 0;
> 
> I agree that this change should be made, but I don't like the
> particulars of the patch. It seems to increase exit handler runtime to
> O(n²) even in the case where no atexit is happening during exit, and
> it's not very elegant. I think a simpler solution would be to reset i
> to COUNT after calling f[i] if either (1) head has changed, or (2)
> i<COUNT-1 and f[i+1] is nonzero. Does this sound correct/better?

(2) should be 'f[i] is nonzero'.

i didnt think about detecting the change of head,
but it is simpler and better for the common case.

[-- Attachment #2: 0001-fix-atexit-when-it-is-called-from-an-atexit-handler.patch --]
[-- Type: text/x-diff, Size: 1452 bytes --]

From 63c2b2d58b2ec45df67927b8959ea8af6dd578ed Mon Sep 17 00:00:00 2001
From: Szabolcs Nagy <nsz@port70.net>
Date: Wed, 22 Jul 2015 23:05:57 +0000
Subject: [PATCH] fix atexit when it is called from an atexit handler

The old code accepted atexit handlers after exit, but did not run
them.  C11 seems to explicitly allow atexit to fail in this case,
but this situation can easily come up in C++ if a destructor has
local static object with a destructor so it should be handled.

Restart iterating the list of atexit handlers if new handlers are
added during a call.

Note that the memory usage can grow linearly with the overall
number of registered atexit handlers instead of with the worst
case list length. (This only matters if atexit handlers keep
registering atexit handlers which should not happen in practice).
---
 src/exit/atexit.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/exit/atexit.c b/src/exit/atexit.c
index be82718..75f7511 100644
--- a/src/exit/atexit.c
+++ b/src/exit/atexit.c
@@ -17,6 +17,7 @@ static volatile int lock[2];
 void __funcs_on_exit()
 {
 	int i;
+	struct fl *old;
 	void (*func)(void *), *arg;
 	LOCK(lock);
 	for (; head; head=head->next) for (i=COUNT-1; i>=0; i--) {
@@ -24,9 +25,12 @@ void __funcs_on_exit()
 		func = head->f[i];
 		arg = head->a[i];
 		head->f[i] = 0;
+		old = head;
 		UNLOCK(lock);
 		func(arg);
 		LOCK(lock);
+		if (head != old || head->f[i])
+			i = COUNT;
 	}
 }
 
-- 
2.4.1


  reply	other threads:[~2015-07-23  3:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-22 23:44 Szabolcs Nagy
2015-07-23  1:18 ` Rich Felker
2015-07-23  3:07   ` Szabolcs Nagy [this message]
2015-07-23  5:54     ` Jens Gustedt
2015-07-23  7:19       ` Jens Gustedt
2015-07-23 19:58         ` Rich Felker
2015-07-23 21:51           ` Jens Gustedt
2015-07-24  0:16             ` Szabolcs Nagy
2015-07-24  6:52               ` Jens Gustedt
2015-07-24 10:53                 ` Szabolcs Nagy
2015-07-24 16:01                 ` Rich Felker
2015-07-24 21:25     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150723030719.GB382@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).