With clang 13 none/tests/amd64/amd64locked fails because of what
looks like a clang optimization error. do_bt_G_E_tests is the
point of failure, and one factor is that clang 13 is inlining
myrandom().
These concern auxv, swapoff and fcntl F_KINFO
I wanted to use the new fcntl K_INFO to replace the existing
horrible implementation of resolve_filename, but it seems to
have change the behaviour for redirected files. Several
fdleak regtests fail because stdout resolves to an empty
string.
In glibc 5aad5f617892e75d91d4c8fb7594ff35b610c042 (first released in
v2.28) a call to strncmp was added to dl-load.c:is_dst. This causes
valgrind to complain about glibc's highly-optimised strncmp performing
sixteen-byte reads on short strings in ld.so. Let's intercept strncmp in
ld.so too so we use valgrind's simple version to avoid this problem.
I've made these changes only for FreeBSD and Solaris for the moment.
I don't know what should be done on Linux for aligned_alloc/memalign.
The current Valgrind code refects the glibc implementation, but not
what the documentation says.
The difference is in the si_code. Linux has a value of 0, FreeBSD has
65537. This is correct.
From vki-freebsd.h
/*
* si_code values
*/
and indeed this signal gets sent by kill()
I'm not sure when this output changed.
This expected differs from the main GCC expected due to clang emitting
a cmovne for the ternary expression in 'use':
fprintf(stderr, "%d: Invalid value is %s\n", index, invalid ? "true" : "false");
Was getting warnings with clang like
memalign2.c:62:17: warning: requested alignment is not a power of 2 [-Wnon-power-of-two-alignment]
p = memalign(0, 100); assert(0 == (long)p % 8);
memfd_secret is a new syscall in linux 5.14. memfd_secret() is
disabled by default and a command-line option needs to be added to
enable it at boot time.
$ cat /proc/cmdline
[...] secretmem.enable=y
https://bugs.kde.org/451878https://lwn.net/Articles/865256/
It fixes a known iusse whose details are described at [1] and more
generally it guarantees that Valgrind is properly compiled for ulibc.
[1] https://www.mail-archive.com/valgrind-users@lists.sourceforge.net/msg05295.html
Suggested-by Michael Trimarchi <michael@amarulasolutions.com>
Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
FreeBSD (and Darwin) use the carry flag for syscall syscall status.
That means that in the assembler for do_syscall_for_client_WRK
they have a call to LibVEX_GuestAMD64_put_rflag_c (amd64) or
LibVEX_GuestX86_put_eflag_c (x86). These also call WRK functions.
The problem is that do_syscall_for_client_WRK has carefully crafted
labels correspinding to IP addresses. If a signal interrupts
processdings, IP can be compared to these addresses so that
VG_(fixup_guest_state_after_syscall_interrupted) can work
out how to resume the syscall. But if IP is in the save
carry flag functions, the address is not recognized and
VG_(fixup_guest_state_after_syscall_interrupted) fails.
The crash in the title happens because the interrupted
syscall does not reset its status, and on the next syscall
it is expected that the status be idle.
To fix this I added global variables that get set to 1
just before calling the save carry flag functions, and cleared
just after. VG_(fixup_guest_state_after_syscall_interrupted)
can then check this and work out which section we are in
and resume the syscall correctly.
Also:
Start a new NEWS section for 3.20
Add a regtest for this and also a similar one for Bug 445032
(x86-freebsd only, new subdir).
I saw that this problem also probably exists with macOS, so I made
the same changes there (not yet tested)
commit 7b5867b1f "helgrind reports false races for printfs using
mempcpy on FILE* state" extended the helgrind-glibc-io-xsputn
suppression by also covering mempcpy (instead of __GI_mempcpy).
The test added in that commit exposed a couple of other variants
of this suppression where _IO_*xsputn* called memcpy (instead of
mempcpy) and/or had an extra indirection/function in between.
Replace the two two suppressions with one that covers all cases
where _IO_*xsputn* *mem*cpy variants with possibly another ...
function in between.
https://bugs.kde.org/show_bug.cgi?id=450962
Found this by testing the Solaris execx (the bits that are
Linux-cmpatible) test. That was giving
--28286-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--28286-- si_code=2; Faulting address: 0x4A0095A; sp: 0x1002ca9c88
valgrind: the 'impossible' happened:
Killed by fatal signal
host stacktrace:
==28286== at 0x5803DE54: vgPlain_strcpy (m_libcbase.c:309)
==28286== by 0x5810A9B3: vgSysWrap_linux_sys_execveat_before (syswrap-linux.c:13310)
==28286== by 0x580953C9: vgPlain_client_syscall (syswrap-main.c:2234)
It's a mistake to copy the path obtained with VG_(resolve_filename) to
the client ARG2, it's unlikely to have space for the path.
Instead just copy the pointer.
We already have a suppression for helgrind which is for when glibc
uses __GI_mempcpy to manipulate internal FILE state (this was bug
352130). But since glibc-2.26 mempcpy is used instead __GI_mempcpy,
making the suppresion from the original bug obsolete.
This patch adds a new suppression using mempcpy but doesn't replace
the original suppression for older systems.
Patch adding suppression + testcase by Jesus Checa <jcheca@redhat.com>
https://bugs.kde.org/show_bug.cgi?id=450962
ht_sigchld_ignore and ht_ignore_node were defined in pub_core_signals.h
which cannot include any other tool header.
...checking header files and include directives
*** File coregrind/pub_core_signals.h must not include pub_tool_hashtable.h
So move the definition and type to pub_tool_signals.h
The paths to these files need to be fully specified in
the out of tree build case. glibc-2.X.supp is a generated file so the
full path is deliberately not specified in that case.
Also adjust the mpi include dir location as valgrind.h is
generated as well and needs to be taken out of build dir.
Also adjust the location of generated xml file. And the search paths
for the xmllint, xsltproc and xmlto programs.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Valgrind fork+execs debuginfod-find in order to perform debuginfod
queries. Any SIGCHLD debuginfod-find sends upon termination can
mistakenly be delivered to the client running under valgrind.
To prevent this, record in a hash table the PID of each process
valgrind forks for internal use. Do not send SIGCHLD to the client
if it is from a PID in this hash table.
https://bugs.kde.org/show_bug.cgi?id=445011
We haven't ran auxprogs/change-copyright-year since we switched to git.
This means most Copyright year ranges still say 2017. The script also
doesn't work for years >= 2020. Instead of trying to figure out how to
correctly update the per file Copyright year ranges just update the
main copyright notice that the program outputs on startup.
Currently, syscall memfd_create was tested by this:
$ perl tests/vg_regtest memcheck/tests/linux/memfd.vgtest
Since memfd_secret introduced in kernel 5.14, valgrind should rename
the "memfd" test to "memfd_create" test to avoid the ambiguity, so that
user will not get confused with the "memfd_secret" test.
After this change, syscall memfd_create will be tested by:
$ perl tests/vg_regtest memcheck/tests/linux/memfd_create.vgtest
For execve valgrind would silently fail when argv was NULL or
unadressable. Make sure that this produces a warning under memcheck.
The linux kernel accepts argv[0] being NULL, but most other kernels
don't since posix says it should be non-NULL and it causes argc to
be zero which is unexpected and might cause security issues.
This adjusts some testcases so they don't rely on execve succeeding
when argv is NULL and expect warnings about argv or argv[0] being
NULL or unaddressable.
https://bugs.kde.org/show_bug.cgi?id=450437
