LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: Jamie Lokier <jamie@shareable.org>
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 15:17:14 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.53.0311261459340.11574@chaos> (raw)
In-Reply-To: <20031126193310.GE14383@mail.shareable.org>

On Wed, 26 Nov 2003, Jamie Lokier wrote:

> Richard B. Johnson wrote:
> > The actual problem in the production machine involves two absolutely
> > independent tasks that end up using the same shared 'C' runtime
> > library. There should be no interaction between them, none
> > whatsover. However, when they both execute rand(), they interact in
> > bad ways. This interraction occurs on random days at monthly
> > intervals.
>
> On Linux (unlike Windows), there is _no_ interaction between the
> libraries of different tasks.  Neither of them sees changes to the
> other's memory space.
>
> If you are seeing a fault, then there might well be a bug, even a
> kernel bug, but your test program does not illustrate the same problem.
>
> 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.

> > This is likely caused by the failure to use "-s" in the compilation
> > of a shared library function, fixed in subsequent releases.
>
> No, this has nothing to do with it.  Unlike Windows and some embedded
> environments, Linux shared libraries do not have "shared writable data"
> sections.

Well the libc rand() does something that looks like that.

>
> > So, I allowed rand() to be "interrupted" just as it would be in a
> > context-switch. I simply used a signal handler, knowing quite well
> > that the "interrupt" could occur at any time. [...] What I brought
> > to light was a SIGSEGV that can occur when the shared-library rand()
> > function is "interrupted".
>
> You have made a mistake.  You program shows a different problem to the
> one which you noticed every month or so.
>

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

> Calling a function from a signal handler while it is being interrupted
> by that handler is _very_ different from tasks context switching.
> They are not similar at all!  (Yes, signals can be used to simulate
> context switches, but not like this!)
>

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. That same problem is observed to happen when
the same shared runtime library was used by entirely different tasks.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.



  reply	other threads:[~2003-11-26 20:14 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 [this message]
2003-11-26 20:42         ` Jamie Lokier
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=Pine.LNX.4.53.0311261459340.11574@chaos \
    --to=root@chaos.analogic.com \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).