On Mon, 2020-09-14 at 18:12 +0900, Masato Asou wrote:
> Hi,
>
> From: Martijn van Duren <openbsd+po...@list.imperialat.at>
> Date: Mon, 14 Sep 2020 10:43:28 +0200
>
> > I did some bisecting and it seems that the update to clang 10 broke
> > valgrind. Specifically /usr/local/lib/valgrind/memcheck-amd64-openbsd:
> >
> > $ ktrace -i /usr/local/lib/valgrind/memcheck-amd64-openbsd
> > Abort trap
> > $ kdump
> > 12913 ktrace RET ktrace 0
> > 12913 ktrace CALL execve(0x7f7ffffc6fca,0x7f7ffffc6e68,0x7f7ffffc6e78)
> > 12913 ktrace NAMI "/usr/local/lib/valgrind/memcheck-amd64-openbsd"
> > 12913 ktrace ARGS
> > [0] = "/usr/local/lib/valgrind/memcheck-amd64-openbsd"
>
> Now, I am debugging this problem.
>
> > Compiling valgrind with CC=gcc gives the same result, so my guess is
> > that the linker does something unexpected.
>
> Your guess is correct.
>
> Anyway, the following changes seems to work correctly.
> I will report the patch to this mailing list in the next few days.
>
> --- a/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in
> +++ b/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in
> @@ -10,7 +10,7 @@
> +# strip command rewrite offset and align in ELF file. Therefor, when
> valgrind
> +# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system
> +# call.
> -+my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x
> -Wl,-T,$temp", $textbase;
> ++my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x",
> $textbase;
>
> # Add the rest of the parameters
> foreach my $n (2 .. $#ARGV) {
> --
> ASOU Masato
>
Thanks, that gets us a bit further, but it still crashes:
$ cat test.c
int
main(int argc, char *argv[])
{
}
$ make test && valgrind ./test
`test' is up to date.
==57402== Memcheck, a memory error detector
==57402== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==57402== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==57402== Command: ./test
==57402==
==57402==
==57402== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==57402== Access not within mapped region at address 0x8016A00
==57402== at 0x4A680CB: __amd64_read_tcb (in /usr/lib/libc.so.96.0)
==57402== by 0x4A6803D: _thread_finalize (in /usr/lib/libc.so.96.0)
==57402== by 0x4A68120: __cxa_finalize (in /usr/lib/libc.so.96.0)
==57402== by 0x4AF2BF3: exit (in /usr/lib/libc.so.96.0)
==57402== by 0x109747: ___start (in ./test)
==57402== If you believe this happened as a result of a stack
==57402== overflow in your program's main thread (unlikely but
==57402== possible), you can try to increase the size of the
==57402== main thread stack using the --main-stacksize= flag.
==57402== The main thread stack size used in this run was 4194304.
valgrind: m_coredump/coredump-elf.c:816 (void make_elf_coredump(ThreadId, const
vki_siginfo_t *, ULong)): Assertion 'VG_(lseek)(core_fd, phdrs[idx].p_offset,
VKI_SEEK_SET) == phdrs[idx].p_offset'
failed.
host stacktrace:
==57402== at 0x3804BA6C: ???
==57402== by 0x802A9AFDF: ???
==57402== by 0x38069590: ???
==57402== by 0x3804BA6B: ???
==57402== by 0x802A99FAF: ???
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==57402== at 0x4A680CB: __amd64_read_tcb (in /usr/lib/libc.so.96.0)
==57402== by 0x4A6803D: _thread_finalize (in /usr/lib/libc.so.96.0)
==57402== by 0x4A68120: __cxa_finalize (in /usr/lib/libc.so.96.0)
==57402== by 0x4AF2BF3: exit (in /usr/lib/libc.so.96.0)
==57402== by 0x109747: ___start (in ./test)
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
