For fadvise64 system call, 7th 32-bit argument slot (third on the stack)
will also be used due to MIPS O32 calling convention in passing 64-bit
values.
sys_fadvise64(int fd, loff_t offset, loff_t len, int advice);
NR_fadvise64 -> v0 (sysno)
fd -> a0 (ARG1)
offset -> a2, a3 (ARG3, ARG4)
len -> SP + 16, SP + 20 (ARG5, ARG6)
advise -> SP + 24 (ARG7)
Change the code according to it.
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16162
* Use stack arrays instead of malloc/free
* ensure msghdr_foreachfield does one single call to foreach_func
for consecutive fields
* some small code reformatting or factorisation
Tested on linux, hoping it also works on solaris
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16111
Also stop checking when max length of bytes have been reached.
Bug #369359
Found by LTP testcases/kernel/syscalls/recvmsg/recvmsg01.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15991
Don't do any more checks if it isn't safe to inspect the address family.
Likewise, don't check sun_path if the string address isn't safe.
Found by LTP testcases/kernel/syscalls/bind/bind01.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15990
The msg telling brk cannot be extended confuses some users
so improve the documentation and have the msg referencing the doc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15880
We were using some wrong syscall numbers in vki-scnums-arm64-linux.h
arm64 doesn't implement a couple of old deprecated system calls like
rename, dup2, getpgrp and fork. Adjust m_libcfile.c rename and dup2
functions to use renameat (also on tilegx) and dup3 (with fcntl fallback
for bad oldfd). And in m_libcproc.c implement getpgrp as getpgid(0).
Also don't compile the fork syswrap on arm64 (it only supports clone).
In practice this only affected callgrind which was unable to rename
dump files in some cases and ELF core dumps might have contained some
bogus prstatus fields.
Related to bug #359503 - Add missing syscalls for aarch64 (arm64)
Reported by Marcin Juszkiewicz who also posted a nice overview
of system calls on different linux architectures:
https://marcin.juszkiewicz.com.pl/2016/03/05/from-a-diary-of-aarch64-porter-system-calls/
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15824
We used to set the process datasize rlimit to zero to prevent
any internal use of brk() from having any effect. But later
linux kernels redefine RLIMIT_DATA as the size of any data
areas, including some dynamic mmap memory allocations.
See bug #357833 for the commit that went into linux 4.5
changing the definition of RLIMIT_DATA. So don't mess with
RLIMIT_DATA anymore. Just remember it for use in the syscall
wrappers.
This also cleans up some hacks around the execv and spawn wrappers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15766
This is a follow up to r14682:
When an mmap retry is done without any constraints, the kernel can
place it into free or reservation segments (i.e. anywhere there is no
mapping yet).
In r14682 a sanity check made the hypothesis that the new mapping was
in a free segment, but it does not hold at least on Linux 3.12 and 3.16
on amd64 (tested under Debian).
There is no risk in allowing the mapping to end up in (what was
previously) a reservation at this point, because it is also allowed.
Patch by Guillaume Knispel <xilun0@gmail.com>. Fixes BZ #348269.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15538
324181 was previously closed with a solution to always make
MAP_32BIT fail. This is technically correct/according to the doc,
but is not very usable.
This patch ensures that MAP_32BIT mmap is succesful, as long as
aspacemgr gives a range in the first 2GB
(so, compared to a native run, MAP_32BIT will fail much more quickly
as aspacemgr does not reserve the address space below 2GB on a 64 bits).
Far to be perfect, but this is better than nothing.
Added a regression test that test succesful mmap 32 bits till
the 2GB limit is reached.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15341
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
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
- remove redundant asserts
- let VG_(am_extend_into_adjacent_reservation_client) worry about
- whether delta is too large
- whether the segment abutting this one exists and is a reservation
segment
The function already checks these things. No need to do it again here.
- do_brk does not need to know that a reservation segment must not
shrink beyond a single page. That detail ought to be hidden in
the address space manager.
Also, turn a few conditions into asserts.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14967
- Tighten up on asserts
- Simplify; as the function grows memory into a free segment, there
cannot possibly be any translations to be discarded. Free segments
do not have translations. sane_NSegment will make sure.
- Change the prototype to take in the start address of the mapping and
return a pointer to the resized segment. Previously, the code
ok = VG_(am_extend_map_client)( &d, old_seg, needL );
if (!ok)
goto eNOMEM;
VG_TRACK( new_mem_mmap, needA, needL,
old_seg->hasR, old_seg->hasW, old_seg->hasX,
was examining old_seg->hasR etc even though VG_(am_extend_map_client)
stated that *old_seg was invalid after the function returned.
That wasn't exactly a problem, but clearly looked wrong.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14963
arm64, like amd64, must not use VKI_IPC_64, even
if this symbol is defined.
This makes the shmctl fail, which results in a zero size returned,
which means that the succesful shmat is not reported to the aspacemgr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14821
are always false. I'm keeping them as assertions for documentation purposes.
The proof is left as exercise to the reader.
Hint: use conditions on lines 307 and 311 and the fact that old_len and
old_arg are both unsigned entities.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14778
Learning aspacemgr to handle huge page is too difficult.
So, huge page requests that fails due to bad advice by aspacemgr
will (we hope) succeed if a mmap retry is done with the kernel,
without any constraints.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14682
Change VG_(resolve_filename) to not truncate the result which is returned
in a static buffer now. Fix callsites.
Simplify VG_(di_notify_pdb_debuginfo) to use VG_(resolve_filename).
Fix VG_(readlink) prototype.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14628
board (instead of e.g. VG_(arena_malloc)(VG_AR_CORE,...). This change
also benefits static analysers. We can tell tools that VG_(malloc) allocates
and VG_(free) deallocates and that they are a pair. But we cannot do that for
arena_malloc/free.
Also provide a wrapper VG_(realloc_shrink).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14517
At various places, there were either some assumption that the 'end'
boundary (highest address) was either not included, included,
or was the highest addressable word, or the highest addressable byte.
This e.g. was very visible when doing:
./vg-in-place -d -d ./helgrind/tests/tc01_simple_race|&grep regi
giving
--24040:2:stacks register 0xBEDB4000-0xBEDB4FFF as stack 0
--24040:2:stacks register 0x402C000-0x4A2C000 as stack 1
showing that the main stack end was (on x86) not the highest word
but the highest byte, while for the thread 1, the registered end
was a byte not part of the stack.
The attached patch ensures that stack bounds semantic are documented and
consistent. Also, some of the stack handling code is factorised.
The convention that the patch ensures and documents is:
start is the lowest addressable byte, end is the highest addressable byte.
(the words 'min' and 'max' have been kept when already used, as this wording is
consistent with the new semantic of start/end).
In various debug log, used brackets [ and ] to make clear that
both bounds are included.
The code to guess and register the client stack was duplicated
in all the platform specific syswrap-<plat>-<os>.c files.
Code has been factorised in syswrap-generic.c
The patch has been regression tested on
x86, amd64, ppc32/64, s390x.
It has been compiled and one test run on arm64.
Not compiled/not tested on darwin, android, mips32/64, arm
More in details, the patch does the following:
coregrind/pub_core_aspacemgr.h
include/valgrind.h
include/pub_tool_machine.h
coregrind/pub_core_scheduler.h
coregrind/pub_core_stacks.h
- document start/end semantic in various functions
also in pub_tool_machine.h:
- replaces unclear 'bottommost address' by 'lowest address'
(unclear as stack bottom is or at least can be interpreted as
the 'functional' bottom of the stack, which is the highest
address for 'stack growing downwards').
coregrind/pub_core_initimg.h
replace unclear clstack_top by clstack_end
coregrind/m_main.c
updated to clstack_end
coregrind/pub_core_threadstate.h
renamed client_stack_highest_word to client_stack_highest_byte
coregrind/m_scheduler/scheduler.c
computes client_stack_highest_byte as the highest addressable byte
Update comments in call to VG_(show_sched_status)
coregrind/m_machine.c
coregrind/m_stacktrace.c
updated to client_stack_highest_byte, and switched
stack_lowest/highest_word to stack_lowest/highest_byte accordingly
coregrind/m_stacks.c
clarify semantic of start/end,
added a comment to indicate why we invert start/end in register call
(note that the code find_stack_by_addr was already assuming that
end was included as the checks were doing e.g.
sp >= i->start && sp <= i->end
coregrind/pub_core_clientstate.h
coregrind/m_clientstate.c
renames Addr VG_(clstk_base) to Addr VG_(clstk_start_base)
(start to indicate it is the lowest address, base suffix kept
to indicate it is the initial lowest address).
coregrind/m_initimg/initimg-darwin.c
updated to VG_(clstk_start_base)
replace unclear iicii.clstack_top by iicii.clstack_end
updated clstack_max_size computation according to both bounds included.
coregrind/m_initimg/initimg-linux.c
updated to VG_(clstk_start_base)
updated VG_(clstk_end) computation according to both bounds included.
replace unclear iicii.clstack_top by iicii.clstack_end
coregrind/pub_core_aspacemgr.h
extern Addr VG_(am_startup) : clarify semantic of the returned value
coregrind/m_aspacemgr/aspacemgr-linux.c
removed a copy of a comment that was already in pub_core_aspacemgr.h
(avoid double maintenance)
renamed unclear suggested_clstack_top to suggested_clstack_end
(note that here, it looks like suggested_clstack_top was already
the last addressable byte)
* factorisation of the stack guessing and registration causes
mechanical changes in the following files:
coregrind/m_syswrap/syswrap-ppc64-linux.c
coregrind/m_syswrap/syswrap-x86-darwin.c
coregrind/m_syswrap/syswrap-amd64-linux.c
coregrind/m_syswrap/syswrap-arm-linux.c
coregrind/m_syswrap/syswrap-generic.c
coregrind/m_syswrap/syswrap-mips64-linux.c
coregrind/m_syswrap/syswrap-ppc32-linux.c
coregrind/m_syswrap/syswrap-amd64-darwin.c
coregrind/m_syswrap/syswrap-mips32-linux.c
coregrind/m_syswrap/priv_syswrap-generic.h
coregrind/m_syswrap/syswrap-x86-linux.c
coregrind/m_syswrap/syswrap-s390x-linux.c
coregrind/m_syswrap/syswrap-darwin.c
coregrind/m_syswrap/syswrap-arm64-linux.c
Some files to look at more in details:
syswrap-darwin.c : the handling of sysctl(kern.usrstack) looked
buggy to me, and has probably be made correct by the fact that
VG_(clstk_end) is now the last addressable byte. However,unsure
about this, as I could not find any documentation about
sysctl(kern.usrstack). I only find several occurences on the web,
showing that the result of this is page aligned, which I guess
means it must be 1+ the last addressable byte.
syswrap-x86-darwin.c and syswrap-amd64-darwin.c
I suspect the code that was computing client_stack_highest_word
was wrong, and the patch makes it correct.
syswrap-mips64-linux.c
not sure what to do for this code. This is the only code
that was guessing the stack differently from others.
Kept (almost) untouched. To be discussed with mips maintainers.
coregrind/pub_core_libcassert.h
coregrind/m_libcassert.c
* void VG_(show_sched_status):
renamed Bool valgrind_stack_usage to Bool stack_usage
if stack_usage, shows both the valgrind stack usage and
the client stack boundaries
coregrind/m_scheduler/scheduler.c
coregrind/m_gdbserver/server.c
coregrind/m_gdbserver/remote-utils.c
Updated comments in callers to VG_(show_sched_status)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14392
getdents has been deprecated since linux 2.4 and newer arches (arm64)
might no longer provide the getdents syscall. Use getdents64 for reading
the /proc/self/fd/ dir so --track-fds=yes works reliable on all arches.
Without this the none/tests/fdleak*vgtest might fail.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14384
pre_mem_read_sockaddr: in the case where the caller doesn't
specify any address family (that is, the family is AF_UNSPEC)
don't perform any further checks on the supplied |sa| address
block, since doing so merely gives rise to false uninitialised
value errors.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14320
of clo which are (or should be) 'enum set'.
* pub_tool_options.h : add new macrox VG_USET_CLO and VG_USETX_CLO to
parse an 'enum set' command line option (with or without "all" keyword).
* use VG_USET_CLO for existing enum set clo options:
memcheck --errors-for-leak-kinds, --show-leak-kinds, --leak-check-heuristics
coregrind --vgdb-stop-at
* change --sim-hints and --kernel-variants to enum set
(this allows to detect user typos: currently, a typo in a sim-hint
or kernel variant is silently ignored. Now, an error will be given
to the user)
* The 2 new sets (--sim-hints and --kernel-variants) should not make
use of the 'all' keyword => VG_(parse_enum_set) has a new argument
to enable/disable the use of the "all" keyword.
* The macros defining an 'all enum' set definition was duplicating
all enum values (so addition of a new enum value could easily
give a bug). Removing these macros as they are unused
(to the exception of the leak-kind set).
For this set, the 'all macro' has been replaced by an 'all function',
coded using parse_enum_set parsing the "all" keyword.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14301
rather than throwing to the default case. This stops Memcheck
reporting false positives for the NETLINK case.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14237
Some syscall verification code is allocating memory to generate
the string used to build an error, e.g. syswrap-generic.c verifying fields of
e.g socket addresses (pre_mem_read_sockaddr) or sendmsg/recvmsg args
(msghdr_foreachfield)
The allocated pointer was copied in the error created by VG_(maybe_record_error).
This was wrong for 2 reasons:
1. If the error is a new error, it is stored in a list of errors,
but the string memory was freed by pre_mem_read_sockaddr, msghdr_foreachfield, ...
This causes a dangling reference. Was at least visible when giving -v, which
re-prints all errors at the end of execution.
Probably this could have some consequences during run while generating new errors,
and comparing for equality with a recorded error having a dangling reference.
2. the same allocated string is re-used for each piece/field of the verified struct.
The code in mc_errors.c that checks that 2 errors are identical was then wrongly
considereing that 2 successive errors for 2 different fields for the same syscall
arg are identical, just because the error string happened to be produced at
the same address.
(it is believed that initially, the error string was assumed to be a static
string, which is not the case anymore, causing the above 2 problems).
Changes:
* The fix consists in duplicating in m_errormgr.c the given error string when
the error is recorded. In other words, the error string is now duplicated similarly
to the (optional) extra component of the error.
* memcheck/tests/linux/rfcomm.c test modified as now an error is reported
for each uninit field.
* socketaddr unknown family is also better reported (using sa_data field name,
rather than an empty field name.
* minor reformatting in m_errormgr.c, to be below 80 characters.
Some notes:
1. the string is only duplicated if the error is recorded
(ie. printed or the first time an error matches a suppression).
The string is not duplicated for duplicated errors or following errors
matching the first (suppressed) error.
The string is also not duplicated for 'unique errors' (that are printed
and then not recorded).
2. duplicating the string for each recorded error is not deemed to
use a lot of memory:
* error strings are usually NULL or short (often 10 bytes or so).
* we expect no program has a huge number of errors
If ever this string duplicate would be significant, having a DedupPoolAlloc
in m_errormgr.c for these strings would reduce this memory (as we expect to
have very few different strings, even with millions of errors).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14214
Call ML_(safe_to_deref) before using msghdr msg_name, msg_iov or msg_control.
Fixes bug #334705.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13963
