The mmap'd max/curr and max/curr nr of bytes will be shown e.g. as
11,440,408/ 4,508,968
instead of
11440656/ 4509200
So, using more space, but more readable (in particular when the
nr exceeds the width, and so are not aligned anymore)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15208
This allows to attach to Valgrind when VAlgrind is blocked in a syscall
and have GDB producing a stacktrace, rather than being unable
to unwind.
I.e. instead of having:
(gdb) bt
#0 0x380460f2 in do_syscall_WRK ()
(gdb)
with the directives, we obtain:
(gdb) bt
#0 vgPlain_mk_SysRes_x86_linux (val=1) at m_syscall.c:65
#1 vgPlain_do_syscall (sysno=168, a1=944907996, a2=1, a3=4294967295, a4=0, a5=0, a6=0, a7=0, a8=0) at m_syscall.c:791
#2 0x38031986 in vgPlain_poll (fds=0x385226dc <remote_desc_pollfdread_activity>, nfds=1, timeout=-1) at m_libcfile.c:535
#3 0x3807479f in vgPlain_poll_no_eintr (fds=0x385226dc <remote_desc_pollfdread_activity>, nfds=1, timeout=-1)
at m_gdbserver/remote-utils.c:86
#4 0x380752f0 in readchar (single=4096) at m_gdbserver/remote-utils.c:938
#5 0x38075ae3 in getpkt (buf=0x61f35020 "") at m_gdbserver/remote-utils.c:997
#6 0x38076fcb in server_main () at m_gdbserver/server.c:1048
#7 0x38072af2 in call_gdbserver (tid=1, reason=init_reason) at m_gdbserver/m_gdbserver.c:721
#8 0x380735ba in vgPlain_gdbserver (tid=1) at m_gdbserver/m_gdbserver.c:788
#9 0x3802c6ef in do_actions_on_error (allow_db_attach=<optimized out>, err=<optimized out>) at m_errormgr.c:532
#10 pp_Error (err=0x61f580e0, allow_db_attach=1 '\001', xml=1 '\001') at m_errormgr.c:644
#11 0x3802cc34 in vgPlain_maybe_record_error (tid=1643479264, ekind=8, a=2271560481, s=0x0, extra=0x62937f1c)
at m_errormgr.c:851
#12 0x38028821 in vgMemCheck_record_free_error (tid=1, a=2271560481) at mc_errors.c:836
#13 0x38007b65 in vgMemCheck_free (tid=1, p=0x87654321) at mc_malloc_wrappers.c:496
#14 0x3807e261 in do_client_request (tid=1) at m_scheduler/scheduler.c:1840
#15 vgPlain_scheduler (tid=1) at m_scheduler/scheduler.c:1406
#16 0x3808b6b2 in thread_wrapper (tidW=<optimized out>) at m_syswrap/syswrap-linux.c:102
#17 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:155
#18 0x00000000 in ?? ()
(gdb)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15194
Update ifdefs around the bogus-LR-value-handling code to allow ppc64le to
behave as ppc64 (BE) does.
This fixes the overlap test case, where the stack unwinding code was
otherwise coming up with bad instruction pointers.
This patch fixes Vagrind bugzilla 347322.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15183
Here's why:
The condition
if (VG_(brk_limit) > VG_(brk_base)) line 1223
is reachable iff
newbrk < VG_(brk_base) on line 1201 is false AND
newbrk < VG_(brk_limit) on line 1205 is true
Rewrite as
newbrk >= VG_(brk_base) is true AND
newbrk < VG_(brk_limit) is true
Rewrite as
newbrk >= VG_(brk_base) is true AND
newbrk <= VG_(brk_limit) - 1 is true
Combine
VG_(brk_base) <= newbrk <= VG_(brk_limit) - 1
Therefore
VG_(brk_base) <= VG_(brk_limit) - 1
Or
VG_(brk_base) < VG_(brk_limit)
Which is the same as
VG_(brk_limit) > VG_(brk_base)
qed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15181
while this nr is in fact the total anonymously mmap-ed.
Change the message so as to reflect the shown number.
* Show also the total anonymous mmaped in non OOM memory statistics
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15177
when the size is known in advance.
3 places identified where this function can be used trivially.
The result is a reduction of 'realloc' operations in core
arena, and a small reduction in ttaux arena
(it is the nr of operations that decreases, the memory usage itself
stays the same (ignoring some 'rounding' effects).
E.g. for perf/bigcode 0, we change from
core 1085742/ 216745904 totalloc-blocks/bytes, 1085733 searches
ttaux 5348/ 6732560 totalloc-blocks/bytes, 5326 searches
to
core 712666/ 190998592 totalloc-blocks/bytes, 712657 searches
ttaux 5319/ 6731808 totalloc-blocks/bytes, 5296 searches
For bz2, we switch from
core 50285/ 32383664 totalloc-blocks/bytes, 50256 searches
ttaux 670/ 245160 totalloc-blocks/bytes, 669 searches
to
core 32564/ 29971984 totalloc-blocks/bytes, 32535 searches
ttaux 605/ 243280 totalloc-blocks/bytes, 604 searches
Performance wise, on amd64, this improves memcheck performance
on perf tests by 0.0, 0.1 or 0.2 seconds depending on the test.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15173
evaluation starts. For DW_CFA_val_expression and DW_CFA_expression
doing so is correct, but not for DW_CFA_def_cfa_expression.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15160
Also fix the alignment check which should be mod 16 not mod 8.
Well, actually, it should be mod LibVEX_GUEST_STATE_ALIGN but
that is another patch.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15147
What this does is to make sure that the initial client data segment
is marked as unaddressable. This is consistent with the behaviour of
brk when the data segment is shrunk. The "freed" memory is marked
as unaddressable.
Special tweaks were needed for s390 which was returning early from
the funtion to avoid sloppy register definedness initialisation.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15144
adler32 is not very good as a hash function.
sdbm_hash gives more different keys that adler32,
and in a large majority of the cases, shorter chains.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15142
The VG_(extend_stack) call needs to be properly guarded because the
passed-in address is not necessarily part of an extensible stack
segment. And an extensible stack segment is the only thing that
function should have to deal with.
Previously, the function VG_(am_addr_is_in_extensible_client_stack)
was introduced to guard VG_(extend_stack) but it was not added in all
places it should have been.
Also, extending the client stack during signal delivery (in sigframe-common.c)
was simply calling VG_(extend_stack) hoping it would do the right thing.
But that was not always the case. The new testcase
none/tests/linux/pthread-stack.c exercises this (3.10.1 errors out on it).
Renamed ML_(sf_extend_stack) to ML_(sf_maybe_extend_stack) and add
proper guard logic for VG_(extend_stack).
Testcases none/tests/{amd64|x86}-linux/bug345887.c by Ivo Raisr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15138
Mark 2 additional syscalls as 'mayblock' when fuse-compatible hint
is given.
Patch from aozgovde@ralota.com
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15112
one for Darwin. Down from 11.
Carve out a new function 'track_frame_memory' that communicates to the
tool the allocation of a new stack frame. This was slightly different on
Linux and Darwin but should be the same on both platforms.
New files: priv_sigframe.h and sigframe-common.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15109
LibVEX_GuestPPC64_get_CR() and LibVEX_GuestPPC64_get_XER().
The bugzilla for this issue is 346267.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15101
