valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Error when analysing pthreads code?

[EML <sa2...@cy...>]

The program below creates two threads, in a detached state, and waits 
for them to complete with 'pthread_exit'. Compile and run as:

 > gcc -lpthread test.c
 > valgrind --leak-check=full a.out

valgrind-3.13.0 (compiled from source) reports no errors on some runs, 
and a possible leak on other runs (560 bytes in 1 blocks), fairly 
randomly. On my system, the ratio of error-free to bad runs is about 50/50.

Is this is a problem with valgrind, or my use of pthreads? *Note that 
this isn't the standard 'pthread_create' memory leak with joinable 
threads which haven't been joined, since the threads are detached.* I'm 
compiling on Centos 6.9, gcc 4.4.7. Thanks.

------------------------------------------------------------------------
#include <stdlib.h>
#include <stdio.h>
#include <pthread.h>

void *thread(void *data) {
    printf("in new thread %ld\n", (long)data);
}

int main() {
    pthread_t      thread_id[2];
    pthread_attr_t thread_attr;
    int failed = 1;

    do {
       if(pthread_attr_init(&thread_attr))
          break;
       if(pthread_attr_setdetachstate(&thread_attr, 
PTHREAD_CREATE_DETACHED))
          break;
       if(pthread_create(&thread_id[0], &thread_attr, thread, (void*)0))
          break;
       if(pthread_create(&thread_id[1], &thread_attr, thread, (void*)1))
          break;
       failed = 0;
    } while(0);

    if(failed) {
       printf("pthreads call failed\n");
       exit(1);
    }

    pthread_exit(0);
}
------------------------------------------------------------------------

Re: [Valgrind-users] Valgrind's support for copy-stack coroutine

[Remus C. <rem...@gm...>]

Thank you very much, John.

It is my fault. I will prepare the test cases and submit the detailed
report as soon as possible.

All best

Remus

On Mon, Jun 25, 2018 at 11:36 AM, John Reiser <jr...@bi...> wrote:

> On 06/23/2018, Remus Clearwater wrote:
>
> I tried to use valgrind's memcheck on a C copy-stack coroutine program,
>> and got many false positive reports about the invalid write/read on the
>> shared stack when memcpy occurred.
>>
>> (I already used the VALGRIND_STACK_REGISTER/VALGRIND_STACK_DEREGISTER.)
>>
>> Valgrind works fine when I use valgrind on a standalone stack coroutine
>> program.
>>
>> So, the question is:
>>
>> Does valgrind support copy-stack coroutine yet?
>>
>
> The errors that you saw when you tried it, say that valgrind does not yet
> support it.
> By the way, which version of valgrind?  Which hardware?  Which compiler(s)?
> Which C run-time library?  And what was the exact text of the first
> relevant
> complaint from memcheck?
>
> The surest way to make progress is to submit a New bug report at
>    https://bugs.kde.org/buglist.cgi?quicksearch=valgrind
> and attach two test cases with actual code: one with "standalone stack
> co-routine",
> and one with "copy-stack co-routine".  Supplying actual code, and the
> recipe
> to build executables from it, is vital.  If the behavior that you saw
> cannot be reproduced by a valgrind developer, then it is likely to be
> a long time before anything gets fixed.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Valgrind's support for copy-stack coroutine

[John R. <jr...@bi...>]

On 06/23/2018, Remus Clearwater wrote:

> I tried to use valgrind's memcheck on a C copy-stack coroutine program, and got many false positive reports about the invalid write/read on the shared stack when memcpy occurred.
> 
> (I already used the VALGRIND_STACK_REGISTER/VALGRIND_STACK_DEREGISTER.)
> 
> Valgrind works fine when I use valgrind on a standalone stack coroutine program.
> 
> So, the question is:
> 
> Does valgrind support copy-stack coroutine yet?

The errors that you saw when you tried it, say that valgrind does not yet support it.
By the way, which version of valgrind?  Which hardware?  Which compiler(s)?
Which C run-time library?  And what was the exact text of the first relevant
complaint from memcheck?

The surest way to make progress is to submit a New bug report at
    https://bugs.kde.org/buglist.cgi?quicksearch=valgrind
