r13876 was a workaround for false ordering introduced by platform-specific
(Solaris) code. The conclusion of an off-list discussion was that this has
to be solved in the drd tool itself and not by modifying test programs. Hence
this revert.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13980
generate two consecutive 32bit loads instead of one 64bit load. Because of that
in error log we have two conflict loads of size 4 instead of one conflict load
of size 8.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13883
When DRD is built with ENABLE_DRD_CONSISTENCY_CHECKS enabled it fails with an assert on platforms where VG_STACK_REDZONE_SZB is #define'd as 0 (for example on 32-bit x86). drd: drd_thread.h:299 (vgDrd_thread_set_stack_min): Assertion 'DRD_(g_threadinfo)[tid].stack_min < DRD_(g_threadinfo)[tid].stack_max || DRD_(g_threadinfo)[tid].stack_max == 0' failed. ==12392== at 0x380227CD: report_and_quit (m_libcassert.c:279) ==12392== by 0x38022979: vgPlain_assert_fail (m_libcassert.c:359) ==12392== by 0x38015B29: drd_post_thread_create (drd_thread.h:297) ==12392== by 0x380A5DDC: run_a_thread_NORETURN (syswrap-linux.c) This is because on drd_post_thread_create() call is made to: drd_start_using_mem_stack2(drd_created, stack_max, 0); and in drd_start_using_mem_stack2() calls is made to: DRD_(thread_set_stack_min)(tid, a - VG_STACK_REDZONE_SZB); For many platforms VG_STACK_REDZONE_SZB is #define'd as 0 so that stack_min == stack_max in DRD_(thread_set_stack_min)(). I think it is safe to change the assert from (stack_min < stack_max) to (stack_min <= stack_max).
From: Ivo Raisr <ivosh@ivosh.net>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13870
Apparently with glibc >= 2.18 the value returned by pthread_mutexattr_gettype()
is not the same as the value passed to pthread_mutexattr_settype(). Add a
workaround for this glibc bug.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13792
When all threads are blocked in a syscall, DRD_(thread_get_running_tid)()
returns (or can return?) a "valid" DrdThreadId (probably the last one
that was running ?).
However, in such a situation, VG_(get_running_tid)() returns 0 (as effectively
there is no thread running).
This discrepancy (drd_tid "valid" and "vg_tid" invalid) can (probably) only
happen with gdb monitor commands, as a thread can (normally) execute a
client request only when it is running.
However, vgdb can "force" the invocation of the gdb monitor client request,
even if no thread is running.
In such a case, the assert should not verify that drd_tid and vg_tid are
consistent.
To reproduce the problem:
./vg-in-place --tool=drd sleep 60
and in another window:
./coregrind/vgdb help
which then gives
...
drd: drd_clientreq.c:84 (handle_client_request): Assertion 'DRD_(VgThreadIdToDrdThreadId)(vg_tid) == drd_tid' failed.
==4208== at 0x3801DE1D: report_and_quit (m_libcassert.c:260)
==4208== by 0x3801E034: vgPlain_assert_fail (m_libcassert.c:340)
==4208== by 0x380026CC: handle_client_request (drd_clientreq.c:84)
==4208== by 0x3806EE8F: handle_gdb_monitor_command (server.c:490)
==4208== by 0x3806F07A: handle_query (server.c:580)
==4208== by 0x3806FDB2: server_main (server.c:915)
==4208== by 0x3806B01C: call_gdbserver (m_gdbserver.c:706)
==4208== by 0x3806B8F2: vgPlain_invoke_gdbserver (m_gdbserver.c:892)
...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13765
Move memcheck/mc_replace_strmem.c to shared/vg_replace_strmem.c and
add several intercepts for SSE-variants. Include that source file from
drd/drd_strmem_intercepts.c, helgrind/hg_intercepts.c and
memcheck/mc_replace_strmem.c.
Merge memcheck/tests/filter_memcpy into tests/filter_stderr_basic.
Update tests/check_headers_and_includes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13719
