Kernel allocates another page after fork and we have to
keep aspacemgr's point of view consistent.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15937
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
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15936
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>
Related VEX change: r3243.
This implements BZ#366079.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15934
Unlikely as it seems, this saves a considerable number of instructions (2% of total)
on very heap-intensive code (perf/heap.c).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15926
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).
Cheers,
Mark
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15898
Don't check or try to copy sigmask if it is NULL. The sigmask might be
given in a struct, where the length is non-zero, but the signal set
pointer is NULL.
Testcase provided by Paul Eggert <eggert@cs.ucla.edu>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15893
bz#354883
Whilst I’ve seen different magic_delta values on one of my older development machines (Intel Nehalem-based), enough other users have reported success with this change.
If this causes regressions, please report your hardware details in our Bugzilla.
Regression test output on OS X 10.11
Before:
== 601 tests, 223 stderr failures, 12 stdout failures, 0 stderrB failures, 0 stdoutB failures, 31 post failures ==
After:
== 601 tests, 223 stderr failures, 12 stdout failures, 0 stderrB failures, 0 stdoutB failures, 31 post failures ==
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15891
The msg telling brk cannot be extended confuses some users
so improve the documentation and have the msg referencing the doc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15880
Raise limit for sizeof(TTEntryC) due to 8-byte alignement requirement for
ULong on mips32 platforms. It is a follow up to the same change on ppc32
(see r15875), and it un-breaks mips32-linux (broken with r15784).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15876
layout constraints are different from x86-ELF and so the assertion on
the sizeof(TTEntryC) fails on ppc32-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15875
TTEntryH and TTEntryC. TTEntryH is a VexGuestExtents plus one more
field. For scenarios involving a lot of code discarding, when the
fast-path discard mechanism does not apply, this change reduces
significantly the number of LLC misses, because such discarding
involves sequentially searching the arrays of TTEntryH's. For recent
Firefoxes the miss rate in a 6MB L3 cache is reduced by about 1/3, as
measured by /usr/bin/perf.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15874
for Elf{32,64}_Chdr. This is fallout from r15868. That commit provided
a configure test, but the resulting config.h was not included here, causing
the test results to be ignored.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15869
- zlib ELF gABI format with SHF_COMPRESSED flag (gcc option -gz=zlib)
- zlib GNU format with .zdebug sections (gcc option -gz=zlib-gnu)
Patch by: Aleksandar Rikalo <aleksandar.rikalo@imgtec.com>
Fixes BZ#303877
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15868
early during main initialization, before the threads are
created and scheduler is initialized.
Fixes BZ#362009
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15867
correctly
Forgot to add the new files to the previous commit 15864.
coregrind/m_gdbserver/power64-core2-valgrind-s1.xml
coregrind/m_gdbserver/power64-core2-valgrind-s2.xml
coregrind/m_gdbserver/power-vsx-valgrind-s1.xml
coregrind/m_gdbserver/power-vsx-valgrind-s2.xml
coregrind/m_gdbserver/power-vsx.xml
Bugzilla 360008 was opened for this issue.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15866
correctly
1) Fix Endianess issue that was missed in the BE to LE port. GDB was
not displaying the contents of the 64-bit and 128-bit registers
correctly due to an Endianess issue.
2) Fix displaying the shadow registers for the 64-bit and 128-bit
registers.
Bugzilla 360008 was opened for this issue.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15864
is no longer needed. The situation with multiple ".rodata" sections existed
only between dozens of builds of Solaris 12.
Fixes BZ#360749
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15853
Newer glibc will use separate socket related syscalls instead of using
the multiplexing socketcall systemcall. On Fedora rawhide this causes
several tests to fail.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15845
from libstdc++ when available, similar to existing __libc_freeres().
New option --run-cxx-freeres=<yes|no> can be used to change whether
this cleanup function is called or not.
Note that __gnu_cxx::__freeres() is currently available
only in gcc 6. It is not yet decided what to do about
libstdc++ from gcc 5.
Tracked under https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945
for libstdc++.
Fixes BZ#345307 (partially).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15840
We somehow overlooked this commit during development work on Solaris port
before it landed in the official repository.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15839
The Floating-point condition code bits FPCC is bits[15:12] of the FPSCR.
The instructions fcmpu, fcmpo, dcmpu, dcmpq, dtstdc, dtstdcq, xscmpodq
and xscmpudq set the FPCC bits in addition to the BE field of the CC
register. This support is needed by the ISA 3.0 instructions to be added.
Added support to emulate the modsw, moduw, modsd, modud, extswsli,
maddld, maddhd, maaddhdu, xxperm, xxpermr, vabsdub, vabsduh, vabsduw,
mtvsrws, xxextractuw, xxinsertw, xxspltib, xxbrh, xxbrw, xxbrd, xxbrq,
vpermr, vextractub, vextractuh, vextractuw, vextractd, vinsertb, vinserth,
vinsertw, vinsertd, lxvwsx, stxvb16x, stxvx, lxvb16x, lxvh8x, lxvx
instructions.
valgrind bugzilla 359767
VEX commit 3214
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15837
* fix off-by-one error that forced use of the slow case unnecessarily
* change ECLASS_SHIFT from 11 to 13 so that ranges up to 8KB can fall
within an equivalence class, and increase ECLASS_WIDTH by 1 so as to
double the number of hash buckets (effectively).
These measures noticably improve the performance of modern Firefoxes,
since they do a lot of 4KB and 8KB discards as a result of mprotect
trickery used to implement W^X protection on JIT code pages.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15833
Enable more arm64 syscalls. ioprio_set, ioprio_get, preadv, pwritev,
vmsplice, splice, tee, waitid, clock_nanosleep and perf_event_open.
Reported and patch (mostly) by Marcin Juszkiewicz.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15826
The new memcheck/tests/arm64-linux/scalar test is based on the
memcheck/tests/x86-linux/scalar test and contains all syscalls
that are also available on arm64. To make comparison of exp results
easier the order of the tested syscalls is the same as on x86.
This enables a couple extra arm64 syscalls. Part of the fix for
bug #359503 - Add missing syscalls for aarch64 (arm64).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15825
We were using some wrong syscall numbers in vki-scnums-arm64-linux.h
arm64 doesn't implement a couple of old deprecated system calls like
rename, dup2, getpgrp and fork. Adjust m_libcfile.c rename and dup2
functions to use renameat (also on tilegx) and dup3 (with fcntl fallback
for bad oldfd). And in m_libcproc.c implement getpgrp as getpgid(0).
Also don't compile the fork syswrap on arm64 (it only supports clone).
In practice this only affected callgrind which was unable to rename
dump files in some cases and ELF core dumps might have contained some
bogus prstatus fields.
Related to bug #359503 - Add missing syscalls for aarch64 (arm64)
Reported by Marcin Juszkiewicz who also posted a nice overview
of system calls on different linux architectures:
https://marcin.juszkiewicz.com.pl/2016/03/05/from-a-diary-of-aarch64-porter-system-calls/
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15824