and attach two test cases with actual code: one with "standalone stack co-routine",
and one with "copy-stack co-routine".  Supplying actual code, and the recipe
to build executables from it, is vital.  If the behavior that you saw
cannot be reproduced by a valgrind developer, then it is likely to be
a long time before anything gets fixed.

[Valgrind-users] Valgrind's support for copy-stack coroutine

[Remus C. <rem...@gm...>]

Hi,

I tried to use valgrind's memcheck on a C copy-stack coroutine program, and
got many false positive reports about the invalid write/read on the shared
stack when memcpy occurred.

(I already used the VALGRIND_STACK_REGISTER/VALGRIND_STACK_DEREGISTER.)

Valgrind works fine when I use valgrind on a standalone stack coroutine
program.

So, the question is:

Does valgrind support copy-stack coroutine yet?

Thank you very much.

All best

Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?

[Alan C. <ala...@gm...>]

I don't really know, I'm not much of a Github user, especially now
that Microsoft's buying them.  But the forks aren't much better than
imposters if you're looking for the original.  They may contribute to
the parent project or not.  I wouldn't expect anybody to mimic
valgrind.org, so a clear link there endorsing one of the forks as the
real thing would be good.  I'd mostly rather have well-tested releases
than bleeding edge.  Usually when I get something from github I get
the master.zip if possible.

This did the trick though, runs fine so far on this arm64 Pi.  I also
have a Rock64 which it should work on.  I like these little arm boxes,
and my i386 machines are all 10+ years old by now

On 6/18/18, Ivo Raisr <iv...@iv...> wrote:
> Il giorno lun 18 giu 2018 alle ore 15:57 Alan Corey
> <ala...@gm...> ha scritto:
>>
>> Um, dumb question probably but you checked it in where?  Looks like
>> there are at least 4 forks of Valgrind on Github, on sourceware.org I
>> just see releases, nothing since 3.13.
>
> In addition to Tom's answer: I found at least 20 of such forks on
> github recently active (this year).
> But none claims to be the master one; all reference master repo at
> sourceware.org.
>
> Where would you expect information about master Valgrind repo?
> sourceware.org? valgrind.org?
> I.
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?

[Ivo R. <iv...@iv...>]

Il giorno lun 18 giu 2018 alle ore 15:57 Alan Corey
<ala...@gm...> ha scritto:
>
> Um, dumb question probably but you checked it in where?  Looks like
> there are at least 4 forks of Valgrind on Github, on sourceware.org I
> just see releases, nothing since 3.13.

In addition to Tom's answer: I found at least 20 of such forks on
github recently active (this year).
But none claims to be the master one; all reference master repo at
sourceware.org.

Where would you expect information about master Valgrind repo?
sourceware.org? valgrind.org?
I.

Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?

[Tom H. <to...@co...>]

The sourceware git repo is the canonical one:

https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=summary

Tom

On 18/06/18 14:56, Alan Corey wrote:
> Um, dumb question probably but you checked it in where?  Looks like
> there are at least 4 forks of Valgrind on Github, on sourceware.org I
> just see releases, nothing since 3.13.
> 
> On 6/18/18, Mark Wielaard <ma...@kl...> wrote:
>> On Sat, 2018-06-16 at 21:30 -0400, Alan Corey wrote:
>>> OK, thanks, I ran Valgrind 3.13.0 on a 32-bit Raspberry Pi and it
>>> worked fine.  Found bugs anyway.  KDE and Fedora are way off my beaten
>>> path.  Oh, I see even Raspbian Stretch finally got 3.13, they had one
>>> that didn't do arm at all.
>>
>> For now I checked in the workaround so that valgrind from git trunk
>> should work on your arm64 environment. I kept the bug open since it
>> needs someone with a bit more arm64 knowledge to properly fix it.
>> https://bugs.kde.org/show_bug.cgi?id=381556
>>
>> Cheers,
>>
>> Mark
>>
> 
> 


-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?

[Alan C. <ala...@gm...>]

Um, dumb question probably but you checked it in where?  Looks like
there are at least 4 forks of Valgrind on Github, on sourceware.org I
just see releases, nothing since 3.13.

