Some recent changes, starting from r15426, have modified the test and
its expected output. The exp files have been only partially updated for
MIPS. We complete that with this change.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15752
r15620 changed the test and the expected output for tc18_semabuse,
r15630 fixed the expected output file for other architectures but not
for mips.
Now we update it for mips as well.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15751
The addition if the safe wrapper in r15620 introduced an extra
output frame in the backtrace of helgrind/tests/tc18_semabuse and
helgrind/tests/tc20_verifywrap.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15630
This fixes the tc18 and tc20 testcases.
On some bad semaphores glibc now might just abort, we catch the SIGABRT
and turn it into a EINVAL. The program will see this, but the helgrind
wrapper won't. Which works for tc18 since there is an alternate exp file
with that result (silent bad sem_post). We add a similar alternative exp
file for tc21.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15620
In case we do recognize the xend, but detect it is invalid
(used outside a transaction) we generate a segsegv instead
of a sigill. Handle that in the same way in the test case.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15570
It is obsolete and not specified by POSIX. See man sigaction on Linux.
No regressions reported.
The following error may be seen on platforms that don't implement this extension:
depbase=`echo tc12_rwl_trivial.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../coregrind -I../../include -I../../VEX/pub -I../../VEX/pub -DVGA_amd64=1 -DVGO_darwin=1 -DVGP_amd64_darwin=1 -DVGPV_amd64_darwin_vanilla=1 -DVGA_SEC_x86=1 -DVGP_SEC_amd64_darwin=1 -Winline -Wall -Wshadow -Wno-long-long -g -fno-stack-protector -Wno-format-extra-args -Wno-literal-range -Wno-tautological-constant-out-of-range-compare -Wno-self-assign -Wno-string-plus-int -Wno-uninitialized -Wno-unused-value -arch x86_64 -MT tc12_rwl_trivial.o -MD -MP -MF $depbase.Tpo -c -o tc12_rwl_trivial.o tc12_rwl_trivial.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from tc12_rwl_trivial.c:8:
./safe-pthread.h:37:7: error: no member named 'sa_restorer' in 'struct sigaction'
sa.sa_restorer = NULL;
~~ ^
1 error generated.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15569
when a pthread_rwlock is used in an invalid way.
Recent glibcs use transactional memory instructions to do lock ellision
but will sometimes, when locks are used in an invalid way, may calls to
xend on systems which don't support it, on the grounds that the program
is invalid anyway.
So we try and catch and ignore the resulting SIGILL in our tests that
deliberately work with invalid locks.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15565
tc09_bad_unlock fails randomly for the following reason:
Thread 1 is creating a lock in a stack variable and locks it.
It then clones a Thread 2 that will unlock this lock.
The test fails if the Thread 2 unlocks the lock while the
main thread is still just after the clone syscall:
There is no unwind info in this area, and so doing a stacktrace
implies a nasty hack (see hg_main.c evh__pre_thread_ll_create).
There is no such hack when describing the address of the lock
(as there is no logic in the 'normal' stack trace to detect we are
in the clone syscall code).
In such a case, the unwind fail, and the lock address description
lacks the frame nr derived from the captured stack trace.
Adding --fair-sched=yes seems to make a more reproducible test.
Note that the proper solution to all these 'racy helgrind regtests'
would be to add some synchronisations operations between threads
that helgrind does not observe (e.g. using a technique similar to
the pipe big lock) and have correct (but invisible to helgrind) synchronisation
between the threads actions needed for a reproducible regtest.
Not very cheap to develop, --fair-sched=try is cheap and easy
so use that till someone courageous implements non visible synchronisation
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15497
Add a .exp for the pth_cond_destroy_busy for PPC64 big endian.
This is specifically to cover the last line of output as
seen on ppc64BE, which is "ERROR SUMMARY: X errors from 3 contexts",
where X is 6, versus 3 as seen on other architectures.
The additional errors show up on BE during the "Thread #1: pthread_cond
_destroy: destruction of condition variable being waited upon."
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
This patch fixes Vagrind bugzilla 347686
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15239
by implementing a Garbage Collection for the SecMap.
The basic change is that freed memory is marked as noaccess
(while before, it kept the previous marking, on the basis that
non buggy applications are not accessing freed memory in any case).
Keeping the previous marking avoids the CPU/memory changes needed
to mark noaccess.
However, marking freed memory noaccess and GC the secmap reduces
the memory on big apps.
For example, a firefox test needs 220Mb less (on about 2.06 Gb).
Similar reduction for libreoffice batch (260 MB less on 1.09 Gb).
On such applications, the performance with the patch is similar to the trunk.
There is a performance decrease for applications that are doing
a lot of malloc/free repetitively: e.g. on some perf tests, an increase
in cpu of up to 15% has been observed.
Several performance optimisations can be done afterwards to not loose
too much performance. The decrease of memory is expected to produce
in any case significant benefit in memory constrained environments
(e.g. android phones).
So, after discussion with Julian, it was decided to commit as-is
and (re-)gain (part of) performance in follow-up commits.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15207
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
of the dynamically allocated Lock addresses.
This restores helgrind/tests/locked_vs_unlocked2.stderr.exp
from r14931.
While regtesting the patch I've observed intermittent failures
of helgrind/tests/hg05_race2 like so:
--- ../../helgrind/tests/hg05_race2.stderr.exp (revision 15001)
+++ ../../helgrind/tests/hg05_race2.stderr.exp (working copy)
@@ -26,8 +26,7 @@
at 0x........: th (hg05_race2.c:17)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
- Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
- declared at hg05_race2.c:24, in frame #x of thread x
+ Address 0x........ is on thread #x's stack
----------------------------------------------------------------
@@ -42,8 +41,7 @@
at 0x........: th (hg05_race2.c:17)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
- Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
- declared at hg05_race2.c:24, in frame #x of thread x
+ Address 0x........ is on thread #x's stack
Surely, that's something else.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15009
This fixes a helgrind crash detected on android.
Android bionic pthread lib unmaps the stack for detached threads
before exiting.
Helgrind tries to unwind the stack to record a 'read' after
the stack unmap, just before the exit syscall.
The unwind then causes a SEGV.
The solution consists in tightening the calculation of
the stack limits, so as to stop unwinding when no valid stack
can be found.
Regression test reproduces the same problem by simulating the
bionic behaviour on linux, using asm similar to bionic lib.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14976
Some arches (s390x and ppc64) return ENOSYS instead of EINVAL for
undefined futex operations. Adjust the helgrind filter_stderr to
handle that case.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14375
Activating this hint using --sim-hints=no-nptl-pthread-stackcache
means the glibc nptl stack cache will be disabled.
Disabling this stack/tls cache avoids helgrind false positive race conditions
errors when using __thread variables.
Note: disabling the stack cache is done by a kludge, dependent on
internal knowledge of glibc code, and using libpthread debug info.
So, this kludge might be broken with newer glibc version.
This has been tested on various platforms and various
glibc versions 2.11, 2.16 and 2.18
To check if the disabling works, you can do:
valgrind --tool=helgrind --sim-hints=no-nptl-pthread-stackcache -d -v ./helgrind/tests/tls_threads |& grep kludge
If you see the below 2 lines, then hopefully the stack cache has been disabled.
--12624-- deactivate nptl pthread stackcache via kludge: found symbol stack_cache_actsize at addr 0x3AF178
--12624:1:sched pthread stack cache size disabling done via kludge
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14313
to add PPC64 LE support. The other two patches can be found in Bugzillas
334384 and 334834. Note, there are no VEX changes in this patch.
PP64 Little Endian test case fixes.
This patch adds new LE and BE expect files where needed. In other
cases, the test was fixed to run correctly on LE and BE using based on
testing to see which platform is being used.
Where practical, the test cases have been changed so that the output
produced for BE and LE will be identical. The test cases that require
a major rewrite to make the output identical for BE and LE simply
had an additional expect file added.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14240
to add PPC64 LE support. The other two patches can be found in Bugzillas
334834 and 334836. The commit does not have a VEX commit associated with it.
POWER PC, add initial Little Endian support
The IBM POWER processor now supports both Big Endian and Little Endian.
This patch renames the #defines with the name ppc64 to ppc64be for the BE
specific code. This patch adds the Little Endian #define ppc64le to the
Additionally, a few functions are renamed to remove BE from the name if the
function is used by BE and LE. Functions that are BE specific have BE put
in the name.
The goals of this patch is to make sure #defines, function names and
variables consistently use PPC64/ppc64 if it refers to BE and LE,
PPC64BE/ppc64be if it is specific to BE, PPC64LE/ppc64le if it is LE
specific. The patch does not break the code for PPC64 Big Endian.
The test files memcheck/tests/atomic_incs.c, tests/power_insn_available.c
and tests/power_insn_available.c are also updated to the new #define
definition for PPC64 BE.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14238
* Add lock announcements in various helgrind errors that were not
announcing the locks
* ensure locks are also announced in xml (note that this is compatible
with xml protocol version 4, so no impact on GUI which properly
implement the protocol)
Changes done:
* Like other HG record_error functions, HG_(record_error_LockOrder) is
now passing Lock* rather than lock guest addresses.
* update exp files for tests that were showing locks without announcing them
* change tc14_laog_dinphils.c and tc15_laog_lockdel.c so as to
have same sizes on 32 and 64 bits systems for allocated or symbol sizes.
* factorise all code that was announcing first lock observation
* enable xml lock announcement
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14204
(note that some error messages are not announcing the lock,
which is not that nice).
At least the lock order violation message do not announce locks.
That should be improved/fixed
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14188
and stack address description.
* A race condition on an allocated block shows the stacktrace, but
does not show the thread # that allocated the block.
This patch adds the output of the thread # that allocated the block.
* The patch also fixes the confusion that might appear between
the core threadid and the helgrind thread nr in Stack address description:
A printed stack addrinfo was containing a thread id, while all other helgrind
messages are using (supposed to use) an 'helgrind thread #' which
is used in the thread announcement.
Basically, the idea is to let a tool set a "tool specific thread nr'
in an addrinfo.
The pretty printing of the addrinfo is then by preference showing this
thread nr (if it was set, i.e. different of 0).
Currently, only helgrind uses this addrinfo tnr.
Note: in xml mode, the output is matching the protocol description.
I.e., GUI should not be impacted by this change, if they properly implement
the xml protocol.
* Also, make the output produced by m_addrinfo consistent:
The message 'block was alloc'd at' is changed to be like all other
output : one character indent, and starting with an uppercase
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14175
showing where a thread was created.
This makes many tests fail => use sed to delete pthread_create_WRK
from the stacktrace to let tests succeed on ppc64.
With this change, on ppc64 gcc110 (fedora 18), helgrind failures
goes from 28 tests failing to 4, with following reasons:
helgrind/tests/pth_cond_destroy_busy (stderr)
(6 errors instead of 3 in the summary line ???)
helgrind/tests/tc06_two_races_xml (stderr)
similar change needed in filter_xml to del pthread_create_WRK
helgrind/tests/tc18_semabuse (stderr)
- with error code 22 (EINVAL: Invalid argument)
+ with error code 38 (ENOSYS: Function not implemented)
helgrind/tests/tc20_verifywrap (stderr)
- with error code 22 (EINVAL: Invalid argument)
+ with error code 38 (ENOSYS: Function not implemented)
More details about the stacktrace not containing pthread_create_WRK:
--------------------------------------------------------------------
Here is the stacktrace obtained by GDB+vgdb:
(gdb) bt
#0 0x0000008074f7ac5c in .__clone () from /lib64/libc.so.6
#1 0x000000807517b1ec in do_clone (pd=0x4c6f200, attr=0x8075189c90 <default_attr>, stackaddr=<optimized out>, stopped=<optimized out>,
fct=@0x80751a01e0: 0x807517c500 <start_thread>, clone_flags=4001536) at ../nptl/sysdeps/pthread/createthread.c:74
#2 0x000000000403ed0c in pthread_create_WRK (thread=<error reading variable: value has been optimized out>,
attr=<error reading variable: value has been optimized out>, start=<error reading variable: value has been optimized out>,
arg=0xfff00ee18) at hg_intercepts.c:269
#3 0x000000000403ef1c in _vgw00000ZZ_libpthreadZdsoZd0_pthreadZucreateZAZa (thread=<optimized out>, attr=<optimized out>,
start=<optimized out>, arg=<optimized out>) at hg_intercepts.c:300
#4 0x000000003806f1d8 in ?? ()
#5 0x0000008074e9fb94 in generic_start_main (main=@0x100200d8: 0x100013a0 <main>, argc=<optimized out>, ubp_av=0xfff00f2d8,
auxvec=0xfff00f408, init=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>, fini=<optimized out>)
at ../csu/libc-start.c:225
#6 0x0000008074e9fd90 in __libc_start_main (argc=<optimized out>, ubp_av=<optimized out>, ubp_ev=<optimized out>,
auxvec=<optimized out>, rtld_fini=<optimized out>, stinfo=<optimized out>, stack_on_entry=<optimized out>)
at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:91
#7 0x0000000000000000 in ?? ()
(gdb)
and here is the stacktrace produced by Valgrind unwinder:
Thread 1: status = VgTs_Runnable
==41687== at 0x8074F7AC5C: clone (in /usr/lib64/libc-2.16.so)
==41687== by 0x807517B1EB: do_clone.constprop.3 (createthread.c:74)
==41687== by 0x403EF1B: pthread_create@* (hg_intercepts.c:300)
==41687== by 0x10001597: main (tc19_shadowmem.c:172)
valgrind stack top usage: 15328 of 1048576
When the 2nd clone break is encountered (in the child thread), here is
the GDB stacktraces:
Thread 2 (Thread 6028):
#0 0x0000008074f75fb0 in .madvise () from /lib64/libc.so.6
#1 0x000000807517c700 in start_thread (arg=0x4c6f200) at pthread_create.c:402
#2 0x0000008074f7acf0 in .__clone () from /lib64/libc.so.6
Thread 1 (Thread 41687):
#0 pthread_create_WRK (thread=0xfff00ee10, attr=0x0, start=@0x100200e8: 0x10001dd0 <steer>, arg=0xfff00ee18) at hg_intercepts.c:248
#1 0x000000000403ef1c in _vgw00000ZZ_libpthreadZdsoZd0_pthreadZucreateZAZa (thread=<optimized out>, attr=<optimized out>,
start=<optimized out>, arg=<optimized out>) at hg_intercepts.c:300
#2 0x000000003806f1d8 in ?? ()
#3 0x0000008074e9fb94 in generic_start_main (main=@0x100200d8: 0x100013a0 <main>, argc=<optimized out>, ubp_av=0xfff00f2d8,
auxvec=0xfff00f408, init=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>, fini=<optimized out>)
at ../csu/libc-start.c:225
#4 0x0000008074e9fd90 in __libc_start_main (argc=<optimized out>, ubp_av=<optimized out>, ubp_ev=<optimized out>,
auxvec=<optimized out>, rtld_fini=<optimized out>, stinfo=<optimized out>, stack_on_entry=<optimized out>)
at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:91
#5 0x0000000000000000 in ?? ()
(gdb)
Here are the valgrind stacktraces:
Thread 1: status = VgTs_Runnable
==41687== at 0x403EBE0: pthread_create_WRK (hg_intercepts.c:248)
==41687== by 0x403EF1B: pthread_create@* (hg_intercepts.c:300)
==41687== by 0x8074E9FB93: generic_start_main.isra.0 (libc-start.c:225)
==41687== by 0x8074E9FD8F: (below main) (libc-start.c:91)
valgrind stack top usage: 15328 of 1048576
Thread 2: status = VgTs_WaitSys
==41687== at 0x8074F75FB0: madvise (in /usr/lib64/libc-2.16.so)
==41687== by 0x807517C6FF: start_thread (pthread_create.c:402)
valgrind stack top usage: 10320 of 1048576
And then after a few more next/breaks:
Thread 1: status = VgTs_Runnable
==41687== at 0x8074F7AC5C: clone (in /usr/lib64/libc-2.16.so)
==41687== by 0x807517B1EB: do_clone.constprop.3 (createthread.c:74)
==41687== by 0x403EF1B: pthread_create@* (hg_intercepts.c:300)
==41687== by 0x100015BB: main (tc19_shadowmem.c:173)
valgrind stack top usage: 15328 of 1048576
Thread 2: status = VgTs_WaitSys
==41687== at 0x8074F75FB0: madvise (in /usr/lib64/libc-2.16.so)
==41687== by 0x807517C6FF: start_thread (pthread_create.c:402)
valgrind stack top usage: 10320 of 1048576
So, pthread_create_WRK is not in the stacktrace anymore.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13983
of memcheck and helgrind in a common module:
pub_tool_addrinfo.h pub_core_addrinfo.h m_addrinfo.c
At the same time, the factorised code is made usable by other
tools also (and is used by the gdbserver command 'v.info location'
which replaces the helgrind 'describe addr' introduced 1 week ago
and which is now callable by all tools).
The new address description code can describe more addresses
(e.g. for memcheck, if the block is not on the free list anymore,
but is in an arena free list, this will also be described).
Similarly, helgrind address description can now describe more addresses
when --read-var-info=no is given (e.g. global symbols are
described, or addresses on the stack are described as
being on the stack, freed blocks in the arena free list are
described, ...).
See e.g. the change in helgrind/tests/annotate_rwlock.stderr.exp
or locked_vs_unlocked2.stderr.exp
The patch touches many files, but is basically a lot of improvements
in helgrind output files.
The code changes are mostly refactorisation of existing code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13965
On MIPS architecture helgrind is showing race condition error in printf if
the printf is first time called from the child thread. If we call printf
from the main for the first time we will suppress this error on mips.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13749
(When calling pthread_cond_destroy or pthread_mutex_destroy
with initializers as argument Helgrind (incorrectly)
reports errors.)
This introduces a new race report (but no new race) in
some conditions. I think this is OK because the race only
occurs in the case where the program is buggy (racey) anyway.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13643
Fix some compiler warnings when compiling Valgrind for mips32/mips64.
Clean up exp files for mips32 BE and LE.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13496
Add mips64-le implementation of:
- atomic_add_8bit
- atomic_add_16bit
- atomic_add_32bit
- atomic_add_64bit
- do_acasW
Minor fixes for mips32 implementations are included as well.
These functions are needed to execute atomic_incs and annotate_hbefore
tests on mips64le.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13357
(problem reported in bug 307082, comment 8).
Solution applied is similar to what is in 307082 patch
(i.e. do not destroy the internal helgrind var if nWaiters > 0).
But also do not remove it from the FM.
+ add a test case (re-using the drd test case)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13329
In case a lock order violation is detected in a multi lock cycle,
then the current code cannot produce the set of locks and the
stack traces involved in the cycle.
However, it is still possible to produce the stack trace of
the new lock and the other lock between which a cycle was discovered.
Also, add a comment in the code clarifying why the set of locks
establishing the required order cannot (currently) be produced.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13281
