valgrind + llvm10

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

valgrind + llvm10

Martijn van Duren-7
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"

Compiling valgrind with CC=gcc gives the same result, so my guess is
that the linker does something unexpected.

martijn@

Reply | Threaded
Open this post in threaded view
|

Re: valgrind + llvm10

Masato Asou
Hi,

From: Martijn van Duren <[hidden email]>
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

Reply | Threaded
Open this post in threaded view
|

Re: valgrind + llvm10

Martijn van Duren-7
On Mon, 2020-09-14 at 18:12 +0900, Masato Asou wrote:

> Hi,
>
> From: Martijn van Duren <[hidden email]>
> 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.


Reply | Threaded
Open this post in threaded view
|

Re: valgrind + llvm10

Masato Asou
From: Martijn van Duren <[hidden email]>
Date: Mon, 14 Sep 2020 11:42:20 +0200

> On Mon, 2020-09-14 at 18:12 +0900, Masato Asou wrote:
>> Hi,
>>
>> From: Martijn van Duren <[hidden email]>
>> 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.
>
>

I have no problems in my environments as below:

$ cat test.c
int
main(int argc, char *argv[])
{
}

$ cc test.c
$ valgrind ./a.out
==67657== Memcheck, a memory error detector
==67657== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==67657== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==67657== Command: ./a.out
==67657==
==67657== Use of uninitialised value of size 8
==67657==    at 0x4A5D250: _thread_finalize (stdlib/atexit.c:131)
==67657==    by 0x4A5D250: __cxa_finalize (stdlib/atexit.c:153)
==67657==    by 0x4ADD690: exit (stdlib/exit.c:54)
==67657==    by 0x109747: ___start (in ./a.out)
==67657==
==67657==
==67657== FILE DESCRIPTORS: 3 open at exit.
==67657== Open file descriptor 2:
==67657==    <inherited from parent>
==67657==
==67657== Open file descriptor 1:
==67657==    <inherited from parent>
==67657==
==67657== Open file descriptor 0:
==67657==    <inherited from parent>
==67657==
==67657==
==67657== HEAP SUMMARY:
==67657==     in use at exit: 0 bytes in 0 blocks
==67657==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==67657==
==67657== All heap blocks were freed -- no leaks are possible
==67657==
==67657== For counts of detected and suppressed errors, rerun with: -v
==67657== Use --track-origins=yes to see where uninitialised values come from
==67657== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
$ gcc test.c
$ valgrind ./a.out
==46705== Memcheck, a memory error detector
==46705== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==46705== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==46705== Command: ./a.out
==46705==
==46705== Use of uninitialised value of size 8
==46705==    at 0x4A5D250: _thread_finalize (stdlib/atexit.c:131)
==46705==    by 0x4A5D250: __cxa_finalize (stdlib/atexit.c:153)
==46705==    by 0x4ADD690: exit (stdlib/exit.c:54)
==46705==    by 0x109747: ___start (in ./a.out)
==46705==
==46705==
==46705== FILE DESCRIPTORS: 3 open at exit.
==46705== Open file descriptor 2:
==46705==    <inherited from parent>
==46705==
==46705== Open file descriptor 1:
==46705==    <inherited from parent>
==46705==
==46705== Open file descriptor 0:
==46705==    <inherited from parent>
==46705==
==46705==
==46705== HEAP SUMMARY:
==46705==     in use at exit: 0 bytes in 0 blocks
==46705==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==46705==
==46705== All heap blocks were freed -- no leaks are possible
==46705==
==46705== For counts of detected and suppressed errors, rerun with: -v
==46705== Use --track-origins=yes to see where uninitialised values come from
==46705== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
$

Could you show me your source tree
/usr/ports/pobj/valgrind-3.10.1/valgrind-3.10.1 at google drive, etc?
--
ASOU Masato