On 6/18/18, Mark Wielaard <ma...@kl...> wrote:
> On Sat, 2018-06-16 at 21:30 -0400, Alan Corey wrote:
>> OK, thanks, I ran Valgrind 3.13.0 on a 32-bit Raspberry Pi and it
>> worked fine.  Found bugs anyway.  KDE and Fedora are way off my beaten
>> path.  Oh, I see even Raspbian Stretch finally got 3.13, they had one
>> that didn't do arm at all.
>
> For now I checked in the workaround so that valgrind from git trunk
> should work on your arm64 environment. I kept the bug open since it
> needs someone with a bit more arm64 knowledge to properly fix it.
> https://bugs.kde.org/show_bug.cgi?id=381556
>
> Cheers,
>
> Mark
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

[Valgrind-users] Valgrind Solaris port - current and future shape

[Ivo R. <iv...@iv...>]

Dear Valgrind'ers,

I have been maintaining the Valgrind Solaris (and partly also illumos)
port for nearly three years,
ensuring it builds and runs on the latest Solaris 11.1, 11.2, 11.3
(and 11.4 until April 2018).
I have been co-developing the port since 2013.
I have had a pleasure to meet and work with many knowledgeable folks
and also met many of you at various conferences and other occasions.
However all things come to an end at some point. And thus with
sadness, I have to announce I am stepping down from the Valgrind
Solaris port maintainer post. I no longer have access to Solaris
development builds and cannot accommodate running Solaris nightly
tests.

That said, if there is an interest from the community, I can help set
up Solaris nightly regression testbed (provided there is hardware
available). I can also offer a limited assistance for Solaris related
problems.

I am still a Valgrind user and contributor, though. Will focus on Linux now.
I.

Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?

[Mark W. <ma...@kl...>]

On Sat, 2018-06-16 at 21:30 -0400, Alan Corey wrote:
> OK, thanks, I ran Valgrind 3.13.0 on a 32-bit Raspberry Pi and it
> worked fine.  Found bugs anyway.  KDE and Fedora are way off my beaten
> path.  Oh, I see even Raspbian Stretch finally got 3.13, they had one
> that didn't do arm at all.

For now I checked in the workaround so that valgrind from git trunk
should work on your arm64 environment. I kept the bug open since it
needs someone with a bit more arm64 knowledge to properly fix it.
https://bugs.kde.org/show_bug.cgi?id=381556

Cheers,

Mark

Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?

[Alan C. <ala...@gm...>]

OK, thanks, I ran Valgrind 3.13.0 on a 32-bit Raspberry Pi and it
worked fine.  Found bugs anyway.  KDE and Fedora are way off my beaten
path.  Oh, I see even Raspbian Stretch finally got 3.13, they had one
that didn't do arm at all.

On 6/16/18, Mark Wielaard <ma...@kl...> wrote:
> On Sat, 2018-06-16 at 19:09 -0400, Alan Corey wrote:
>> > Linux version 4.16.0-2-arm64 (deb...@li...) (gcc
>> version 7.3.0 (Debian 7.3.0-19)) #1 SMP Debian 4.16.12-1 (2018-05-27)
>>
>> The Valgrind was a 3.13.0 that I'd built from the distribution
>> tarball, then I discovered the same version had been added (Debian
>> Unstable) to the standard debs.  I wanted to see Valkyrie so I did a
>> make uninstall and installed Valgrind and Valkyrie from the debs.
>>
>> From before it broke:
>>
>> ==6541== Memcheck, a memory error detector
>> ==6541== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
>> ==6541== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright
>> info
>> ==6541== Command: ./cmpi2
>> ==6541==
>> ARM64 front end: branch_etc
>> disInstr(arm64): unhandled instruction 0xD5380000
>> disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000
>> ==6541== valgrind: Unrecognised instruction at address 0x4014e2c.
>> ==6541==    at 0x4014E2C: init_cpu_features (cpu-features.c:72)
>> ==6541==    by 0x4014E2C: dl_platform_init (dl-machine.h:208)
>> ==6541==    by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231)
>> ==6541==    by 0x40018D3: _dl_start_final (rtld.c:414)
>> ==6541==    by 0x4001B57: _dl_start (rtld.c:523)
>> ==6541==    by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
>> ==6541== Your program just tried to execute an instruction that Valgrind
>> ==6541== did not recognise.  There are two possible reasons for this.
>> ==6541== 1. Your program has a bug and erroneously jumped to a non-code
>> ==6541==    location.  If you are running Memcheck and you just saw a
>> ==6541==    warning about a bad jump, it's probably your program's fault.
>> ==6541== 2. The instruction is legitimate but Valgrind doesn't handle it,
>> ==6541==    i.e. it's Valgrind's fault.  If you think this is the case or
>> ==6541==    you are not sure, please let us know and we'll try to fix it.
>> ==6541== Either way, Valgrind will now raise a SIGILL signal which will
>> ==6541== probably kill your program.
>> ==6541==
>> ==6541== Process terminating with default action of signal 4 (SIGILL):
>> dumping core
>> ==6541==  Illegal opcode at address 0x4014E2C
>> ==6541==    at 0x4014E2C: init_cpu_features (cpu-features.c:72)
>> ==6541==    by 0x4014E2C: dl_platform_init (dl-machine.h:208)
>> ==6541==    by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231)
>> ==6541==    by 0x40018D3: _dl_start_final (rtld.c:414)
>> ==6541==    by 0x4001B57: _dl_start (rtld.c:523)
>> ==6541==    by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
>
> That is https://bugs.kde.org/show_bug.cgi?id=381556
> arm64: Handle feature registers access on 4.11 Linux kernel or later
>
> In Fedora we carry a workaround as mentioned in comment #1:
> https://bugs.kde.org/show_bug.cgi?id=381556#c1
>
> But this really needs someone who knows what the various HWCAP flags
> really mean on arm64 and which ones we should/shouldn't mask to
> indicate what instructions valgrind/VEX emulates.
>
> Cheers,
>
> Mark
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?

