mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: chris@scary.beasts.org
To: Steve Beaty <beaty@emess.mscd.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: sigaction, fork, malloc, and futex
Date: Tue, 4 May 2004 23:30:57 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.58.0405042315001.24297@sphinx.mythic-beasts.com> (raw)
In-Reply-To: <200405042015.i44KFb0R001900@emess.mscd.edu>

Hi-

On Tue, 4 May 2004, Steve Beaty wrote:

>
> 	anyone have a clue on this one?  we set up a signal handler, create
> 	a child that sends that signal, and have the signal handler fork
> 	another child.  if there is a malloc(), the second child gets stuck
> 	in a futex(); without the malloc(), no problem.  2.4.20-30.9
> 	kernel.  straces at the end.  any help would be appreciated.
> 	thanks!

Your signal handler function is illegally calling non-reentrant functions.
The *printf() family of functions are going to need to call malloc() to
allocate buffers. malloc() cannot be re-entered.

So specifically your deadlock sequence is:

Parent:
fork()
fprintf()
-> malloc()
   -> take a malloc() lock
(Child schedules and sends SIGALRM at this point)
SIGALRM:
fprintf()
-> malloc()
   -> try to take a malloc() lock
      -> deadlock, lock is already taken and will never be released!

Modern glibc / kernel combinations which use futexes in the malloc code
really seem to expose this race.

Cheers
Chris

  reply	other threads:[~2004-05-04 22:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-04 20:15 Steve Beaty
2004-05-04 22:30 ` chris [this message]
2004-05-04 22:56   ` Zan Lynx
2004-05-04 23:16     ` Andreas Schwab
2004-05-06 21:37     ` Steve Beaty
2004-05-06 22:22       ` Zan Lynx
2004-05-06 21:36   ` Steve Beaty
2004-05-04 23:37 ` Richard B. Johnson
2004-05-06 21:41   ` Steve Beaty
2004-05-05  0:38 ` Edgar Toernig
2004-05-06 21:47   ` Steve Beaty
     [not found] <1SeIE-Dy-17@gated-at.bofh.it>
     [not found] ` <1ShG9-2Yt-11@gated-at.bofh.it>
2004-05-04 23:57   ` Pascal Schmidt

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=Pine.LNX.4.58.0405042315001.24297@sphinx.mythic-beasts.com \
    --to=chris@scary.beasts.org \
    --cc=beaty@emess.mscd.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®