This is because that dwarf entry defines a struct with no size.
This happens when the struct has a VLA array in the middle
of a struct. This is a C gcc extension, and is a standard
feature of Ada.
The proper solution would be to have the size calculated at runtime,
using the gnat extensions or dwarf entries (to be generated by
the compiler).
The patch fixes this problem by defining the size of such structure
as 1 byte.
Another approach tried was to put the max possible size.
This had the disadvantage that any address on the stack was seen
as belonging to this variable.
This allows the description to work for the 1st byte of the variable
but cannot properly describe the 2nd and following bytes :
(gdb) p &n
$9 = (namet *) 0xbefbc070
(gdb) mo c d 0xbefbc070
Address 0xBEFBC070 len 1 not defined:
Uninitialised value at 0xBEFBC070
==1396== Location 0xbefbc070 is 0 bytes inside n.before_name,
==1396== declared at crec.c:10, in frame #0 of thread 1
(gdb) mo c d 0xbefbc071
Address 0xBEFBC071 len 1 not defined:
Uninitialised value at 0xBEFBC071
==1396== Address 0xbefbc071 is on thread 1's stack
(gdb)
A possible refinement would be to use a huge size but have the
logic of variable description understanding this and describing
all between this var and hte next var on the stack as being
in the VLA variable.
In the meantime, the size 1 avoids --read-var-info=yes to fail.
Also, the 'goto bad_DIE' have been replaced by a macro
goto_bad_DIE that ensures the line nr at which the bad DIE has
been detected is reported in the error msg.
This makes it easier to understand what is the problem.
Julian Seward [Mon, 5 May 2014 10:03:56 +0000 (10:03 +0000)]
Fix assertion failures resulting from change of arity of
Iop_{Add,Sub,Mul}32Fx4 introduced in r2809, in which said IROps
acquired a rounding-mode argument.
Julian Seward [Sun, 4 May 2014 10:54:08 +0000 (10:54 +0000)]
Renaming only (no functional change): rename IR artefacts to do
with i-cache invalidation to be more consistent with new d-cache
flushing functionality, so as to track changes in Vex r2852:
Ijk_TInval -> Ijk_InvalICache
TISTART -> CMSTART (CM == "Cache Management")
TILEN -> CMLEN
VEX_TRC_JMP_TINVAL -> VEX_TRC_JMP_INVALICACHE
Julian Seward [Sun, 4 May 2014 10:52:11 +0000 (10:52 +0000)]
Renaming only (no functional change): rename IR artefacts to do
with i-cache invalidation to be more consistent with new d-cache
invalidation functionality:
Ijk_TInval -> Ijk_InvalICache
TISTART -> CMSTART (CM == "Cache Management")
TILEN -> CMLEN
VEX_TRC_JMP_TINVAL -> VEX_TRC_JMP_INVALICACHE
Helgrind : two new gdbserver commands 'describe address' and 'info locks'
- Helgrind GDB server monitor command 'describe <address>'
allowing to describe an address (e.g. where it was allocated).
- Helgrind GDB server monitor command 'info locks' giving
the list of locks, their location, and their status.
In a further patch, it is intended to
1. factorise the describe address code between memcheck and helgrind
2. generalise the describe address gdbsrv command so as to make
it usable for all tools.
Bart Van Assche [Thu, 1 May 2014 08:05:49 +0000 (08:05 +0000)]
syswrap: XEN_DOMCTL_resumedomain
No input or output parameters
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13928
Bart Van Assche [Thu, 1 May 2014 08:05:24 +0000 (08:05 +0000)]
syswrap: XEN_HVMOP_set_mem_type
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> CC: Ian Campbell <Ian.Campbell@citrix.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13927
Bart Van Assche [Thu, 1 May 2014 08:05:06 +0000 (08:05 +0000)]
syswrap: XEN_HVMOP_set_pci_link_route
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> CC: Ian Campbell <Ian.Campbell@citrix.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13926
Bart Van Assche [Thu, 1 May 2014 08:04:42 +0000 (08:04 +0000)]
syswrap: XEN_HVMOP_set_isa_irq_level
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> CC: Ian Campbell <Ian.Campbell@citrix.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13925
Bart Van Assche [Thu, 1 May 2014 08:04:18 +0000 (08:04 +0000)]
syswrap: XEN_DOMCTL_cacheflush
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> CC: Ian Campbell <Ian.Campbell@citrix.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13924
Bart Van Assche [Thu, 1 May 2014 08:03:13 +0000 (08:03 +0000)]
syswrap: XEN_DOMCTL_settimeoffset
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> CC: Ian Campbell <Ian.Campbell@citrix.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13923
Bart Van Assche [Thu, 1 May 2014 08:02:39 +0000 (08:02 +0000)]
Fix P{RE,OST}_XEN_HVMOP_{READ,WRITE}
_type should be a type, not a string
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> CC: Ian Campbell <Ian.Campbell@citrix.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13922
Add a new test that shows a surprising side effect of the
medium resolution (4 callers) used to compare errors.
To look at the strange side effect, do:
./vg-in-place -v --suppressions=memcheck/tests/suppfreecollision.supp memcheck/tests/suppfree activatenondangerouserror
You obtain at the end:
...
--19240-- used_suppression: 2 suppressnondangerouserror memcheck/tests/suppfreecollision.supp:2
...
showing that the suppression aiming at suppressing a nondangerous error has in fact
suppressed more than expected.
This is because m_errormgr.c compares the exe_context in medium resolution/4 calls
(or low resolution/2 calls once 100 errors have been collected).
The error machinery first encounters the non dangerous error. This error is suppressed,
because all callers match the suppression entry. In particular, we have
in the stacktrace the function ok_to_suppress_double_free_from_this_fun
Then the error machinery encounters the second error.
The stacktrace of the 2nd error has the same first 4 callers than the non
dangerous error. So the 2nd error is considered equal to the first one
and is (unexpectedly in my opinion) suppressed.
This looks a bug (or at least something very surprising).
(the doc mentions the fact that errors are 'commoned up' on 4 callers, but
I am not sure the above side effect was understood).
There are several ways this can be improved, some are more easier than other
* have --error-resolution=low/med/high
similar to the memcheck --leak-resolution=low/med/high
(which default value would we take for this new clo ?)
* have a lot more intelligent error comparison:
when comparing an error with a suppressed error, one must
check that the callers used for suppression are equal.
This looks difficult to implement and probably a significant slow down
in the error machinery, which will impact applications producing
many suppressed errors (e.g. helgrind + some pthread lib errors).
This also implies more memory (e.g. one byte per caller in the
error, to indicate which caller(s) were used to suppress.
Still wondering what to do with * and ... ?
* have a somewhat more intelligent error comparison:
Instead of comparing only the callers used for suppression, we
compare the range first..last caller used (so including some
callers in the range that were not used to suppressed if e.g.
a ... matching was put in the supp entry).
Probably still a slowdown (less than previous solution ?)
and less memory than the previous solution.
But also not completely clear how to compute the range.
* always re-evaluate the suppression : this will very probably be
a significant slow down.
* do nothing, as nobody complained about this behaviour up to now :)
Make the test (more) deterministic by having send_signal using
a guardcmd before sending the signal.
This allows to be sure that the signal are emitted when vgdb
is attached.
We still have one 'sleep' in the test.
Due to timing problem, test was not properly testing.
What needs to be ensured is:
vgdb is attached (i.e. is ptracing valgrind)
2 sigusr1 signals are sent while vgdb is ptracing
vgdb will queue these signals
when continuing, the queued signals are delivered.
With 3.9.0, the above causes an internal error in valgrind:
valgrind: m_syswrap/syswrap-main.c:1436 (vgPlain_client_syscall): Assertion 'sci->status.what == SsIdle' failed.
It would be better to have explicit synchronisation in the test
rather than counting on 'sleep xxx' to have things done in the
order that tests the signal queueing.
Remove the 2 sed expressions that were trying to massage the
stacktrace for the last program instruction encountered with
--vgdb-stop-at=exit
These are not needed anymore, as these lines are now removed
Too difficult to match the stacktrace of the last instruction
of a program => let's remove these (uninteresting) lines
rather than trying to 'sed' them to make them look the same
on different OS/platform/....
* Modify nlgone_exit so that it tests --vgdb-stop-at=startup,exit
* remove empty lines from nlgone_*.stdinB.gdb, as these empty
lines are (surprisingly) repeating the previous gdb command.
Empty lines should be be put in the *gdb files.
* And add yet another sed expression in filter_gdb to cope with
the different place where a thread exits.
(this filter technique is now *really* arriving in a dead end
e.g. the link between the comment and the sed expression is very
poor).
* Factorise code between is_valid_for_client and is_valid_for_valgrind.
* Implement VG_(am_is_valid_for_valgrind)
* Use it in gdbsrv to check accessibility when hostvisibility is activated
* New option --aspace-minaddr=<address> allows to (possibly) make
use of some more memory by decreasing the default value
or solve some conflicts with system libraries by increasing the value.
See user manual for details.
Note that the lowest accepted possible value is 0x1000, which is
the current value used by Macos in 32bits.
On linux, 0x10000 (64KB) seems to cause not much conflicts.
Default values are unchanged (i.e. are the same as when there
was no clo option).
- The option "--vgdb-stop-at=event1,event2,..." allows the user
to ask GDB server to stop before program execution, at the end
of the program execution and on Valgrind internal errors.
- A new monitor command "v.set hostvisibility" that allows GDB server
to provide access to Valgrind internal host status/memory.
Factorise enum set parsing code
* add a function Bool VG_(parse_enum_set) in pub_tool_libcbase.h/m_libcbase.c
(close to Bool VG_(parse_Addr)
* Implement Bool MC_(parse_leak_heuristics) and MC_(parse_leak_kinds)
as a call to VG_(parse_enum_set)
Several improvements to (internal) statistics reporting about memory usage,
making it easier to understand the memory and/or oom situation.
No functional (user level) change.
* For --profile-heap=yes, sort the cost centers by decreasing size,
so that the most relevant cost centers are closed to the arena
total.
* factorise duplicated code calling a series of print stat functions
* VG_(show_sched_status)
optionally show the host stacktrace
the amount of valgrind stack used by each thread
the exited threads
* various functions: update to add VG_(show_sched_status) new
args, keeping the same info production as before.
* In case of out of memory situation detected by m_mallocfree.c,
reports more information:
valgrind and tool stats
scheduler status (full information)
* gdbserver v.info scheduler :
show full information.
The oom behaviour/reporting was tested using a small
program causing an OOM, and having several threads
(some terminated, some still active).
vgdb must not transmit signals when gdbserver has been ptrace-invoked.
Most of the time, Valgrind masks async signals, and polls for such
signals at regular interval.
There is a very narrow range of code (around client syscall logic)
where such signals are unmasked (as they must be able to interrupt
syscalls).
This is the only range of code where Valgrind is expecting to
receive such a signal.
When gdbserver is ptraced invoked, Valgrind is artificially made
to jump out of this code portion. Signals are not masked.
When ptraceing valgrind, vgdb will get these signals but cannot
transmit them immediately, otherwise they arrive in range
of code where they are not expected (causing internal error
in syscall logic) and/or causing gdbserver syscalls to be
interrupted.
3 solutions to solve that were looked at:
1. have the gdbserver code masking signals "as quickly as possible".
Easy to implement, but this leaves still a small window
of code where signals are not masked and would cause a problem.
2. have vgdb setting the SIGMASK of valgrind before invoking
gdbserver.
This would be easy to implement, but changing the SIGMASK
of the ptrace-d process is only available on very recent kernels.
3. have vgdb queuing signals, and only transmitting them once
gdbserver invocation is finished.
This 3rd solution has been implemented.
mips32: According to the glibc bug 5044 (https://sourceware.org/bugzilla/show_bug.cgi?id=5044)
until the glibc version 2.17 printf hadn't respected the rounding mode for decimal
output. Because of change in glibc printf function we need to change our
expected output file for none/tests/mips32/FPUarithmetic test.
mips32/64: According to DWARF version 4 in DW_TAG_structure_type we can
have DW_AT_signature attribute. That wasn't the case in DWARF version 3.
From DWARF version 4:
If the complete declaration of a type has been placed in a separate type unit,
an incomplete declaration of that type in the compilation unit may provide the
unique 64-bit signature of the type using a DW_AT_signature attribute.
This patch adds an extra field in TyStOrUn structure (typeR). This field is
reference to other TyEnt that is placed in separate type unit. Because of the new
field in TyStOrUn structure we need to add an extra case in parse_type_DIE
that will put the right reference to other TyEnt and an extra case in
ML_(describe_type) that will describe type when the ty->Te.TyStOrUn.typeR field
is used.
This patch is resolving the problem with memcheck/tests/dw4 test when it's
compiled with compiler that will emit DW_AT_signature under the DW_TAG_structure_type.
Julian Seward [Thu, 20 Mar 2014 23:00:09 +0000 (23:00 +0000)]
Add client requests
VALGRIND_DISABLE_ADDR_ERROR_REPORTING_IN_RANGE and
VALGRIND_ENABLE_ADDR_ERROR_REPORTING_IN_RANGE
and supporting machinery for managing whole-address-space sparse
mappings. n-i-bz. In support of
https://bugzilla.mozilla.org/show_bug.cgi?id=970643
Dejan Jevtic [Thu, 20 Mar 2014 10:23:43 +0000 (10:23 +0000)]
mips32: When we are accessing elements via double pointer MIPS compiler can
generate two consecutive 32bit loads instead of one 64bit load. Because of that
in error log we have two conflict loads of size 4 instead of one conflict load
of size 8.
Dejan Jevtic [Wed, 19 Mar 2014 11:58:35 +0000 (11:58 +0000)]
VG_(strlen) ( const HChar* str ) does not count the null terminator '\0' at the
end of the string, so we need to add an extra element in string 's' for the null
terminator.
VG_(strcpy) ( HChar* dest, const HChar* src ) function copies the string pointed
to by src, including the null terminator ('\0'), to the buffer pointed to by dest.
Bart Van Assche [Wed, 12 Mar 2014 14:27:49 +0000 (14:27 +0000)]
drd: Fix an assertion failure in the internal consistency check code (#332055)
When DRD is built with ENABLE_DRD_CONSISTENCY_CHECKS enabled it fails with an assert on platforms where VG_STACK_REDZONE_SZB is #define'd as 0 (for example on 32-bit x86). drd: drd_thread.h:299 (vgDrd_thread_set_stack_min): Assertion 'DRD_(g_threadinfo)[tid].stack_min < DRD_(g_threadinfo)[tid].stack_max || DRD_(g_threadinfo)[tid].stack_max == 0' failed. ==12392== at 0x380227CD: report_and_quit (m_libcassert.c:279) ==12392== by 0x38022979: vgPlain_assert_fail (m_libcassert.c:359) ==12392== by 0x38015B29: drd_post_thread_create (drd_thread.h:297) ==12392== by 0x380A5DDC: run_a_thread_NORETURN (syswrap-linux.c) This is because on drd_post_thread_create() call is made to: drd_start_using_mem_stack2(drd_created, stack_max, 0); and in drd_start_using_mem_stack2() calls is made to: DRD_(thread_set_stack_min)(tid, a - VG_STACK_REDZONE_SZB); For many platforms VG_STACK_REDZONE_SZB is #define'd as 0 so that stack_min == stack_max in DRD_(thread_set_stack_min)(). I think it is safe to change the assert from (stack_min < stack_max) to (stack_min <= stack_max).
Julian Seward [Sun, 9 Mar 2014 09:46:04 +0000 (09:46 +0000)]
Supporting macros for function intercept and wrapping on arm64:
* implement VALGRIND_ALIGN_STACK, VALGRIND_RESTORE_STACK
* preserve r30(LR) across the hidden call, so as to avoid segfaulting later
projects / thirdparty / valgrind.git / log