[Mark W. <ma...@kl...>]

On Sat, 2018-06-16 at 19:09 -0400, Alan Corey wrote:
> > Linux version 4.16.0-2-arm64 (deb...@li...) (gcc
> version 7.3.0 (Debian 7.3.0-19)) #1 SMP Debian 4.16.12-1 (2018-05-27)
> 
> The Valgrind was a 3.13.0 that I'd built from the distribution
> tarball, then I discovered the same version had been added (Debian
> Unstable) to the standard debs.  I wanted to see Valkyrie so I did a
> make uninstall and installed Valgrind and Valkyrie from the debs.
> 
> From before it broke:
> 
> ==6541== Memcheck, a memory error detector
> ==6541== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==6541== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==6541== Command: ./cmpi2
> ==6541==
> ARM64 front end: branch_etc
> disInstr(arm64): unhandled instruction 0xD5380000
> disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000
> ==6541== valgrind: Unrecognised instruction at address 0x4014e2c.
> ==6541==    at 0x4014E2C: init_cpu_features (cpu-features.c:72)
> ==6541==    by 0x4014E2C: dl_platform_init (dl-machine.h:208)
> ==6541==    by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231)
> ==6541==    by 0x40018D3: _dl_start_final (rtld.c:414)
> ==6541==    by 0x4001B57: _dl_start (rtld.c:523)
> ==6541==    by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
> ==6541== Your program just tried to execute an instruction that Valgrind
> ==6541== did not recognise.  There are two possible reasons for this.
> ==6541== 1. Your program has a bug and erroneously jumped to a non-code
> ==6541==    location.  If you are running Memcheck and you just saw a
> ==6541==    warning about a bad jump, it's probably your program's fault.
> ==6541== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==6541==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==6541==    you are not sure, please let us know and we'll try to fix it.
> ==6541== Either way, Valgrind will now raise a SIGILL signal which will
> ==6541== probably kill your program.
> ==6541==
> ==6541== Process terminating with default action of signal 4 (SIGILL):
> dumping core
> ==6541==  Illegal opcode at address 0x4014E2C
> ==6541==    at 0x4014E2C: init_cpu_features (cpu-features.c:72)
> ==6541==    by 0x4014E2C: dl_platform_init (dl-machine.h:208)
> ==6541==    by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231)
> ==6541==    by 0x40018D3: _dl_start_final (rtld.c:414)
> ==6541==    by 0x4001B57: _dl_start (rtld.c:523)
> ==6541==    by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)

That is https://bugs.kde.org/show_bug.cgi?id=381556
arm64: Handle feature registers access on 4.11 Linux kernel or later
     
In Fedora we carry a workaround as mentioned in comment #1:
https://bugs.kde.org/show_bug.cgi?id=381556#c1

But this really needs someone who knows what the various HWCAP flags
really mean on arm64 and which ones we should/shouldn't mask to
indicate what instructions valgrind/VEX emulates.

Cheers,

Mark

Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?

[Alan C. <ala...@gm...>]

Hmm, I'll check that.  Right now the latest apt-update & upgrade seems
to have broken my USB connection to the camera.  I wanted to check a
subroutine I wrote for a program that works with libghoto.

I'm using:

Linux version 4.16.0-2-arm64 (deb...@li...) (gcc
version 7.3.0 (Debian 7.3.0-19)) #1 SMP Debian 4.16.12-1 (2018-05-27)

The Valgrind was a 3.13.0 that I'd built from the distribution
tarball, then I discovered the same version had been added (Debian
Unstable) to the standard debs.  I wanted to see Valkyrie so I did a
make uninstall and installed Valgrind and Valkyrie from the debs.

>From before it broke:

==6541== Memcheck, a memory error detector
==6541== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6541== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==6541== Command: ./cmpi2
==6541==
ARM64 front end: branch_etc
disInstr(arm64): unhandled instruction 0xD5380000
disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000
==6541== valgrind: Unrecognised instruction at address 0x4014e2c.
==6541==    at 0x4014E2C: init_cpu_features (cpu-features.c:72)
==6541==    by 0x4014E2C: dl_platform_init (dl-machine.h:208)
==6541==    by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231)
==6541==    by 0x40018D3: _dl_start_final (rtld.c:414)
==6541==    by 0x4001B57: _dl_start (rtld.c:523)
==6541==    by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
==6541== Your program just tried to execute an instruction that Valgrind
==6541== did not recognise.  There are two possible reasons for this.
==6541== 1. Your program has a bug and erroneously jumped to a non-code
==6541==    location.  If you are running Memcheck and you just saw a
==6541==    warning about a bad jump, it's probably your program's fault.
==6541== 2. The instruction is legitimate but Valgrind doesn't handle it,
==6541==    i.e. it's Valgrind's fault.  If you think this is the case or
==6541==    you are not sure, please let us know and we'll try to fix it.
==6541== Either way, Valgrind will now raise a SIGILL signal which will
==6541== probably kill your program.
==6541==
==6541== Process terminating with default action of signal 4 (SIGILL):
dumping core
==6541==  Illegal opcode at address 0x4014E2C
==6541==    at 0x4014E2C: init_cpu_features (cpu-features.c:72)
==6541==    by 0x4014E2C: dl_platform_init (dl-machine.h:208)
==6541==    by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231)
==6541==    by 0x40018D3: _dl_start_final (rtld.c:414)
==6541==    by 0x4001B57: _dl_start (rtld.c:523)
==6541==    by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)

valgrind: m_coredump/coredump-elf.c:495 (fill_fpu): Assertion
'Unimplemented functionality' failed.
valgrind: valgrind

host stacktrace:
==6541==    at 0x5803CC70: show_sched_status_wrk (m_libcassert.c:355)
==6541==    by 0x5803CDB3: report_and_quit (m_libcassert.c:426)
==6541==    by 0x5803CF23: vgPlain_assert_fail (m_libcassert.c:492)
==6541==    by 0x5806F783: fill_fpu.isra.4 (coredump-elf.c:495)
==6541==    by 0x5806F98F: dump_one_thread (coredump-elf.c:552)
==6541==    by 0x5806F98F: make_elf_coredump (coredump-elf.c:656)
==6541==    by 0x5806F98F: vgPlain_make_coredump (coredump-elf.c:737)
==6541==    by 0x58055717: default_action (m_signals.c:1914)
==6541==    by 0x58055717: deliver_signal (m_signals.c:1974)
==6541==    by 0x58055DDB: vgPlain_synth_sigill (m_signals.c:2083)
==6541==    by 0x58096BD7: vgPlain_scheduler (scheduler.c:1581)
==6541==    by 0x580A918B: thread_wrapper (syswrap-linux.c:103)
==6541==    by 0x580A918B: run_a_thread_NORETURN (syswrap-linux.c:156)
==6541==    by 0xFFFFFFFFFFFFFFFF: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 6541)
==6541==    at 0x4014E2C: init_cpu_features (cpu-features.c:72)
==6541==    by 0x4014E2C: dl_platform_init (dl-machine.h:208)
==6541==    by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231)
==6541==    by 0x40018D3: _dl_start_final (rtld.c:414)
==6541==    by 0x4001B57: _dl_start (rtld.c:523)
==6541==    by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)


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.



