Messages in this thread | | | Date | Wed, 26 Nov 2003 20:42:56 +0000 | From | Jamie Lokier <> | Subject | Re: BUG (non-kernel), can hurt developers. |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |