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
Option -v outputs a list of used suppressions. This only gives
the nr of times a suppression was used.
For a leak search, this only gives the nr of loss records that
have been suppressed, but it does not give additional needed details
to understand more precisely what has been suppressed
(i.e. nr of blocks and nr of bytes).
=> Add in the tool interface update_extra_suppression_use and
print_extra_suppression_info functions to allow the tool to record
additioonal use statistics for a suppression. These statistics
can be done depending on the error (and its data) which is suppressed.
Use this in memcheck for the leak suppressions, to maintain and output
the nr of blocks and bytes suppressed by a suppression during
the last leak search.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13651
clang 3.3 produces an error message for /usr/include/c++/4.6/chrono
which happens to get included somewhere inside <thread>.
This happens with C++ headers from:
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13620
Non-POD variable length arrays are supported by g++ but not by clang.
Hence convert the variable length array in this test program into a vector.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13606
(1) Detect availability of pthread_setname_np. Ignore testcases
memcheck/tests/threadname[_xml] if not available.
(2) Enable _GNU_SOURCE to avold compiler warnings.
(3) In threadname_xml filter out stackframes referring to system
libraries. Added tests/filter_xml_frames to do that.
(4) Adjust .exp files as needed
(5) Do not ship stdout.exp for memcheck/tests/threadname[_xml].
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13557
If a suppression file contains an error, the lineno reported could be wrong.
Also, give filename and lineno of the used suppressions in -v debugging output.
The fix consists in ensuring that tool specific read_extra function gets
the Int* lineno pointer, together with other VG_(get_line) parameters.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13469
exp-32bit files needed minor update for the last store, and some mips32
platforms also need additional exp-mips32 due to different way of loading
and storing double values.
This fixes drd/tests/annotate_trace_memory on different 32-bit platforms.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13414
Workaround for bug #318643. Disable the tests for now so they don't
go into an infinite loop and fill up the disks on arm, ppc32 or ppc64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13402