On 6/16/18, Tom Hughes <to...@co...> wrote:
> On 16/06/18 17:49, Alan Corey wrote:
>
>> Maybe a bleeding edge version on Github or somewhere?
>>
>> I'm on a Raspberry Pi 3b in 64 bit mode:
>> Linux version 4.16.0-1-arm64 (deb...@li...) (gcc
>> version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29)
>>
>> I have Valgrind 3.13 I built from a release tarball, it works in 32
>> bit mode but not in 64, it doesn't know the instructions yet.
>
> Well aarch64 is supported in the version you have.
>
> If you have found an instruction it doesn't understand then
> report a bug in the bug tracker.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?

[Tom H. <to...@co...>]

On 16/06/18 17:49, Alan Corey wrote:

> Maybe a bleeding edge version on Github or somewhere?
> 
> I'm on a Raspberry Pi 3b in 64 bit mode:
> Linux version 4.16.0-1-arm64 (deb...@li...) (gcc
> version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29)
> 
> I have Valgrind 3.13 I built from a release tarball, it works in 32
> bit mode but not in 64, it doesn't know the instructions yet.

Well aarch64 is supported in the version you have.

If you have found an instruction it doesn't understand then
report a bug in the bug tracker.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Is there a Valgrind that knows arm64/aarch64?

[Alan C. <ala...@gm...>]

Maybe a bleeding edge version on Github or somewhere?

I'm on a Raspberry Pi 3b in 64 bit mode:
Linux version 4.16.0-1-arm64 (deb...@li...) (gcc
version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29)

I have Valgrind 3.13 I built from a release tarball, it works in 32
bit mode but not in 64, it doesn't know the instructions yet.

-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Valgrind-users] Test suite for instruction semantics

[John R. <jr...@bi...>]

> I was looking for some test suite for testing the instruction semantics of x86-64.

Also known as 'amd64' in honor of the original designers of the 64-bit flavor of x86.

> As Valgrind host the semantics of the ISA and was expecting Valgrind to have a test-suite for the purpose of testing that. But I could not find any.

