Re: [Valgrind-users] valgrind aarch64 unitialized warnings
Oh, fft_r[] and fft_l[] are similar memory areas from calloc which hold the FFT output data once it's moved from the fft3w output array. I pick left and right channels out of the PCM data and FFT them individually, then plot them separately on the same frame image. On 5/6/21, Alan Corey wrote: > This is under Debian Bullseye Linux on a PineBook Pro so ARM 64-bit I > think although sizeof(int) is still 4. It's a fairly complicated > program at 750 lines in it's almost-done state so I'm not posting the > whole thing. I have this program that does audiograms > https://sourceforge.net/projects/audiogram-c/ and I got the bright > idea of adding FFT plots to the video generated. I read a wav file > into RAM, draw the envelope of the audio. Then move a cursor bar over > it by generating frames at different times, saving as jpegs and > calling ffmpeg at the end to make a video. Originally it was a > work-around for not being able to post audio files to social media > sites. > > The FFT version works with the PCM data in the wav file in memory and > draws more onto the same frames. tmpbuf is a per-frame output drawing > area allocated with calloc and then cleared with bzero but I still get > these uninitialized warnings: > > ==26220== > ==26220== Invalid write of size 1 > ==26220==at 0x402460: plot (agf.c:573) > ==26220==by 0x402B9F: main (agf.c:713) > ==26220== Address 0x4d2b993 is 13 bytes before an unallocated block > of size 3,278,400 in arena "client" > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220==at 0x401504: plotffts (agf.c:301) > ==26220==by 0x401DDF: makeframes (agf.c:442) > ==26220==by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220==by 0x40125B: fft_init (agf.c:173) > ==26220==by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220==at 0x40153C: plotffts (agf.c:303) > ==26220==by 0x401DDF: makeframes (agf.c:442) > ==26220==by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220==by 0x40125B: fft_init (agf.c:173) > ==26220==by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220==at 0x401598: plotffts (agf.c:307) > ==26220==by 0x401DDF: makeframes (agf.c:442) > ==26220==by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220==by 0x40125B: fft_init (agf.c:173) > ==26220==by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220==at 0x4015D0: plotffts (agf.c:309) > ==26220==by 0x401DDF: makeframes (agf.c:442) > ==26220==by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220==by 0x40125B: fft_init (agf.c:173) > ==26220==by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220==at 0x40165C: plotffts (agf.c:315) > ==26220==by 0x401DDF: makeframes (agf.c:442) > ==26220==by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220==by 0x40125B: fft_init (agf.c:173) > ==26220==by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220==at 0x401678: plotffts (agf.c:317) > ==26220==by 0x401DDF: makeframes (agf.c:442) > ==26220==by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220==by 0x40125B: fft_init (agf.c:173) > ==26220==by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Use of uninitialised value of size 8 > ==26220==at 0x4016E0: plotffts (agf.c:328) > ==26220==by 0x401DDF: makeframes (agf.c:442) > ==26220==by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220==by 0x40125B: fft_init (agf.c:173) > ==26220==by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Use of uninitialised value of size 8 > ==26220==at 0x4016F8: plotffts (a
[Valgrind-users] valgrind aarch64 unitialized warnings
This is under Debian Bullseye Linux on a PineBook Pro so ARM 64-bit I think although sizeof(int) is still 4. It's a fairly complicated program at 750 lines in it's almost-done state so I'm not posting the whole thing. I have this program that does audiograms https://sourceforge.net/projects/audiogram-c/ and I got the bright idea of adding FFT plots to the video generated. I read a wav file into RAM, draw the envelope of the audio. Then move a cursor bar over it by generating frames at different times, saving as jpegs and calling ffmpeg at the end to make a video. Originally it was a work-around for not being able to post audio files to social media sites. The FFT version works with the PCM data in the wav file in memory and draws more onto the same frames. tmpbuf is a per-frame output drawing area allocated with calloc and then cleared with bzero but I still get these uninitialized warnings: ==26220== ==26220== Invalid write of size 1 ==26220==at 0x402460: plot (agf.c:573) ==26220==by 0x402B9F: main (agf.c:713) ==26220== Address 0x4d2b993 is 13 bytes before an unallocated block of size 3,278,400 in arena "client" ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220==at 0x401504: plotffts (agf.c:301) ==26220==by 0x401DDF: makeframes (agf.c:442) ==26220==by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220==by 0x40125B: fft_init (agf.c:173) ==26220==by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220==at 0x40153C: plotffts (agf.c:303) ==26220==by 0x401DDF: makeframes (agf.c:442) ==26220==by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220==by 0x40125B: fft_init (agf.c:173) ==26220==by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220==at 0x401598: plotffts (agf.c:307) ==26220==by 0x401DDF: makeframes (agf.c:442) ==26220==by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220==by 0x40125B: fft_init (agf.c:173) ==26220==by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220==at 0x4015D0: plotffts (agf.c:309) ==26220==by 0x401DDF: makeframes (agf.c:442) ==26220==by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220==by 0x40125B: fft_init (agf.c:173) ==26220==by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220==at 0x40165C: plotffts (agf.c:315) ==26220==by 0x401DDF: makeframes (agf.c:442) ==26220==by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220==by 0x40125B: fft_init (agf.c:173) ==26220==by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220==at 0x401678: plotffts (agf.c:317) ==26220==by 0x401DDF: makeframes (agf.c:442) ==26220==by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220==by 0x40125B: fft_init (agf.c:173) ==26220==by 0x402B63: main (agf.c:707) ==26220== ==26220== Use of uninitialised value of size 8 ==26220==at 0x4016E0: plotffts (agf.c:328) ==26220==by 0x401DDF: makeframes (agf.c:442) ==26220==by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220==by 0x40125B: fft_init (agf.c:173) ==26220==by 0x402B63: main (agf.c:707) ==26220== ==26220== Use of uninitialised value of size 8 ==26220==at 0x4016F8: plotffts (agf.c:329) ==26220==by 0x401DDF: makeframes (agf.c:442) ==26220==by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220==by 0x40125B: fft_init (agf.c:173) ==26220==by 0x402B63: main (agf.c:707) ==26220== ==26220== Use of uninitialised value of size 8 ==26220==at 0x401710: plotffts (agf.c:330) ==26220==by 0x401DDF: makeframes (agf.c:442) ==26220==by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220==at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220==by 0x40125B: fft_init (agf.c:173) ==26220==by 0x402B63: main (agf.c:707) ==26220== ==26220==
Re: [Valgrind-users] PowerPC undefined symbol _restgpr_30_x
Those happen, don't take it personally. They used to be real common
in ARM. Sounds like you hit a code that's not covered. Not that I'm
one that can add it.
See the "==466== Your program just tried to execute an instruction that Valgrind
==466== did not recognise." section of the error message. OTOH
somewhere it looks like it jumped to a null.
On 3/22/20, MP wrote:
> I'm trying to use Valgrind on an embedded PowerPC system but I'm
> getting the following errors:
>
> ./testprog: symbol lookup error:
> /usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so: undefined
> symbol: _restgpr_30_x
> disInstr(ppc): unhandled instruction: 0x0
> primary 0(0x0), secondary 0(0x0)
> ==466== valgrind: Unrecognised instruction at address 0xffefa74.
> ==466==at 0xFFEFA74: ??? (in
> /usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so)
>
> The target setup is:
> CPU: MPC8280 (PowerPC 603e core)
> Linux Kernel 4.9.59
> gcc 6.3.0
> glibc 2.25
> valgrind 3.15.0
> The toolchain was generated using crosstool-NG 1.23 with a target of
> "powerpc-generic-linux-gnu".
>
> Test program is:
> int main (int argc, char **argv) { return argc; }
>
> It was compiled with:
> powerpc-generic-linux-gnu-gcc -o testprog testprog.c
>
> Valgrind was compiled like this:
> ./configure --host=powerpc-generic-linux-gnu
> make
>
> The full program output is as follows:
>
> # valgrind -v ./testprog
> ==466== Memcheck, a memory error detector
> ==466== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==466== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun
> with -h for copyright info
> ==466== Command: ./testprog
> ==466==
> --466-- Valgrind options:
> --466---v
> --466-- Contents of /proc/version:
> --466-- Linux version 4.9.59 (build@engdev) (gcc version 6.3.0
> (crosstool-NG crosstool-ng-1.23.0) ) #0 PREEMPT Mon Mar 9 10:36:51 EDT
> 2020
> --466--
> --466-- Arch and hwcaps: PPC32, BigEndian, ppc32-int-flt-GX
> --466-- Page sizes: currently 4096, max supported 65536
> --466-- Valgrind library directory: /usr/local/lib/valgrind
> --466-- Reading syms from /lib/ld-2.25.so
> --466-- Reading syms from /tmp/testprog
> --466-- Reading syms from /usr/local/lib/valgrind/memcheck-ppc32-linux
> --466--object doesn't have a dynamic symbol table
> --466-- Scheduler: using generic scheduler lock implementation.
> --466-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
> ==466== embedded gdbserver: reading from
> /tmp/vgdb-pipe-from-vgdb-to-466-by-root-on-???
> ==466== embedded gdbserver: writing to
> /tmp/vgdb-pipe-to-vgdb-from-466-by-root-on-???
> ==466== embedded gdbserver: shared mem
> /tmp/vgdb-pipe-shared-mem-vgdb-466-by-root-on-???
> ==466==
> ==466== TO CONTROL THIS PROCESS USING vgdb (which you probably
> ==466== don't want to do, unless you know exactly what you're doing,
> ==466== or are doing some strange experiment):
> ==466== /usr/local/lib/valgrind/../../bin/vgdb --pid=466 ...command...
> ==466==
> ==466== TO DEBUG THIS PROCESS USING GDB: start GDB like this
> ==466== /path/to/gdb ./testprog
> ==466== and then give GDB the following command
> ==466== target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=466
> ==466== --pid is optional if only one valgrind process is running
> ==466==
> --466-- REDIR: 0x401b250 (ld.so.1:strcmp) redirected to 0x58116d7c
> (vgPlain_ppc32_linux_REDIR_FOR_strcmp)
> --466-- REDIR: 0x401b3b4 (ld.so.1:strlen) redirected to 0x58116d54
> (vgPlain_ppc32_linux_REDIR_FOR_strlen)
> --466-- REDIR: 0x401b174 (ld.so.1:index) redirected to 0x58116df0
> (vgPlain_ppc32_linux_REDIR_FOR_strchr)
> --466-- Reading syms from
> /usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so
> --466-- Reading syms from
> /usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so
> --466-- REDIR: 0x401bec8 (ld.so.1:memcpy) redirected to 0xffba7e8 (memcpy)
> --466-- REDIR: 0x401b820 (ld.so.1:bcmp) redirected to 0xffbb8c4 (bcmp)
> --466-- Reading syms from /lib/libc-2.25.so
> ./testprog: symbol lookup error:
> /usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so: undefined
> symbol: _restgpr_30_x
> disInstr(ppc): unhandled instruction: 0x0
> primary 0(0x0), secondary 0(0x0)
> ==466== valgrind: Unrecognised instruction at address 0xffefa74.
> ==466==at 0xFFEFA74: ??? (in
> /usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so)
> ==466==by 0x404082F: ??? (in /lib/ld-2.25.so)
> ==466==by 0x4018D27: _dl_signal_error (dl-error-skeleton.c:134)
> ==466==by 0x4018E67: _dl_signal_cerror (dl-error-skeleton.c:166)
> ==466==by 0x400AECF: _dl_lookup_symbol_x (dl-lookup.c:874)
> ==466==by 0x400C977: elf_machine_rela (dl-machine.h:315)
> ==466==by 0x400C977: elf_dynamic_do_Rela (do-rel.h:170)
> ==466==by 0x400C977: _dl_relocate_object (dl-reloc.c:259)
> ==466==by 0x4004923: dl_main (rtld.c:2051)
> ==466==by 0x4017B73: _dl_sysdep_start (dl-sysdep.c:253)
> ==466==by 0x4005A3F: _dl_start_final (rtld.c:305)
>
Re: [Valgrind-users] Issues installing valgrind 3.15.0
In Debian I'm just using the Valgrind that's in the debs (packages): dpkg-query -l | grep -i valgrind ii valgrind 1:3.12.0~svn20160714-1+b1 arm64instrumentation framework for building dynamic analysis tools ii valgrind-dbg 1:3.12.0~svn20160714-1+b1 arm64instrumentation framework for building dynamic analysis tools (debug) ii valkyrie 2.0.0-1+b1 arm64open-source graphical user interface for the Valgrind On 9/30/19, Alan Corey wrote: > I'm not sure which of those you'd want, but you can try > CFLAGS="-I" ./configure > > Or if it uses cmake it would be a -D define and poke around in your cache > > -I will add a directory, -i (lowercase) will add a specific file, and > yes it's stuff that's going to make. Not for arch, just for finding > stuff > > On 9/30/19, Salman Ahmed wrote: >> on my machine I have >> /usr/arm-linux-gnueabi/include/asm/types.h >> /usr/include/x86_64-linux-gnu/asm/types.h >> >> and a lot of dirs inside -> /usr/src/linux-headers-4.15.0-24/arch/ >> >> e.g.) /usr/src/linux-headers-4.15.0-24/arch/alpha/include/asm/types.h >> /usr/src/linux-headers-4.15.0-24/arch/alpha/include/uapi/asm/types.h >> /usr/src/linux-headers-4.15.0-24/arch/arm/include/uapi/asm/types.h >> etc >> >> Do I need to make with some special "make ARCH="? I thought running >> ./configure would set that up >> >> >> >> >> On Mon, Sep 30, 2019 at 6:37 PM Salman Ahmed >> wrote: >> >>> on my machine I have >>> >>> >>> On Mon, Sep 30, 2019 at 6:31 PM João M. S. Silva < >>> joao.m.santos.si...@gmail.com> wrote: >>> >>>> I just used a Linux Mint VM: >>>> >>>> Other than Linux headers I only get this: >>>> >>>> $ dpkg -S /usr/include/x86_64-linux-gnu/asm/types.h >>>> linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/types.h >>>> >>>> Should be package linux-libc-dev. >>>> >>>> João M. S. Silva >>>> >>>> On Mon, Sep 30, 2019 at 2:18 PM Alan Corey wrote: >>>> > >>>> > You're missing asm/types.h >>>> > >>>> > Not sure what it's part of because there are 1 or 2 other types.h >>>> > files too. Somewhere in build-essentials or kernel building stuff I >>>> > picked it up. Try your kernel headers package I see: >>>> > >>>> > locate asm/types.h >>>> > /usr/include/aarch64-linux-gnu/asm/types.h >>>> > /usr/src/linux-headers-4.9.177+/arch/arm/include/asm/types.h >>>> > /usr/src/linux-headers-4.9.177+/arch/arm64/include/generated/asm/types.h >>>> > /usr/src/linux-headers-4.9.177+/include/asm/types.h >>>> > >>>> > >>>> > On 9/30/19, Salman Ahmed wrote: >>>> > > Hello, >>>> > > >>>> > > I am getting the following error when I try to install valgrind on >>>> > > my >>>> > > machine (ubuntu 16.04) >>>> > > 1) ./configure >>>> > > 2) make >>>> > > In file included from /usr/include/linux/prctl.h:4:0, >>>> > > from /usr/include/sys/prctl.h:22, >>>> > > from m_gdbserver/remote-utils.c:34: >>>> > > /usr/include/linux/types.h:4:23: fatal error: asm/types.h: No such >>>> file or >>>> > > directory >>>> > > compilation terminated. >>>> > > Makefile:7078: recipe for target >>>> > > 'm_gdbserver/libcoregrind_x86_linux_a-remote-utils.o' failed >>>> > > >>>> > > I tried to google anything related to this error but havnt been >>>> > > able >>>> to fix >>>> > > the issue. >>>> > > >>>> > >>>> > >>>> > -- >>>> > - >>>> > No, I won't call it "climate change", do you have a "reality >>>> > problem"? >>>> - AB1JX >>>> > Cities are cages built to contain excess people and keep them from >>>> > cluttering up nature. >>>> > Impeach Impeach Impeach Impeach Impeach Impeach Impeach >>>> > Impeach >>>> > >>>> > >>>> > ___ >>>> > Valgrind-users mailing list >>>> > Valgrind-users@lists.sourceforge.net >>>> > https://lists.sourceforge.net/lists/listinfo/valgrind-users >>>> >>> >> > > > -- > - > No, I won't call it "climate change", do you have a "reality problem"? - > AB1JX > Cities are cages built to contain excess people and keep them from > cluttering up nature. > Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach > -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Cities are cages built to contain excess people and keep them from cluttering up nature. Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Issues installing valgrind 3.15.0
I'm not sure which of those you'd want, but you can try CFLAGS="-I" ./configure Or if it uses cmake it would be a -D define and poke around in your cache -I will add a directory, -i (lowercase) will add a specific file, and yes it's stuff that's going to make. Not for arch, just for finding stuff On 9/30/19, Salman Ahmed wrote: > on my machine I have > /usr/arm-linux-gnueabi/include/asm/types.h > /usr/include/x86_64-linux-gnu/asm/types.h > > and a lot of dirs inside -> /usr/src/linux-headers-4.15.0-24/arch/ > > e.g.) /usr/src/linux-headers-4.15.0-24/arch/alpha/include/asm/types.h > /usr/src/linux-headers-4.15.0-24/arch/alpha/include/uapi/asm/types.h > /usr/src/linux-headers-4.15.0-24/arch/arm/include/uapi/asm/types.h > etc > > Do I need to make with some special "make ARCH="? I thought running > ./configure would set that up > > > > > On Mon, Sep 30, 2019 at 6:37 PM Salman Ahmed wrote: > >> on my machine I have >> >> >> On Mon, Sep 30, 2019 at 6:31 PM João M. S. Silva < >> joao.m.santos.si...@gmail.com> wrote: >> >>> I just used a Linux Mint VM: >>> >>> Other than Linux headers I only get this: >>> >>> $ dpkg -S /usr/include/x86_64-linux-gnu/asm/types.h >>> linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/types.h >>> >>> Should be package linux-libc-dev. >>> >>> João M. S. Silva >>> >>> On Mon, Sep 30, 2019 at 2:18 PM Alan Corey wrote: >>> > >>> > You're missing asm/types.h >>> > >>> > Not sure what it's part of because there are 1 or 2 other types.h >>> > files too. Somewhere in build-essentials or kernel building stuff I >>> > picked it up. Try your kernel headers package I see: >>> > >>> > locate asm/types.h >>> > /usr/include/aarch64-linux-gnu/asm/types.h >>> > /usr/src/linux-headers-4.9.177+/arch/arm/include/asm/types.h >>> > /usr/src/linux-headers-4.9.177+/arch/arm64/include/generated/asm/types.h >>> > /usr/src/linux-headers-4.9.177+/include/asm/types.h >>> > >>> > >>> > On 9/30/19, Salman Ahmed wrote: >>> > > Hello, >>> > > >>> > > I am getting the following error when I try to install valgrind on >>> > > my >>> > > machine (ubuntu 16.04) >>> > > 1) ./configure >>> > > 2) make >>> > > In file included from /usr/include/linux/prctl.h:4:0, >>> > > from /usr/include/sys/prctl.h:22, >>> > > from m_gdbserver/remote-utils.c:34: >>> > > /usr/include/linux/types.h:4:23: fatal error: asm/types.h: No such >>> file or >>> > > directory >>> > > compilation terminated. >>> > > Makefile:7078: recipe for target >>> > > 'm_gdbserver/libcoregrind_x86_linux_a-remote-utils.o' failed >>> > > >>> > > I tried to google anything related to this error but havnt been able >>> to fix >>> > > the issue. >>> > > >>> > >>> > >>> > -- >>> > - >>> > No, I won't call it "climate change", do you have a "reality >>> > problem"? >>> - AB1JX >>> > Cities are cages built to contain excess people and keep them from >>> > cluttering up nature. >>> > Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach >>> > >>> > >>> > ___ >>> > Valgrind-users mailing list >>> > Valgrind-users@lists.sourceforge.net >>> > https://lists.sourceforge.net/lists/listinfo/valgrind-users >>> >> > -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Cities are cages built to contain excess people and keep them from cluttering up nature. Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Issues installing valgrind 3.15.0
You're missing asm/types.h Not sure what it's part of because there are 1 or 2 other types.h files too. Somewhere in build-essentials or kernel building stuff I picked it up. Try your kernel headers package I see: locate asm/types.h /usr/include/aarch64-linux-gnu/asm/types.h /usr/src/linux-headers-4.9.177+/arch/arm/include/asm/types.h /usr/src/linux-headers-4.9.177+/arch/arm64/include/generated/asm/types.h /usr/src/linux-headers-4.9.177+/include/asm/types.h On 9/30/19, Salman Ahmed wrote: > Hello, > > I am getting the following error when I try to install valgrind on my > machine (ubuntu 16.04) > 1) ./configure > 2) make > In file included from /usr/include/linux/prctl.h:4:0, > from /usr/include/sys/prctl.h:22, > from m_gdbserver/remote-utils.c:34: > /usr/include/linux/types.h:4:23: fatal error: asm/types.h: No such file or > directory > compilation terminated. > Makefile:7078: recipe for target > 'm_gdbserver/libcoregrind_x86_linux_a-remote-utils.o' failed > > I tried to google anything related to this error but havnt been able to fix > the issue. > -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Cities are cages built to contain excess people and keep them from cluttering up nature. Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] How can valgrind prevent Segmentation fault?
A segfault is usually a bad pointer or something pointing outside allocated space. Why it stops segfaulting when you run it through Valgrind I don't know. Compile with -g for either Valgrind or gdb, and if it still runs in Valgrind try gdb. You can just do gdb then you'll probably have to type run in gdb. At least if it segfaults in there you can do a backtrace and maybe figure out why. Compiling with -g will usually enable gdb to print out bits of your code when it stops so you may recognize where it is. Google something like "gdb segfault tutorial", you usually have to pick a frame I think. hmm, umass, I used to work there until 2009. On 1/26/19, Eliot Moss wrote: > On 1/26/2019 6:12 PM, Peng Yu wrote: > >> I have an executable. If I just run on its own, there will be >> segmentation fault. But if I run it using valgrind, it finishes >> successfully. Does anybody how can this happen? How to debug such a >> program? Thanks. > > Maybe not the sort of answer you have in mind, but I might start > with using gdb. It should still segfault under those conditions. > You can then try recompiling to -g to get debug symbols. Doing > that might affect whether the bug exhibits, but it would make > debugging easier. > > Valgrind might be useful if you think the fault has to do with > improper freeing or lack of initialization of pointers ... > > Regards - Eliot Moss > > > ___ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Cities are cages built to contain excess people and keep them from cluttering up nature. Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] What is the memory ( RAM ) requirement for running valgrind
I run it often on my Raspberry Pi 3b with 1 GB, never thought about it. Sent from my Motorola XT1527 On Fri, Jan 25, 2019, 5:02 AM Padala Dileep wrote: > Hi > > My system has 4GB memory ( arm-linux ) . But when I try to run the > valgrind, the process becomes very slow, and it gets rebooted with a > message "valgrind: the 'impossible' happened' > > How much RAM is expected to be present in the system to run valgrind for > 15-20 mins atleast. > > > If i stop the process, before 100% memory gets over, it dumps the > evaluation till that point. > But it is only for 5 mins of Run. and it has not hit all the threads as > the process is running slowly. > > > ==1382== Memcheck, a memory error detector > > ==1382== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > > ==1382== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info > > ==1382== Command: Frm20xd > > ==1382== > > --1382-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) > - exiting > > --1382-- si_code=1; Faulting address: 0x0FE3; sp: 0x426987b0 > > > > valgrind: the 'impossible' happened: > >Killed by fatal signal > > > > host stacktrace: > > ==1382==at 0x58184470: getUIntLittleEndianly (guest_arm_toIR.c:196) > > ==1382==by 0x58184470: disInstr_ARM_WRK.isra.36 > (guest_arm_toIR.c:16118) > > ==1382==by 0x5818E2B3: disInstr_ARM (guest_arm_toIR.c:23690) > > ==1382==by 0x581501D3: bb_to_IR (guest_generic_bb_to_IR.c:365) > > ==1382==by 0x581328AF: LibVEX_FrontEnd (main_main.c:560) > > ==1382==by 0x58133043: LibVEX_Translate (main_main.c:1185) > > ==1382==by 0x58059CBB: vgPlain_translate (m_translate.c:1813) > > ==1382==by 0x58095F53: handle_chain_me (scheduler.c:1134) > > ==1382==by 0x58097FFF: vgPlain_scheduler (scheduler.c:1483) > > ==1382==by 0x580F0F27: thread_wrapper (syswrap-linux.c:103) > > ==1382==by 0x580F0F27: run_a_thread_NORETURN (syswrap-linux.c:156) > > ==1382==by 0x: ??? > > > > Once I stop the process before it gets exited like above, It is dumping > the evaluation it was doing. > > > > = > > ==1375== Process terminating with default action of signal 2 (SIGINT) > > ==1375==at 0x53B90E8: std::string::_Rep::_S_create(unsigned int, > unsigned int, std::allocator const&) (in /lib/libstdc++.so.6.0.17) > > ==1375==by 0x7DD155E7: ??? > > ==1375== > > ==1375== HEAP SUMMARY: > > ==1375== in use at exit: 16,558 bytes in 292 blocks > > ==1375== total heap usage: 1,449 allocs, 1,157 frees, 53,262 bytes > allocated > > ==1375== > > ==1375== LEAK SUMMARY: > > ==1375==definitely lost: 0 bytes in 0 blocks > > ==1375==indirectly lost: 0 bytes in 0 blocks > > ==1375== possibly lost: 0 bytes in 0 blocks > > ==1375==still reachable: 16,558 bytes in 292 blocks > > ==1375== of which reachable via heuristic: > > ==1375== stdstring : 5,178 bytes in 194 > blocks > > ==1375== suppressed: 0 bytes in 0 blocks > > ==1375== Rerun with --leak-check=full to see details of leaked memory > > ==1375== > > ==1375== For counts of detected and suppressed errors, rerun with: -v > > ==1375== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > > > Thanks & Regards, > > Dileep Padala > ___ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users > ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind on arm system startup message
On 6/29/18, Edward Diener wrote: > On 6/28/2018 9:01 PM, Alan Corey wrote: >> I'm no expert, but especially if it's arm64 try fetching the absolute >> latest from https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=summary >> >> That's about the error I got running versions before 3.13 on my Pi and >> there was something similar even with 3.13 on the same Pi running as >> arm64. (and my rock64) Search in the archives of this list for >> arm64, it's probably not the final fix but it works for me. > > I am running valgrind 3.13.0 on the arm system. > > My attempts at cloning using sourceware.org/git/valgrind.git always get > permission denied. I just had no problem doing git clone git://sourceware.org/git/valgrind.git which is the URL on the page. I think you can also get to it through github but there are something like 20 forks of it, it's safer to use the sourceware URL. But all that's going to get you is the latest Valgrind, you may have more serious problems. Best to use the latest though. > >> >> On 6/28/18, Edward Diener wrote: >>> I am attempting to use Valgrind with an application on an embedded arm >>> system. Debugging with gdb, a problem is occurring with a shared library >>> used by the application, where gdb is showing a SIGABRT from a malloc >>> call in a well-supported library, but can not show me the memory >>> overwrite problem that must be causing the crash. I was hoping using >>> valgrind could isolate from where the original memory overwrite is >>> occurring. >>> >>> However as soon as I start 'valgrind --leak-check=yes ./myprogram' I get >>> the message: >>> >>> ==621== Memcheck, a memory error detector >>> ==621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. >>> ==621== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright >>> info >>> ==621== Command: ./myprogram >>> ==621== >>> disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E >>> ==621== valgrind: Unrecognised instruction at address 0x4cc1767. >>> ==621==at 0x4CC1766: ??? (in >>> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1) >>> ==621== Your program just tried to execute an instruction that Valgrind >>> ==621== did not recognise. There are two possible reasons for this. >>> ==621== 1. Your program has a bug and erroneously jumped to a non-code >>> ==621==location. If you are running Memcheck and you just saw a >>> ==621==warning about a bad jump, it's probably your program's fault. >>> ==621== 2. The instruction is legitimate but Valgrind doesn't handle it, >>> ==621==i.e. it's Valgrind's fault. If you think this is the case or >>> ==621==you are not sure, please let us know and we'll try to fix it. >>> ==621== Either way, Valgrind will now raise a SIGILL signal which will >>> ==621== probably kill your program. >>> >>> Does this mean that valgrind is not reliable for my purposes. It appears >>> impossible that this problem is being caused by any code execution in >>> 'myprogram' since the message occurs at the beginning of my valgrind >>> session and before the first console message 'myprogram' outputs, which >>> is at the beginning of the 'main' routine. > > -- > 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 > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind on arm system startup message
I'm no expert, but especially if it's arm64 try fetching the absolute latest from https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=summary That's about the error I got running versions before 3.13 on my Pi and there was something similar even with 3.13 on the same Pi running as arm64. (and my rock64) Search in the archives of this list for arm64, it's probably not the final fix but it works for me. On 6/28/18, Edward Diener wrote: > I am attempting to use Valgrind with an application on an embedded arm > system. Debugging with gdb, a problem is occurring with a shared library > used by the application, where gdb is showing a SIGABRT from a malloc > call in a well-supported library, but can not show me the memory > overwrite problem that must be causing the crash. I was hoping using > valgrind could isolate from where the original memory overwrite is > occurring. > > However as soon as I start 'valgrind --leak-check=yes ./myprogram' I get > the message: > > ==621== Memcheck, a memory error detector > ==621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==621== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info > ==621== Command: ./myprogram > ==621== > disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E > ==621== valgrind: Unrecognised instruction at address 0x4cc1767. > ==621== at 0x4CC1766: ??? (in > /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1) > ==621== Your program just tried to execute an instruction that Valgrind > ==621== did not recognise. There are two possible reasons for this. > ==621== 1. Your program has a bug and erroneously jumped to a non-code > ==621== location. If you are running Memcheck and you just saw a > ==621== warning about a bad jump, it's probably your program's fault. > ==621== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==621== i.e. it's Valgrind's fault. If you think this is the case or > ==621== you are not sure, please let us know and we'll try to fix it. > ==621== Either way, Valgrind will now raise a SIGILL signal which will > ==621== probably kill your program. > > Does this mean that valgrind is not reliable for my purposes. It appears > impossible that this problem is being caused by any code execution in > 'myprogram' since the message occurs at the beginning of my valgrind > session and before the first console message 'myprogram' outputs, which > is at the beginning of the 'main' routine. > > > > -- > 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 > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?
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 wrote: > Il giorno lun 18 giu 2018 alle ore 15:57 Alan Corey > 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 -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?
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 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 -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?
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 (debian-ker...@lists.debian.org) (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 0xD538 disInstr(arm64): 1101'0101 0011'1000 ' ' ==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 0x: ??? 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 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 (debian-ker...@lists.debian.org) (gcc >> version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29) >> >> I have Valgr
[Valgrind-users] Is there a Valgrind that knows arm64/aarch64?
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 (debian-ker...@lists.debian.org) (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 -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
