After looking more in depth, gdbserver must not be terminated
in PRE(posix_spawn) on MacOS: this is running in the parent and
(on MacOS) is a single syscall similar to a fork+exec.
On linux, posix_spawn is implemented using 2 syscalls
(fork followed by exec).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12882
This should fix the bug (but could not test it : no MacOSX).
See equivalent code in syswrap-generic.c and comment
in pub_tool_gdbserver.h:
// tid == 0 indicates to stop gdbserver and report to gdb
// that the valgrind-ified process has exited.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12879
Darwin from returning address zero (however insane that is). r12466
appears to cause other applications to break (TextEdit, for one).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12813
to any other platforms. Prevent mmap(ANON) from returning zero (zero
with success, that is) since (a) some programs are observed to be
spooked by getting zero from a successful call to mmap, and (b) it's
pretty stupid from the point of view of program safety and possibly
security, since it causes page zero to become accessible. So don't.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12466
If the pre_thread_ll_create tracking function would be invoked without the
big lock being held, that would trigger a race condition in the tools that
implement this tracking function.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12458
(Rusty Russell, rusty@rustcorp.com.au)
tdb uses fcntl locks and mmap, and some of the tests fail under valgrind.
strace showed valgrind opening the tdb file, reading 1024 bytes, then closing
it. This is not allowed: POSIX says if you open and close a file, all fcntl
locks on it are dropped (insane, yes).
Finally got around to hacking the source to track this down: di_notify_mmap is
doing the damage. The simplest fix was to hand in an optional fd for it to
use, then have it do pread.
I had to fix your pread; surely this should seek back even if the platform
doesn't have pread support?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12224
* configure.in support
* new supp file darwin11.supp
* comment out many intercepts in mc_replace_strmem.c and
vg_replace_malloc.c that are apparently unnecessary for Darwin
* add minimal handling for the following new syscalls and mach traps:
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
* wqthread_hijack on amd64-darwin: deal with
tst->os_state.pthread having an apparently different offset,
which caused an assertion failure
* m_debuginfo: for 32 bit processes on Lion, use the DebugInfoFSM
cleanup added in r12041/12042 to handle apparently new dyld
behaviour, which is to map text areas r-- first and only
vm_protect them later to r-x.
The following cleanups remain to be done
* remove apparently pointless, commented out wrapper macro
invokations in mc_replace_strmem.c, eg
//MEMMOVE(VG_Z_DYLD, memmove)
(or determine that they are still necessary, and uncomment)
* ditto in vg_replace_malloc.c, plus general VGO_darwin cleanups
there
* write proper syscall wrappers for
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
These are currently just no-ops and may be causing Memcheck to
report false undef-value errors
* figure out why it doesn't work properly unless built with gcc-4.2 on
Lion.
gcc-4.2 is the "normal" gcc (i686-apple-darwin11-gcc-4.2.1). Plain
gcc is the hybrid gcc-front-end clang-back-end thing
(i686-apple-darwin11-llvm-gcc-4.2). Whereas on Snow Leopard, plain
gcc is the normal gcc.
The symptoms of the failure are that wqthread_hijack in
syswrap-amd64-linux.c hits this /*NOTREACHED*/ vg_assert(0); right
at the end (you need a pretty complex threaded app to trigger this),
which makes me think that either ML_(wqthread_continue_NORETURN) or
call_on_new_stack_0_1 do return, which they are not expected to.
* figure out if some of the uninitialised value errors reported in
system libraries on are caused by Memcheck being confused by LLVM
generated code, as per bug #242137
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12043
VALGRIND_{DISABLE,ENABLE}_ERROR_REPORTING, which allow a thread to
temporarily disable reporting of errors it makes. This is useful for
making Memcheck behave sanely in the presence of some MPI
implementations. Also mark up libmpiwrap.c accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11910
ensure proper cleanup of gdbsrv FIFOs/shmem files with untraced fork/exec
* syswrap-{generic|darwin|aix5}.c : in PRE(sys_execve) : terminate gdbserver
* pub_core_gdbserver.h and m_gdbserver.c : add VG_(gdbserver_prerun_action),
factorising the actions to do by gdbserver at "startup" (i.e. a traced
fork or a traced exec).
* scheduler.c : implement startup action using VG_(gdbserver_prerun_action)
(Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11771
dmaclach@gmail.com). Fixes#244670. I'm assuming this also compiles
on 10.5 but haven't tried it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11222
svn merge -r11143:HEAD svn://svn.valgrind.org/valgrind/branches/MACOSX106
There were some easy-to-resolve conflicts.
Then I had to fix up coregrind/link_tool_exe*.in -- those files had been
added independently on both the trunk and the branch, AFAICT. I just
overwrote the trunk versions with the branch versions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11194
Specifies a comma-separated list of executable-names
(with "*" and "?" wildcards allowed) that should not be traced into
even when --trace-children=yes. Modified version of a patch
from Bill Hoffman. Fixes#148932.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10927
for not testing properly. Added a regtest for it too. Fixes bug 200760
(again, properly this time).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10826
syscalls I've had the displeasure of encountering. Due to its
ridiculousness, the wrapper misses a PRE_MEM_WRITE check and so can result
in false positives. The POST_MEM_WRITE update is present, though, so it
shouldn't cause subsequent problems. Fixes bug 200760.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10786
as written once aio_return() is successfully called.
Also check the addressability of the buffer for both aio_read() and
aio_write().
Also check the file descriptor for aio_read() and aio_write().
And add a test for this. There's one corner case of the test that doesn't
work as expected and is currently commented out. But aio_*() certainly
works better than it used to.
All this is for bug 197227.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10539
following improvements:
- Arch/OS/platform-specific files are now included/excluded via the
preprocessor, rather than via the build system. This is more consistent
(we use the pre-processor for small arch/OS/platform-specific chunks
within files) and makes the build system much simpler, as the sources for
all programs are the same on all platforms.
- Vast amounts of cut+paste Makefile.am code has been factored out. If a
new platform is implemented, you need to add 11 extra Makefile.am lines.
Previously it was over 100 lines.
- Vex has been autotoolised. Dependency checking now works in Vex (no more
incomplete builds). Parallel builds now also work. --with-vex no longer
works; it's little use and a pain to support. VEX/Makefile is still in
the Vex repository and gets overwritten at configure-time; it should
probably be renamed Makefile-gcc to avoid possible problems, such as
accidentally committing a generated Makefile. There's a bunch of hacky
copying to deal with the fact that autotools don't handle same-named files
in different directories. Julian plans to rename the files to avoid this
problem.
- Various small Makefile.am things have been made more standard automake
style, eg. the use of pkginclude/pkglib prefixes instead of rolling our
own.
- The existing five top-level Makefile.am include files have been
consolidated into three.
- Most Makefile.am files now are structured more clearly, with comment
headers separating sections, declarations relating to the same things next
to each other, better spacing and layout, etc.
- Removed the unused exp-ptrcheck/tests/x86 directory.
- Renamed some XML files.
- Factored out some duplicated dSYM handling code.
- Split auxprogs/ into auxprogs/ and mpi/, which allowed the resulting
Makefile.am files to be much more standard.
- Cleaned up m_coredump by merging a bunch of files that had been
overzealously separated.
The net result is 630 fewer lines of Makefile.am code, or 897 if you exclude
the added Makefile.vex.am, or 997 once the hacky file copying for Vex is
removed. And the build system is much simpler.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10364
