LKML Archive on
help / color / mirror / Atom feed
From: Jamie Lokier <>
To: "Richard B. Johnson" <>
Cc: Linus Torvalds <>,
	Linux kernel <>
Subject: Re: BUG (non-kernel), can hurt developers.
Date: Wed, 26 Nov 2003 19:33:10 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <Pine.LNX.4.53.0311261344280.11326@chaos>

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?

> 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"

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

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

Your code interrupts one call to rand() and calls rand() _within_
the interrupt handler.  The inner call and outer call interfere, in a
very similar way to calling it twice from two threads (note: threads
not tasks).  The memory state becomes corrupted.

This is _very_ different from two independent tasks context switching.
Independent tasks do not share the same memory space, not even when
they share the same libraries, so this type of corruption isn't

Summary: your monthly "bad interaction" is not illustrated in this
test program.  It's a different problem.

-- Jamie

  reply	other threads:[~2003-11-26 19:33 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 [this message]
2003-11-26 20:17       ` Richard B. Johnson
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:

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

  git send-email \ \ \ \ \ \
    --subject='Re: BUG (non-kernel), can hurt developers.' \

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