You did not look effectively:

    VEX/test/*
    none/tests/amd64/*
    */tests/*
    tests/*

Altogether over 1500 files related to testing,
with 233 of them in none/tests/amd64
and several more x86* tests in VEX/test.

[Valgrind-users] Test suite for instruction semantics

[Sandeep D. <sda...@il...>]

Hello Team,

I was looking for some test suite for testing the instruction semantics 
of x86-64. As Valgrind host the semantics of the ISA and was expecting 
Valgrind to have a test-suite for the purpose of testing that. But I 
could not find any.
Can somebody please help me here?


Thanks
Sandeep

[Valgrind-users] Valgrind exits immediately with Java program

[Jessica R. <jr...@te...>]

Hiya folks,

I am hoping to use Valgrind to help me figure out where some mysterious native memory leaks are happening with a server program I have written in Java.  I have found, however, that Valgrind seems to be exiting prematurely.  I wrote a simple test program that simply loops and outputs to the console for 10 seconds, and even with that, Valgrind ends immediately.  Here is my command to run it with Valgrind:

valgrind --trace-children=yes java NewClass

And the following is the output.  Any help or insight would be greatly appreciated!

-Jess



==36360== Memcheck, a memory error detector
==36360== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==36360== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
==36360== Command: java NewClass
==36360== 

valgrind: m_debuginfo/debuginfo.c:452 (void discard_or_archive_DebugInfo(DebugInfo *)): Assertion 'is_DebugInfo_active(di)' failed.

host stacktrace:
==36360==    at 0x2580551AB: ???
==36360==    by 0x25805553C: ???
==36360==    by 0x25805551F: ???
==36360==    by 0x25808CEC3: ???
==36360==    by 0x25808B5CA: ???
==36360==    by 0x25810B68F: ???
==36360==    by 0x2580ECF19: ???
==36360==    by 0x2580EC76A: ???
==36360==    by 0x2580EA8E3: ???
==36360==    by 0x2580E8846: ???
==36360==    by 0x2580FB14E: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 771)
==36360==    at 0x100038476: __mmap (in /usr/lib/dyld)
==36360==    by 0x100037D7F: mmap (in /usr/lib/dyld)
==36360==    by 0x10001E3AA: ImageLoaderMachO::mapSegments(int, unsigned long long, unsigned long long, unsigned long long, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==36360==    by 0x100021BF9: ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, unsigned int, unsigned int, linkedit_data_command const*, encryption_info_command const*, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==36360==    by 0x10001B25F: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==36360==    by 0x10000AB9F: dyld::loadPhase6(int, stat const&, char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==36360==    by 0x1000110DD: dyld::loadPhase5(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==36360==    by 0x100010D19: dyld::loadPhase4(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==36360==    by 0x100010A99: dyld::loadPhase3(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==36360==    by 0x100010267: dyld::loadPhase1(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==36360==    by 0x10000A7FE: dyld::loadPhase0(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==36360==    by 0x10000A4A1: dyld::load(char const*, dyld::LoadContext const&, unsigned int&) (in /usr/lib/dyld)
==36360==    by 0x1000119B2: dyld::libraryLocator(char const*, bool, char const*, ImageLoader::RPathChain const*, unsigned int&) (in /usr/lib/dyld)
==36360==    by 0x1000187F1: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x1000189A8: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x100017B64: ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool, ImageLoader::RPathChain const&, char const*) (in /usr/lib/dyld)
==36360==    by 0x10000BF69: dyld::link(ImageLoader*, bool, bool, ImageLoader::RPathChain const&, unsigned int) (in /usr/lib/dyld)
==36360==    by 0x10000DFE7: dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) (in /usr/lib/dyld)
==36360==    by 0x1000083D3: dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) (in /usr/lib/dyld)
==36360==    by 0x1000081D1: _dyld_start (in /usr/lib/dyld)
==36360==    by 0x1: ???
==36360==    by 0x1048A4A76: ???
==36360==    by 0x1048A4A7B: ???


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.

Re: [Valgrind-users] Counting specific reads and writes

[Philippe W. <phi...@sk...>]

On Tue, 2018-05-29 at 08:49 +0000, Zwinkau Andreas (CC-AD/EYF1) wrote:
> Hi
> 
> We have a bunch of memory arrays which are used as communication queues between components. I want to count how much those queues are actually used by the components by counting the memory accesses. This should be possible with Valgrind, but it the actual tool has not been developed yet as far as I researched. Maybe somewhere something similar was done already?
> 
You might look at exp-dhat or lackey tools, which both
can track memory accesses.

Philippe

[Valgrind-users] Counting specific reads and writes

[Zwinkau A. (CC-AD/EYF1) <And...@de...>]

Hi

We have a bunch of memory arrays which are used as communication queues between components. I want to count how much those queues are actually used by the components by counting the memory accesses. This should be possible with Valgrind, but it the actual tool has not been developed yet as far as I researched. Maybe somewhere something similar was done already?

For clarification a little pseudo code:

int main() {
	vector<int> a = init_a();
	vector<Image> init_b();
         	foo(a, b);
	bar(a, b);
}

void foo (&vector<int> a, &vector<Image> b) {
	for (int i = 0; i < a.length; i+= 10)
                     a[i] = b[i/10].getRed(i);
}

void foo (&vector<int> a, &vector<Image> b) {
	for (int i = 0; i < a.length; i+= 8)
                     if (a[i] == 42)
		b[i%10].setTransparent();
}

The information I would like to get is something like:

Component     Writes a   Reads a    Writes b    Reads b
foo                  243           27              574           235
bar                  833          684             87             3897


The obvious challenges I can see is to identify/mark the components and memory regions.

Mit freundlichen Grüßen / Best regards

Andreas Zwinkau
CC-AD/EYF1

Re: [Valgrind-users] Please leave Sorceforge

[David C. <dcc...@ac...>]

On 5/20/2018 2:49 PM, Mark Wielaard wrote:
> On Sun, May 20, 2018 at 02:44:16PM -0400, Jeffrey Walton wrote:
>> When signing up for the newsletter we have to " I agree to receive
>> these communications from SourceForge.net...." Requiring me to accept
>> spam is very disingenuous.
>>
>> Please leave Sorceforge.
> We could ask the sourceware overseers to take over the mailinglists.
> sourceware used to be very strict about not allowing HTML email.
> But I believe they will now strip such HTML attachments instead of
> just bouncing them. Are others bothered by the current mailinglist
> arrangement? Should we start a discussion about moving to sourceware?
> (sourceware is where our current git repository lives)

I forget whether the Sourceforge newsletter arrives once per month or 
twice per month.  It's rare enough that I don't pay much attention.  I 
really don't think it's a problem.  YMMV.

-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     EDA Software Developer, Expert Witness
     www.chapman-consulting-sj.com
     2018 Chair, IEEE Consultants' Network of Silicon Valley

Re: [Valgrind-users] valgrind "error: -mpreferred-stack-boundary=2 is not between 3 and 12"

[Jeffrey W. <nol...@gm...>]

On Sun, May 20, 2018 at 5:50 PM, Mark Wielaard <ma...@kl...> wrote:
> On Sun, May 20, 2018 at 02:49:21PM -0400, Jeffrey Walton wrote:
>> I'm working on Fedora 27 x86_64 from Master trying to sidestep
>> https://bugs.kde.org/show_bug.cgi?id=387773.
>
> Fixes for that bug should already be in the Fedora 27 valgrind package.
> What issues are you seeing? Are you using the latest valgrind rpm
> version?

-march=native and additional VEX codes pretty much ensures we have to
work from Master. (I tried to get Fedora to pickup some VEX codes that
were added after a release but they declined).

Jeff

Re: [Valgrind-users] valgrind "error: -mpreferred-stack-boundary=2 is not between 3 and 12"

[Jeffrey W. <nol...@gm...>]

On Sun, May 20, 2018 at 5:42 PM, Tom Hughes <to...@co...> wrote:
> On 20/05/18 21:15, John Reiser wrote:
>
>> This is peculiar: "I am working on ... x86_64" but invoking "gcc -m32"
>> which requests "generate code for i686".
>> Also, if the value is not at least 4 then some generated SSE instructions
>> (even on i686) will fault because they demand 16-byte alignment,
>> and any call involving a variable number of arguments which includes
>> any argument that requires 16-byte alignment will generate incorrect code.
>> The best strategy is to omit "-mpreferred-stack-boudnary" entirely.
>
>
> It's not peculiar really - by default when building on x86_64 valgrind
> will try and build both the x86 and x86_64 backends.
>
> Use --enable-only64bit to configure if you want to stop it trying to
> build the 32 bit backend.

Oh, thanks. I did not look at the configuration options closely enough.

Sorry about the extra noise.

Re: [Valgrind-users] valgrind "error: -mpreferred-stack-boundary=2 is not between 3 and 12"

[Tom H. <to...@co...>]

On 20/05/18 21:15, John Reiser wrote:

> This is peculiar: "I am working on ... x86_64" but invoking "gcc -m32"
> which requests "generate code for i686".
> Also, if the value is not at least 4 then some generated SSE instructions
> (even on i686) will fault because they demand 16-byte alignment,
> and any call involving a variable number of arguments which includes
> any argument that requires 16-byte alignment will generate incorrect code.
> The best strategy is to omit "-mpreferred-stack-boudnary" entirely.

It's not peculiar really - by default when building on x86_64 valgrind
will try and build both the x86 and x86_64 backends.

Use --enable-only64bit to configure if you want to stop it trying to
build the 32 bit backend.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] valgrind "error: -mpreferred-stack-boundary=2 is not between 3 and 12"

[Mark W. <ma...@kl...>]

On Sun, May 20, 2018 at 02:49:21PM -0400, Jeffrey Walton wrote:
> I'm working on Fedora 27 x86_64 from Master trying to sidestep
> https://bugs.kde.org/show_bug.cgi?id=387773.

Fixes for that bug should already be in the Fedora 27 valgrind package.
What issues are you seeing? Are you using the latest valgrind rpm
version?

Cheers,

Mark