Re: BUG (non-kernel), can hurt developers.

[Jamie Lokier <jamie@shareable.org>]

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