* Redzones for custom alloc were not protected by VALGRIND_MALLOCLIKE_BLOCK.
mc_main.c client request handling completed with protection
of the redzones.
* custom_alloc.c test modified to test this case.
* mc_errors.c modified so as to first search for a malloc-ed block
bracketting the error : for a custom allocator, a recently freed
block can have just been re-allocated.
In such a case, describing the address (e.g. in case of error)
points to the block freed rather than to the block just allocated.
If there is *also* a recently freed block bracketting the address,
the block description is changed to indicate that.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12439
is failing on a 64 bit host.
The bug might or might not be related to some
errors "failed in UME with error 22"
(such as bug https://bugs.kde.org/show_bug.cgi?id=138424).
The bug is: when aspacem_maxAddr is very close to the upper limit,
and aspacem_minAddr is somewhat not close to 0, then
the computation of
aspacem_vStart = VG_PGROUNDUP((aspacem_minAddr + aspacem_maxAddr + 1) / 2);
can overflow.
The vStart value will then silently wrap around.
(please, give me my Ada language back :).
When overflowing, vStart will then be below the client cStart.
At least when running outer on inner on a 32 bit application on
a 64 bit system, this was causing strange problems.
I suppose that on a 64 bit system, a 32 bit application can use more
of the 4 Gb, and then the max address is higher and can more easily
overflow than on a 32 bit system.
Tested on f12/x86, debian6/amd64 (bi-arch).
+ run a few outer on inner x86 regression tests : these were all failing
and are now succesfully running.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12438
negatives, by marking the V bits that come from out of range parts of
the access as undefined; and hence any use of them leads to an value
error. Prior to this they were marked as defined and could be used
without error.
Behaviour of --partial-loads-ok=no (the default case) is unchanged.
Also add some testing thereof.
Fixes#294523. Modified version of a patch and testcase by Patrick
J. LoPresti (lopresti@gmail.com).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12430
since gcc complains about "statement with no effect" or some such for
the simple "0" version. Also, make the formal parameter names a bit
more unique.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12426
remove_mapping_callback: if the kernel tells us of a gap that
partially, but does not exactly, overlap a V segment, only record
directives to remove that part of the segment that actually falls
within the gap. Removing the entire V segment is incorrect and can
cause Memcheck to believe that memory not within the hole is
inaccessible, leading to floods of invalid errors. Fixes
https://bugzilla.mozilla.org/show_bug.cgi?id=715750
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12422
(found by running regression tests with an outer memcheck).
(validated by running all regression tests "natively" on x86 and amd64,
and re-running regressions tests with outer memcheck).
==7500== 160 bytes in 2 blocks are definitely lost in loss record 75 of 246
==7500== at 0x2803CEF7: vgPlain_arena_malloc (m_mallocfree.c:1599)
==7500== by 0x280AAFA5: vgModuleLocal_dinfo_zalloc (misc.c:48)
==7500== by 0x2804E2A4: vgPlain_newXA (m_xarray.c:68)
==7500== by 0x280B3CD6: unitary_range_list (readdwarf3.c:703)
==7500== by 0x280B66CF: parse_var_DIE (readdwarf3.c:1631)
==7500== by 0x280BA0A6: read_DIE (readdwarf3.c:3248)
==7500== by 0x280BA170: read_DIE (readdwarf3.c:3269)
==7500== by 0x280BABC4: T.364 (readdwarf3.c:3611)
==7500== by 0x280BC634: vgModuleLocal_new_dwarf3_reader (readdwarf3.c:4035)
==7500== by 0x280609F4: vgModuleLocal_read_elf_debug_info (readelf.c:2529)
==7500== by 0x2805BD31: vgPlain_di_notify_mmap (debuginfo.c:610)
==7500== by 0x280362E3: valgrind_main (m_main.c:1944)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12419
* make a reference to --vex-iropt-precise-memory-exns=yes
to obtain up to date registers values.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12416
* manual-core.xml : fix a typo
* include/pub_tool_inner.h : new file, defining macros for inner annotation
include/Makefile.am : reference this new file.
* syswrap-linux.c : when ENABLE_INNER, register the stacks for the outer.
(otherwise, nothing works properly).
* m_redir.c : avoid inner interpreting the outer vgpreload instructions.
* sema.c : annotate the semaphore with RWLOCK annotations for helgrind
* ticket-lock-linux.c : similar.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12414
Buffers should not be re-allocated in such a case.
(memory leak detected by running memcheck on memcheck)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12410
Previously it looked for the debuginfo object for "/system/X" in
"/sdcard/symbols/system/X". This commit removes the requirement for
"system" as the first path component, so the mapping is now "/X" (viz,
any absolute path) to "/sdcard/symbols/X".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12406
once place. This was breaking vg-in-place on platforms
needing gdbserver target description files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12401
These holes are not initialized,
and writing these uninitialised bytes to the mapped file
causes an error being reported when running Valgrind
inside Valgrind. Having no holes avoid having this error.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12397
functions that do FP arithmetic. This is due to the Dwarf3 CFI
mentioning Dwarf registers above N_CFI_REGS, in particular FP
registers, which have values of about 80. This fixes the problem by
increasing N_CFI_REGS to a level that covers all known registers.
(n-i-bz)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12393
