exposed by scheduling changes caused by commit vg_scheduler.c rev 1.70.
We cannot simply pass the __attr pointer to the child, since it could
point to stuff on the parent's stack, which might not exist by the time
the child looked at it. Prior to scheduler.c rev 1.70 the child would
have been scheduled as soon as created, so the access was made before the
parent could clear the stuff from its stack. From rev 1.70 and after
the parent continues after creating the child, causing invalid stack
accesses when the child finally runs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@455
signal, cause the nanoslep to return with EINTR. Then, in the user-space
nonblocking select() implementation, notice this and correspondingly return
with EINTR. This appears to fix the MySQL hang-at-exit problem.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@391
the size is bigger then the hardcoded value in valgrind. This
makes it easier to find out which value to use for
VG_PTHREAD_STACK_SIZE.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@378
- Thread stack size = 1 Meg
- Alias for __pthread_kill_other_threads_np
Now at least valgrind doesn't crash/assert. Still doesn't work tho.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@373
- just before __NR_exec()
- just after __NR_fork() when I am the child
This makes OpenOffice 1.0 not have mutex-related assertion failures
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@333
Major overhaul to the way thread startup and exit is done. Removes some
ugly gunk in the scheduler, and adds support for thread detaching and
cancellation.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@326
$ nm /lib/libc-2.2.4.so | grep vfork
000b4220 T __vfork
000b4220 W vfork
There's no __libc_vfork, so there's nothing we can do here.
Just don't supply our own version.
Not at all sure if this is correct.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@303
throw away the old signals simulation and more or less start again
from scratch. vg_signals.c is nearly a complete rewrite. In fact
this is now the third generation of the signals simulation.
The purpose of this is to properly support signals in threads -- a
nightmare combination. pthread_sigmask, pthread_kill and sigwait
are now alledged to work as POSIX requires.
In the process, throw away confusing and conceptually muddled old
implementation and replace with something which is more verbose but
conceptually cleaner, simpler and easier to argue is correct.
* When the client does sigaction/sigprocmask et al, the resulting
changes are stored verbatim in SCSS -- the Static Client Signal State.
So SCSS is the state the client believes the kernel is in.
* Every time SCSS changes, we recalculate the state the kernel
*should* be in so that our signal simulation works. This is the
SKSS -- Static Kernel Signal State. The kernel state is then
updated accordingly. By diffing the new and old SKSSs, the
number of real system calls made is minimised.
* The dynamic state of the client's signals is stored in DCSS
-- Dynamic Client Signal State. This just records which signals
are pending for which threads.
The big advantage of this scheme over the previous is that the SCSS ->
SKSS mapping is made explicit and gathered all in one place, rather
than spread out in a confusing way and done implicitly. That makes it
all lot easier to decide if the mapping, which is really the heart of
the signals simulation, is correct or not.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@271
will start up valgrind if it is not already running. This more or less
sidesteps the problem that sometimes valgrind.so isn't init'd first by
the dynamic linker.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@257
