Default value changed following discussion on valdev.
Giving more information for errors with freed blocks can help
when investigating difficult problems (e.g. double free, programs
using 'cleanup list' collecting different types of memory, ...)
Regression tested on various setup (x86, ppc64, s390x, amd64, debian or fedora)
Tests that have only one exp files have been updated to use the output
of the new default value in their .exp file.
Tests having more than one exp file have been changed so as to
specify explicitely the previous clo default value (i.e. adding
--keep-stacktraces=alloc-then-free in the vgtest file).
Possibly, some tests might fail on non tested platforms
(e.g. mips, macos, solaris, tilegx).
Fixes should be straightforward, using one of the above fix techniques.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15597
envB: var=value
in the .vgtest file. This is similar to "env:" except the environment
variable is set prior to invoking progB.
Adapt gdbserver_tests/nlgone_exit.vgtest to fix a problem reported
by Matthias Schwarzott <zzam@gentoo.org>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15592
GDB is correct that we don't support that at the moment.
See bug #351792 - vgdb doesn't support remote file transfers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15591
Initial data segment is established (see initimg-solaris.c for rationale):
- directly during client program image initialization,
- or on demand when the executed program is the runtime linker itself,
after it has loaded its target dynamic executable (see PRE(sys_mmapobj)),
or when the first brk() syscall is made.
More preparatory work for ldsoexec support.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15583
../../coregrind/m_oset.c:413:39: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15582
Objective is to avoid a 'possibly lost' leak when self-hosting
(and re-uses the already existing align logic in m_mallocfree.c)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15581
is made. It cannot be established during client image initialization because
that would conflict with a temporary stack which ld.so.1 (when executed directly)
uses for loading the target dynamic executable.
See PRE(sys_brk) in syswrap-solaris.c.
Preparatory work for ldsoexec support.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15572
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
This is just a testsuite cleanup. In the case defcfaexpr was compiled
with line number information (which might happen in some distro builds)
just throw it away because the expected output just wants to see the
function names.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15566
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
