Further fix 297078 : implement conversion between vki and gdb real time sig nr.
* gdbserver_tests/nlpasssigalrm
modify test so as to test also a real time signal
* coregrind/m_gdbserver/signals.c
- implement translation between gdb real time signal numbers
and vki real time signal numbers
- ensure non-convertible signals are giving an error
Fix bug 297078 gdbserver signal handling problems caused by diff vki nr/gdb nr and
non reset of "C-ontinued" signal
* To allow vki signame to be used in debuglog:
- pub_core_signals.h : added prototype for Char *VG_(signame)
- m_signals.c : changed static const Char *signame(Int sigNo)
to const Char *VG_(signame)(Int sigNo)
* valgrind-low.c : when the signal to report to gdb has
been reported, clear it so that it is not reported anymore
afterwards.
* m_gdbserver.c: when checking in pass_signals if signal
can be passed without gdb interaction, do a conversion
from vki nr to gdb nr when indexing
(as pass_signals[] is indexed by gdb_nr).
* various gdbserver files:
- used vki_ prefix for some args and variables to clarify
- better debuglog tracing
* modified nlpasssigalrm.vgtest to test SIGCHLD signal
handling followed by a break (to see SIGTRAP is properly
given to gdb).
Julian Seward [Tue, 27 Mar 2012 10:19:39 +0000 (10:19 +0000)]
/* Do expensive interpretation for Iop_Add32 and Iop_Add64 on
Darwin. 10.7 is mostly built with LLVM, which uses these for
bitfield inserts, and we get a lot of false errors if the cheap
interpretation is used, alas. Could solve this much better if
we knew which of such adds came from x86/amd64 LEA instructions,
since these are the only ones really needing the expensive
interpretation, but that would require some way to tag them in
the _toIR.c front ends, which is a lot of faffing around. So
for now just use the slow and blunt-instrument solution. */
Pertains to, although does not completely solve, #242137.
Julian Seward [Tue, 27 Mar 2012 10:06:31 +0000 (10:06 +0000)]
Add a nasty kludge in the handling of mmap on Darwin. Does not apply
to any other platforms. Prevent mmap(ANON) from returning zero (zero
with success, that is) since (a) some programs are observed to be
spooked by getting zero from a successful call to mmap, and (b) it's
pretty stupid from the point of view of program safety and possibly
security, since it causes page zero to become accessible. So don't.
Bart Van Assche [Sun, 25 Mar 2012 17:51:59 +0000 (17:51 +0000)]
Check whether the big lock is held before invoking pre_thread_ll_create.
If the pre_thread_ll_create tracking function would be invoked without the
big lock being held, that would trigger a race condition in the tools that
implement this tracking function.
Have check_makẹfile_consistency run at the end of make regtest
This ensures that a missing file in the Makefile is detected,
without blocking the tests.
add test-plo-no.stderr.exp-s390x-mvc in EXTRA_DIST.
Note: such missing files in EXTRA_DIST are found
by check_makefile_consistency.
However, to avoid blocking the tests, the return code
of check_makefile_consistency is ignored, but the errors
it detects are pages before the end of the make regtest output.
=> it might be a good idea to move the check_makefile_consistency
as the last step of regtest: target, and not ignore its return code.
This means:
trials tests will not block make regtest
such errors will be noticed.
For the moment, just fixed the missing file in EXTRA_DIST
Modify test so that scheduling events are generated.
Even without fair scheduling, this ensures the progress
of each thread.
This avoids the test looping forever in an outer/inner
setup.
Florian Krohm [Sun, 18 Mar 2012 01:51:12 +0000 (01:51 +0000)]
Add spreadsheet that lists all s390 opcodes in the following format:
1. column: mnemonic
2. column: description
3. column: implementation status
4. column: comments, if any
Prepared by Divya Vyas (divyvyas@linux.vnet.ibm.com).
(for x86 and amd64): Change the type of the shadow regs for floating point registers
Similar to r12444 (see Log below), but this is doing it for x86 and amd64.
The xmm registers are using uint32 or uint64 for their float
union components. For the i387 80 bits float registers, as there is
no uint80, a struct uint16 + uint64 is defined.
Log:
Change the type of the shadow regs for floating point registers
to be uint64. Previously the value in such a shadow reg would
be interpreted by gdb as a floating point value which would
produce non-sensible output for e.g p/x $f1s1.
This patch covers the power and arm architectures.
Florian Krohm [Wed, 14 Mar 2012 01:15:59 +0000 (01:15 +0000)]
Change the type of the shadow regs for floating point registers
to be uint64. Previously the value in such a shadow reg would
be interpreted by gdb as a floating point value which would
produce non-sensible output for e.g p/x $f1s1.
This patch covers the power and arm architectures.
Fix leak in debuginfo.c
di->soname was not freed, so was leaked when debug info is removed.
free(soname) added in free_Debuginfo, after having verified
and then ensured that all soname are allocated in dinfo.
Allows to run regression tests in an outer/inner setup.
A '3 lines how to':
perl tests/vg_regtest --outer-valgrind=../trunk_untouched/install/bin/valgrind --all
(the outer results for a test xxx is in xxx.outer.log)
To run with another tool (e.g. drd), add the argument --outer-tool=drd
Still to do/things to improve:
* Most (inner) tests are successful when running under an outer
memcheck. Need to analyse the reasons of remaining failures.
* The memcheck annotations in m_mallocfree.c can be improved:
- A superblock is marked 'undefined', it should rather be marked
'no access'.
- When a free block is splitted, the remaining free block is
not made 'no access'. Instead, it is made 'undefined'.
=> this decreases the chance to find bugs.
=> this is not very efficient (e.g. the rest of a superblock
is often marked undefined repetitively).
Similarly, the free block created by VG_(arena_memalign)
is marked 'undefined'. 'No access' would be preferrable.
- mkInuseBlock marks the new block as undefined. This is probably
not needed, as VALGRIND_MALLOCLIKE_BLOCK will do it already.
- VG_(arena_malloc) should give the requested size to
VALGRIND_MALLOCLIKE_BLOCK, not the malloc usable size,
as this decreases the chance to find buffer overrun bugs.
But giving the requested size is tricky (see comments in
the code).
* need to do memcheck annotations in m_poolalloc.c
so as to allow leak checking for pool allocated elements.
* vg_regtest.in
- should analyse the results of the outer and should
produce a separate result for the tests for which
the outer detects an error or a memory leak or ...
Changes done:
README_DEVELOPERS: document the new outer/inner features.
manual-core.xml: document the new sim-hint no-inner-prefix
tests/outer_inner.supp: new file, containing the suppressions for inner.
vg_regtest.in: implement new args --outer-valgrind, --outer-tool, --outer-args.
m_mallocfree.c: annotations for memcheck.
m_libcprint.c: handle the new sim-hint no-inner-prefix
m_main.c: do an (early) parse of --sim-hints
Ensure VALGRIND_MALLOCLIKE_BLOCK protects the red zones.
* 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.
Finally understood why an outer on inner on a 32 bit application
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.
Julian Seward [Thu, 8 Mar 2012 14:51:01 +0000 (14:51 +0000)]
Change the behaviour of --partial-loads-ok=yes to avoid false
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).
Julian Seward [Wed, 7 Mar 2012 17:11:44 +0000 (17:11 +0000)]
Turn no-op versions of INNER_REQUEST into statements, not values,
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.
Julian Seward [Wed, 7 Mar 2012 13:28:05 +0000 (13:28 +0000)]
MacOS only: VG_(get_changed_segments) callback
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
Fix leak of range_list (see below an example) in readdwarf3.c.
(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)
* README_DEVELOPERS : complete/enhance the section about outer/inner
* 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.
After a fork, gdbserver_init can be called again.
Buffers should not be re-allocated in such a case.
(memory leak detected by running memcheck on memcheck)
Julian Seward [Mon, 27 Feb 2012 11:02:20 +0000 (11:02 +0000)]
Android only: make the debuginfo mapping hack more flexible.
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".
Revision 12396 (replacing pkglib_DATA by vglib_DATA) missed
once place. This was breaking vg-in-place on platforms
needing gdbserver target description files.
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.
Julian Seward [Mon, 20 Feb 2012 15:33:24 +0000 (15:33 +0000)]
ARM/Thumb only: fix a bug in which stack unwinding halts in some
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)
* compare vgdb-error with n_errs_shown, not with n_errs_found.
Using n_errs_shown allows the user to stop on an error
identified in a previous run by counting errors shown.
* shows also n_errs_shown in monitor command v.info n_errs_found
* slightly clarified the manual, updated to new output of v.info n_errs_found
* fix Bug 290655 - Add support for AESKEYGENASSIST instruction
(Valgrind part : test for AES instructions (AESKEYGENASSIST, AESIMC,
AESENC, AESENCLAST, AESDEC, AESDECLAST).
Julian Seward [Tue, 14 Feb 2012 12:11:47 +0000 (12:11 +0000)]
Change the garbage collection policy for the secondary VBit table
(that holds partially defined bytes), to GC more aggressively.
Details in the comments. This largely avoids a sometimes massive
space leak, that has been observed (eg) running the Firefox test suite
on Memcheck. Without this patch it cannot complete with 4 million
nodes in the table; with the patch it completes comfortably with 50000
ish nodes. This reduces the total memory use needed for the run
from above 7GB down to 6.2GB.
Smaller improvements have been seen with other programs too. Speed
does not appear to be negatively affected.
(Based on a patch, and analysis of the problem, by Philippe Waroquiers.)
Bart Van Assche [Mon, 13 Feb 2012 08:47:51 +0000 (08:47 +0000)]
nightly build: Run nightly build also if only VEX has been modified. Check out matching revisions of Valgrind and VEX instead of using latest VEX when checking out the (today - 1) source code.
projects / thirdparty / valgrind.git / log
