1. Make the output deterministic; different thread interleaving from expected
was causing failures for me.
2. Make it actually use the condition variable -- the condvar stupidly wasn't
actually being used in the expected case, because the other threads finished
all their work before pthread_cond_wait() even got called, and this prevented
the condition guarding pthread_cond_wait() from succeeding.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2952
neater. Also remove some dodgy CFLAGS+= lines.
I had to change the expected output of pth_once.c, because the change has
altered the order of the (non-deterministic) output.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2825
in a similar way to the previous patch that removed the limit on the
number of semaphores and fixes bug 86264.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2776
dist". This avoids the need to put it in "EXTRA_DIST", and saves a few lines
in all the docs Makefile.am files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2614
that it is called as soon as libpthread.so is loaded even if pthread_create
is never called.
This ensures that pthread_exit will work correctly, and I think will also
cure the famous memory leak in the pthread specifics for the main thread.
CCMAIL: 86730-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2584
directory from the source tree. This resolves bug 83040.
Based on patch from Ralf Wildenhues <Ralf.Wildenhues@gmx.de>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2450
handlers when a thread is cancelled which has the side effect that
programs linked with librt fail on Fedora Core 2 due to librt having
been built against the NPTL header instead of the old pthread headers.
This change extends valgrind's libpthread.so to handle both the old
and new style cleanup handlers in a similar way to NPTL and seems to
be sufficient to get programs linked with librt working again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2405
input so that the output is well known regardless of whether the test is
run from a terminal or from cron.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2276
Valgrind's dependency on the dynamic linker for getting started, and
instead takes things into its own hands.
This checkin doesn't add much in the way of new functionality, but it
is the basis for all future work on Valgrind. It allows us much more
flexibility in implementation, and well as increasing the reliability
of Valgrind by protecting it more from its clients.
This patch requires some changes to tools to update them to the changes
in the tool API, but they are straightforward. See the posting "Heads
up: Full Virtualization" on valgrind-developers for a more complete
description of this change and its effects on you.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2118
choosing the longest symbol, choose the longest ignoring any of the libc
junk prefixes like __libc_, __, __GI_*, etc. This makes the symbol
presented to the user in messages and used in *.supp files more consistent
and comprehensible.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2114
how autoconf/automake really work, but not me :-) What's the difference
between $(srcdir) and $(top_srcdir) (eg in coregrind/Makefile.am) ?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2104
clearer what's wrong if you try to catch signals 32 and 33; they're not bad
signals, just used internally. Updated one regtest accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2030
the places that normal users will see:
- command line: --tool=foo (although --skin=foo still works)
- docs: removed all traces (included renaming coregrind_skins.html to
coregrind_tools.html)
- in the usage messages
- in error messages
Also did in in some places that I judged were unlikely to cause clashes with
existing workspaces:
- in the header comments of many files (eg. "This file is part of Memcheck, a
Valgrind tool for...")
- in the regtests script
- in the .supp files
- in AUTHORS
- in README_MISSING_SYSCALL_OR_IOCTL
Also update the AUTHORS file to mention Jeremy.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2027
requests to allow client code to print messages through Valgrind's
logging mechanism. The new requests are:
VALGRIND_PRINTF - do a normal printf (prefixed with **PID**)
VALGRIND_PRINTF_BACKTRACE - do a printf with stack trace
VALGRIND_INTERNAL_PRINTF - printf, but for internal use (prefixed with ==PID==)
VALGRIND_INTERNAL_PRINTF_BACKTRACE - as above, with backtrace
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1974
with the aim of making it more robust, more correct and perhaps faster.
This patch removes the need to poll blocking syscalls, by adding a proxy
LWP for each application thread. This LWP is a kernel thread whose job
is to run all (potentially) blocking syscalls, and also to handle signals.
This allows the kernel to do more of the work of dealing with signals,
so on kernels which do this properly (2.6), Valgrind's behavious is a
lot more posix compliant. On base 2.4 kernels, we emulate some of the
missing 2.6 functionality.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1918
had forgotten that some errors (PThread errors) are found by the core, rather
than skins and so the skin shouldn't be involved in handling them. This commit
fixes the problem.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1770
