LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
	Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: BUG (non-kernel), can hurt developers.
Date: Wed, 26 Nov 2003 20:42:56 +0000	[thread overview]
Message-ID: <20031126204256.GJ14383@mail.shareable.org> (raw)
In-Reply-To: <Pine.LNX.4.53.0311261459340.11574@chaos>

Richard B. Johnson wrote:
> > What is the "bad interaction" that you observed at monthly intervals?
> > Also a SIGSEGV?
> 
> Yes. When the call to rand() was replaced with a static-linked
> clone it went away.

> The calling rand() from a handler in a newer libc doesn't seg-fault.

On both cases, although it doesn't seg-fault, you can no longer trust
the results to be the same quality of random numbers.

It's an implementation detail that the other versions of rand() happen
not to segfault even though you are calling them incorrectly.  Just
like you can call free() twice on a memory block and it will segfault
with Glibc, but is fine in some versions of BSD.  It's still an error
to do it.

> Not with the emulation. The problem is that rand() uses a thread-
> specific pointer to find the seed (history variable), just like
> 'errno' which isn't really a static variable, but a function
> that returns a pointer to a thread-specific integer. If this
> is interrupted in a critical section, and that same pointer
> is used, that pointer is left pointing to a variable in somebody
> else's address space.

Yes that sounds reasonable.  A newer libc would fix it because newer
libc uses a different method for looking up thread-specific pointers.

> That same problem is observed to happen when the same shared runtime
> library was used by entirely different tasks.

When you say "entirely different tasks", do you mean "different
threads in the same process" or "different processes"?

That same problem _can_ happen between different threads in a single
process, but it _cannot_ happen between different processes.

-- Jamie


  reply	other threads:[~2003-11-26 20:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-26 16:54 Richard B. Johnson
2003-11-26 17:21 ` YOSHIFUJI Hideaki / 吉藤英明
2003-11-26 18:29 ` Linus Torvalds
2003-11-26 18:55   ` Richard B. Johnson
2003-11-26 19:33     ` Jamie Lokier
2003-11-26 20:17       ` Richard B. Johnson
2003-11-26 20:42         ` Jamie Lokier [this message]
2003-11-26 18:59   ` YOSHIFUJI Hideaki / 吉藤英明
2003-11-27 20:41   ` Mikulas Patocka
2003-11-28  7:18   ` Tomas Szepe
2003-11-28 10:29 Andries.Brouwer
2003-11-28 17:22 ` Chris Friesen
2003-11-28 21:21 Andries.Brouwer
2003-11-28 21:38 ` Chris Friesen

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=20031126204256.GJ14383@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    --cc=torvalds@osdl.org \
    --subject='Re: BUG (non-kernel), can hurt developers.' \
    /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

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).