+38 ../sysdeps/unix/sysv/linux/_exit.c: No such file or directory.
This should make nlgone_exit work on s390 suse and x86_64 suse
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13913
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13912
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13910
stacktrace for the last program instruction encountered with
--vgdb-stop-at=exit
These are not needed anymore, as these lines are now removed
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13907
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/....
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13906
* 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).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13905
See comments in MC_(helperc_STOREV8) for a detailed explanation.
On modern cpu, this gives a few percent speed improvement for
some perf tests, and reduces the nr of undistinguished secondary
map.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13904
* Implement VG_(am_is_valid_for_valgrind)
* Use it in gdbsrv to check accessibility when hostvisibility is activated
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13903
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).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13901
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13900
* 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)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13898
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).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13897
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13896
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13894
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13891
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
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13884
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13883
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13880
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).
From: Ivo Raisr <ivosh@ivosh.net>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13870
