Replace --wait-for-gdb=yes memory loop by a call to VG_(poll) (5000 milliseconds)
Depending on the cpu speed, this loop was way too fast or too slow.
=> replace by a syscall that will always give the same waiting time.
A few notes:
A VG_(poll) is available on all supported OS
B no signals are supposed to interrupt the syscall, as at that place, nothing works yet.
C gdb can attach to a process blocked in a syscall.
If ever B or C would not be true on some setups, then we could instead do a loop
of e.g. 50 * VG_(poll) (100 milli-seconds)
Mark Wielaard [Sat, 1 Oct 2016 11:54:50 +0000 (11:54 +0000)]
Fix crash in sys_modify_ldt wrapper on bad ptr. Bug #369383.
Make sure ptr is safe_to_deref if not NULL.
Also fixup some corner case error return codes.
We have to do that ourselves since we never actually call into the kernel.
Found by LTP testcases/kernel/syscalls/modify_ldt/modify_ldt01.
Mark Wielaard [Sat, 1 Oct 2016 11:54:49 +0000 (11:54 +0000)]
Fix crash in linux [rt_]sigaction wrapper with bad old/new sigaction handler.
Since we try to modify the old/new sigaction handler before passing it
to the kernel we must make sure that (if they aren't NULL) it is safe
to use. If not we should bail out early with EFAULT.
Bug #369362
Found by LTP testcases/kernel/syscalls/rt_sigaction/rt_sigaction02.
Mark Wielaard [Sat, 1 Oct 2016 11:54:47 +0000 (11:54 +0000)]
Fix crash when old/new sigprocmask isn't safe to dereference. Bug #369360.
Since we want to use the set and oldset for bookkeeping we also want
to make sure they are addressable otherwise, like the kernel, we EFAULT.
Also use EINVAL instead of EMFILE as failure when sigset size is wrong.
Found by LTP testcases/kernel/syscalls/rt_sigprocmask/rt_sigprocmask02.
Mark Wielaard [Sat, 1 Oct 2016 11:54:38 +0000 (11:54 +0000)]
Don't require the current working directory to exist. Bug #369209.
At startup valgrind fetches the current working directory and stashes
it away to be used later (in debug messages, read config files or create
log files). But if the current working directory didn't exist (or there
was some other error getting its path) then valgrind would go in an
endless loop. This was caused by assuming that any error meant a larger
buffer needed to be created to store the cwd path (ERANGE). However
there could be other reasons calling getcwd failed.
Fix this by only looping and resizing the buffer when the error is
ERANGE. Any other error just means we cannot fetch and store the current
working directory. Fix all callers to check get_startup_wd() returns
NULL. Only abort startup if a relative path needs to be used for
user supplied relative log files. Debug messages will just show
"<NO CWD>". And skip reading any config files from the startup_wd
if it doesn't exist.
Also add a new testcase that tests executing valgrind in a deep,
inaccessible and/or non-existing directory (none/tests/nocwd.vgtest).
Mark Wielaard [Sat, 1 Oct 2016 10:12:31 +0000 (10:12 +0000)]
Use AM_LDFLAGS instead of LDFLAGS in exp-bbv/tests Makefiles.
That makes it possible to add to LDFLAGS instead of overriding
when doing make. Useful if you want to have different LD_FLAGS
added for the main and check makes.
Add an optional 2nd arg to leak-autofreepool to test performance
e.g. using the beloz
for f in 1 2 3 4 5 6 7 8 9; do echo $f; time ./vg-in-place -q ./memcheck/tests/leak-autofreepool 2 $(expr $f \* 100000); done
This shows that freeing a mempool with significant nr of elements
has a bad effect on performance
Note that no effort has been spent to avoid leaks in this
optional perf test. This is just to analyse the time taken to
free the pool.
The above loop shows that a medium size pool (e.g. < 1000000 elts)
can already take significant time, probably due to the quadratic
algorithm to clear the pool.
Note that the increase can vary a lot, probably depending on the
way the blocks are spread in the hash table: when lucky, the quadratic
algorithm probably somewhat becomes more linear if the elements
are 'properly' ordered in the hash table by deletion order.
Ivo Raisr [Sat, 24 Sep 2016 21:15:44 +0000 (21:15 +0000)]
Added meta mempool support into memcheck for describing a custom allocator which:
- Auto-frees all chunks assuming that destroying a pool destroys all
objects in the pool
- Uses itself to allocate other memory blocks
Unit tests included.
Fixes BZ#367995
Patch by: Ruurd Beerstra <ruurd.beerstra@infor.com>
Ivo Raisr [Fri, 23 Sep 2016 17:23:47 +0000 (17:23 +0000)]
Fix expected error output of drd/tests/bar_bad* on Solaris.
On Solaris, we still do get error reports about destroying
a barrier which was never initialized even after SVN r15962.
We also get an error report about destroying barrier bar3
which is still waited upon by a thread.
n-i-bz
Carl Love [Thu, 22 Sep 2016 15:37:57 +0000 (15:37 +0000)]
Powerpc big endian, fix the expected output file for
none/tests/ppc64/jm_int_isa_2_07.stdout.exp
By convention the file jm_int_isa_2_07.stdout.exp is the big endian reuslts.
If the little endian results differ, the file has -LE appended to it.
This patch replaces the little endian results that are currenttly in
none/tests/ppc64/jm_int_isa_2_07.stdout.exp with the correct the big
endian results.
Mark Wielaard [Mon, 19 Sep 2016 14:16:35 +0000 (14:16 +0000)]
Workaround bar_bad testcase hanging with newer glibc in helgrind/drd tests.
This is a workaround for bug #358213 helgrind/drd pthread_barrier tests
hangs with new glibc pthread barrier implementation. This makes sure that
the tests don't hang anymore. It does this by creating new threads that
sleep and kill the other threads after some time. But this introduces
some non-determinism that might cause the tests to occassionally fail
(both against old and new glibc implementations).
Carl Love [Wed, 14 Sep 2016 16:43:27 +0000 (16:43 +0000)]
Add tc06_two_races_xml.exp output for ppc64
Update xml filter to suppress pthread_create_WRK frame. Update the filter_xml
filter to suppress the frame containing the pthread_create_WRK function. This
allows the tc06_two_races_xml test to complete reliably on power.
This change also adds the ability to suppress the printf that generates a
"pthread_create_WRK...pthread_create" entry to replace the suppressed frame.
This is conceptually a follow-up from r13983, which suppresses the
pthread_create_WRK entry from non-xml outputs.
Patch submitted by Will Schmidt <will_schmidt@vnet.ibm.com>
Carl Love [Wed, 14 Sep 2016 15:50:48 +0000 (15:50 +0000)]
Adapt massif mmapunmap test to handle ppc64 backtrace
The reported backtrace on ppc64 platform reports "generic_start_main.isra.0"
in the backtrace, where other platforms typically see "main". Adjust the
vgtest file to handle this variation. This is similar to existing changes
as seen in deep-D.post.exp
FORGOT to add the file massif/tests/mmapunmap.post.exp-ppc64 before doing
commit 15950.
Mark Wielaard [Tue, 13 Sep 2016 19:18:36 +0000 (19:18 +0000)]
Correct an Altivec configure think-o.
An earlier change introduced a think-o in the altivec capability
check, allowing a false positive if the compiler supported altivec
but the hardware did not.
Resolves bug #368412 - False positive result for altivec capability check
Patch by Will Schmidt <will_schmidt@vnet.ibm.com>
Mark Wielaard [Tue, 13 Sep 2016 19:06:23 +0000 (19:06 +0000)]
Update libiberty demangler.
Update the libiberty demangler using the auxprogs/update-demangler
script. There were various extensions and bug fixes since our last
import. Add new D language demangler file d-demangle.c and update
the vg_libciface.h header with some new constructs used (strtol,
xmalloc_failed, xmemdup, XDELETEVEC, XDUPVEC).
Resolves bug #359181 - Buffer Overflow during Demangling.
Carl Love [Tue, 13 Sep 2016 15:54:33 +0000 (15:54 +0000)]
Adapt massif mmapunmap test to handle ppc64 backtrace
The reported backtrace on ppc64 platform reports "generic_start_main.isra.0"
in the backtrace, where other platforms typically see "main". Adjust the
vgtest file to handle this variation. This is similar to existing changes
as seen in deep-D.post.exp
Fix 199468 - Suppressions: stack size limited to 25 while --num-callers allows more frames
Nr of callers in a suppression entry had a smaller limit than the max
for --num-callers.
This means it was not possible to precisely suppress an error with a big
stack trace.
Also, --gen-suppressions was not providing the full stack trace of
the error in the generated suppressions.
Now, a suppression entry can have the same nr of callers as a backtrace.
Generated suppressions are generated with up to --num-callers callers.
This change has neglectible impact :
* memory: stack array of 500*2 words is declared, instead of 24*2 words
This array is declared on the interim stack (startup stack), which is
largely big enough.
* cpu : neglectible more cpu needed to read suppression entries
(to initialise the bigger stack array when reading a supp entry),
Apart of the above, no impact on performance (unless of course bigger
supp entries are really used).
Note that this does not impact the behaviour for existing suppression files.
Ivo Raisr [Fri, 12 Aug 2016 22:28:50 +0000 (22:28 +0000)]
Follow recent Solaris development with respect to
SUNWDTRACE program header. Newer Solaris no longer utilizes
this program header as a scratchspace for DTrace fasttrap
provider, before libc is loaded.
For the time being, it serves as a space for initial thread
pointer.
n-i-bz
Julian Seward [Wed, 10 Aug 2016 22:22:20 +0000 (22:22 +0000)]
Connect the v8crypto test to the build system, at least somewhat, so
as to make the post-regtest-tests happy. Still needs configure.ac
checking for "-mfpu=crypto-neon-fp-armv8" gcc flag support.
Petar Jovanovic [Wed, 10 Aug 2016 14:38:10 +0000 (14:38 +0000)]
mips32: add support for FPXX mode
With this patch, MIPS32 Valgrind compiled with -mfpxx can handle all types
(regarding FP_ABI flag) of MIPS32 ELFs.
- Functions arch_elf_pt_proc() and arch_check_elf() are added to elf reader
according to linux/fs/binfmt_elf.c from Linux 4.1;
- Processing .MIPS.abiflags section and initializing appropriate FPU mode
for MIPS32 are added;
- Emulation of prctl(GET/SET_FP_MODE) sys-calls are implemented for MIPS32.
Patch by Aleksandar Rikalo <Aleksandar.Rikalo@imgtec.com>
Julian Seward [Sat, 6 Aug 2016 12:33:59 +0000 (12:33 +0000)]
Fix uses of CPSR in these tests, so that (1) the relevant fields are
initialised properly before the test, and (2) after the test, we don't
print implementation-defined parts of the resulting CPSR.
Julian Seward [Sat, 6 Aug 2016 12:32:37 +0000 (12:32 +0000)]
do_vldm_vstm_check: don't use caller saved FP ('s') registers to hold
data that we expect to stay alive over calls to printf. Fixes erratic
failures of this test.
Julian Seward [Fri, 5 Aug 2016 14:54:27 +0000 (14:54 +0000)]
Reimplement pszB_to_listNo using a binary search rather than a linear search.
Unlikely as it seems, this saves a considerable number of instructions (2% of total)
on very heap-intensive code (perf/heap.c).
Julian Seward [Thu, 4 Aug 2016 21:11:28 +0000 (21:11 +0000)]
Make "ashmem" and "binder" ioctls be handled properly on 64-bit ARM Android,
rather than falling through to the generic handler and being mishandled.
Fixes #360574.
Ivo Raisr [Fri, 29 Jul 2016 20:52:21 +0000 (20:52 +0000)]
Fix test memcheck/tests/descr_belowsp a bit on Solaris.
On Solaris, '%p' outputs just a hexadecimal number
without '0x' prefix. This is perfectly valid but not
understood by VG_(strtok_get_address_and_size)().
Therefore use universal PRIxPTR.
n-i-bz
Carl Love [Thu, 28 Jul 2016 16:51:53 +0000 (16:51 +0000)]
When running the valgrind tests, the jm-insns test is segfaulting when it
attempts to patch instructions as it deals with the ppc64 (BE) function
descriptor. This is actually due to the RELRO option being enabled by default
for the ppc64 (BE) platform, per an upstream binutils change.
Bugzilla 365912 reported by Will Schmidt, Will supplied the patch to fix the
make file none/tests/ppc64/Makefile.a
Add test cases for PCMPxSTRx cases 0x62 and 0x72, and reformat the associated
switch statements a bit more consistently. Pertains to #353384 and #353727.
Regression test for n-i-bz amd64: memcheck false positive with shr %edx
Valgrind side : reproducer for the false positive memcheck
+ announce the fix (VEX side in next commit)
Fix leak in m_redir.c
See below discussion for more details.
On Sat, 2016-07-02 at 14:20 +0200, Philippe Waroquiers wrote:
> I am testing a patch (provided by Julian) that solves a false positive
> memcheck found at my work.
>
> Testing this, I decided to run valgrind under valgrind (not done since
> a long time).
>
> This shows a leak in many tests, the stack trace being such as:
> ==26246== 336 bytes in 21 blocks are definitely lost in loss record 72 of 141
> ==26246== at 0x2801C01D: vgPlain_arena_malloc (m_mallocfree.c:1855)
> ==26246== by 0x2801D616: vgPlain_arena_strdup (m_mallocfree.c:2528)
> ==26246== by 0x2801D616: vgPlain_strdup (m_mallocfree.c:2600)
> ==26246== by 0x2801F5AD: vgPlain_redir_notify_new_DebugInfo (m_redir.c:619)
> ==26246== by 0x2803B650: di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:771)
> ==26246== by 0x2803B650: vgPlain_di_notify_mmap (debuginfo.c:1067)
> ==26246== by 0x2806589C: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2368)
> ==26246== by 0x2809932A: vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:637)
> ==26246== by 0x28061E11: vgPlain_client_syscall (syswrap-main.c:1906)
> ==26246== by 0x2805E9D2: handle_syscall (scheduler.c:1118)
> ==26246== by 0x280604A6: vgPlain_scheduler (scheduler.c:1435)
> ==26246== by 0x2806FF87: thread_wrapper (syswrap-linux.c:103)
> ==26246== by 0x2806FF87: run_a_thread_NORETURN (syswrap-linux.c:156)
>
>
> The strdup call in m_redir.c:619 was introduced by r15726.
>
> However, I am not sure this is a bug that is introduced by this change,
> or if it just reveals a leak that was already there.
> The "very original" replacement logic did not do memory allocation for
> the replacement: see m_redir.c in valgrind 3.10.1 : it was just copying
> some chars from VG_(clo_soname_synonyms) to demangled_sopatt
Yes, it should do exactly the same as the other code paths. If
replaced_sopatt != NULL then it is an allocated string that has been
assigned to demangled_sopatt. I had assumed that would take care of the
life-time issues of the allocated string. But now that I read the code
it is indeed not so clear.
> Then in 3.11, the fixed size demangled_sopatt was changed to be
> a dynamically allocated buffer.
> The revision log 14664 that introduced this explains that the ownership of
> returned buffer is not easy. It tells at the end:
> "So the rule of thunb here is: if in doubt strdup the string."
>
> but now we have to see when to free what, it seems ???
>
> Any thoughts ?
So if replaced_sopatt != NULL, then demangled_sopatt contains the
allocated string, and it is then immediately copied and assigned to
spec->from_sopatt. After that it is used under check_ppcTOCs. But there
it will first be reassigned a new value through maybe_Z_demangle
(overwriting any existing string being pointed to). So for this
particular leak it seem fine to free it right after the spec[List] has
been initialized (line 642).
Carl Love [Mon, 27 Jun 2016 15:50:29 +0000 (15:50 +0000)]
Add the HW register support for missing registers in get_otrack_shadow_offset_wrk(). The registers are: NRADDR, NRADDR_GPR2, (REDIR_STACK, TFHAR, TEXASR, TEXASRU, TFIAR, PPR, PSPB.
projects / thirdparty / valgrind.git / log
