valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Helgrind causing data race warning in mutex_destroy_WRK?

[David F. <fa...@kd...>]

On mardi 17 août 2021 09:59:23 CEST Schmidt, Adriaan wrote:
> Hi.
> 
> Running Helgrind (Valgrind 3.17.0) on arm32 (Linux 4.14.139), glibc 2.31,
> and an application using Poco 1.10.1, I see the following:
> 
> ==17922== Possible data race during read of size 1 at 0x64BD4C4 by thread
> #97 ==17922== Locks held: 1, at address 0x1C134CC
> ==17922==    at 0x48536D8: my_memcmp (hg_intercepts.c:220)
> ==17922==    by 0x4853BBF: mutex_destroy_WRK (hg_intercepts.c:859)
> ==17922==    by 0x48572F7: pthread_mutex_destroy (hg_intercepts.c:882)
> ==17922==    by 0x5705F23: Poco::EventImpl::~EventImpl()
> (Event_POSIX.cpp:96) ==17922==    by 0x5706393: Poco::Event::~Event()
> (Event.cpp:40)
> ==17922==    by 0x578099B: Poco::Timer::~Timer() (Timer.cpp:34)
> ==17922==    by 0x5470827: Poco::Data::SessionPool::~SessionPool()
> (SessionPool.cpp:40) ==17922==    by 0x54708A7:
> Poco::Data::SessionPool::~SessionPool() (SessionPool.cpp:50) ==.....==    [
> ... ]
> ==17922==
> ==17922== This conflicts with a previous write of size 4 by thread #7
> ==17922== Locks held: none
> ==17922==    at 0x57F8998: __pthread_mutex_unlock_usercnt
> (pthread_mutex_unlock.c:52) ==17922==    by 0x4854273: mutex_unlock_WRK
> (hg_intercepts.c:1106) ==17922==    by 0x4857337: pthread_mutex_unlock
> (hg_intercepts.c:1124) ==17922==    by 0x5781153: setImpl
> (Event_POSIX.h:61)
> ==17922==    by 0x5781153: set (Event.h:101)
> ==17922==    by 0x5781153: Poco::Timer::run() (Timer.cpp:216)
> ==17922==    by 0x577ACAF: Poco::PooledThread::run() (ThreadPool.cpp:199)
> ==17922==    by 0x57765B3: Poco::ThreadImpl::runnableEntry(void*)
> (Thread_POSIX.cpp:345) ==17922==    by 0x48562FF: mythread_wrapper
> (hg_intercepts.c:398)
> ==17922==    by 0x57F4143: start_thread (pthread_create.c:477)
> 
> To me it seems that Helgrind itself is causing the warning when calculating
> mutex_is_init (hg_intercepts.c:859).

Isn't this rather a race between unlocking a mutex and destroying that mutex?

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

[Valgrind-users] Helgrind causing data race warning in mutex_destroy_WRK?

[Schmidt, A. <adr...@si...>]

Hi.

Running Helgrind (Valgrind 3.17.0) on arm32 (Linux 4.14.139), glibc 2.31, and an application using Poco 1.10.1, I see the following:

==17922== Possible data race during read of size 1 at 0x64BD4C4 by thread #97
==17922== Locks held: 1, at address 0x1C134CC
==17922==    at 0x48536D8: my_memcmp (hg_intercepts.c:220)
==17922==    by 0x4853BBF: mutex_destroy_WRK (hg_intercepts.c:859)
==17922==    by 0x48572F7: pthread_mutex_destroy (hg_intercepts.c:882)
==17922==    by 0x5705F23: Poco::EventImpl::~EventImpl() (Event_POSIX.cpp:96)
==17922==    by 0x5706393: Poco::Event::~Event() (Event.cpp:40)
==17922==    by 0x578099B: Poco::Timer::~Timer() (Timer.cpp:34)
==17922==    by 0x5470827: Poco::Data::SessionPool::~SessionPool() (SessionPool.cpp:40)
==17922==    by 0x54708A7: Poco::Data::SessionPool::~SessionPool() (SessionPool.cpp:50)
==.....==    [ ... ]
==17922== 
==17922== This conflicts with a previous write of size 4 by thread #7
==17922== Locks held: none
==17922==    at 0x57F8998: __pthread_mutex_unlock_usercnt (pthread_mutex_unlock.c:52)
==17922==    by 0x4854273: mutex_unlock_WRK (hg_intercepts.c:1106)
==17922==    by 0x4857337: pthread_mutex_unlock (hg_intercepts.c:1124)
==17922==    by 0x5781153: setImpl (Event_POSIX.h:61)
==17922==    by 0x5781153: set (Event.h:101)
==17922==    by 0x5781153: Poco::Timer::run() (Timer.cpp:216)
==17922==    by 0x577ACAF: Poco::PooledThread::run() (ThreadPool.cpp:199)
==17922==    by 0x57765B3: Poco::ThreadImpl::runnableEntry(void*) (Thread_POSIX.cpp:345)
==17922==    by 0x48562FF: mythread_wrapper (hg_intercepts.c:398)
==17922==    by 0x57F4143: start_thread (pthread_create.c:477)

To me it seems that Helgrind itself is causing the warning when calculating mutex_is_init (hg_intercepts.c:859).

The conflicting access is a write to the field __data.__owner of the mutex (https://elixir.bootlin.com/glibc/glibc-2.31/source/nptl/pthread_mutex_unlock.c#L52).

Any ideas what could be going on here?

Thanks,
Adriaan

[Valgrind-users] Fwd: No "by" message in memcheck output

[Michael O. <mto...@gm...>]

---------- Forwarded message ---------
From: Michael Ortiz <mto...@gm...>
Date: Tue, Jul 13, 2021 at 3:52 PM
Subject: Re: [Valgrind-users] No "by" message in memcheck output
To: Paul FLOYD <pj...@wa...>


I found a resolution to this issue here:
http://arago-project.org/pipermail/meta-arago/2015-August/006016.html

The resolution is to include the debug symbols
for vgpreload_memcheck-arm-linux.so. After doing so the callstack is
reported in the memcheck output:

==8828== Thread 1:
==8828== 5 bytes in 1 blocks are definitely lost in loss record 1 of 1
==8828==    at 0x4845BD4: malloc (vg_replace_malloc.c:309)
==8828==    by 0x73D6B: main (example.cpp:158)

Cheers,
Mike


On Tue, Jul 13, 2021 at 2:01 PM Michael Ortiz <mto...@gm...>
wrote:

> Thanks for the reply,
>
> I set the malloc breakpoint in gdb per your suggestion and the
> callstack shows that the offending call is in main:
>
> Breakpoint 15, 0x00072760 in malloc@plt ()
> (gdb) where
> #0  0x00072760 in malloc@plt ()
> #1  0x00073d6c in main (argc=<optimized out>, argv=<optimized out>) at
> /home/mortiz/test/example.cpp:158
>
> As you noted, I am running on armv7l. I wonder if the callstack output is
> not supported in the "HEAP SUMMARY" for this architecture.
>
> For reference, I am using valgrind provided by yocto zeus (3.0.3).
>
> Mike
>
> On Tue, Jul 13, 2021 at 12:53 AM Paul FLOYD <pj...@wa...> wrote:
>
>>
>> > De : "Michael Ortiz"
>> > Objet : [Valgrind-users] No "by" message in memcheck output
>>
>>
>> Hi
>>
>> It's possible that the call to malloc is before the start of main
>> (either from your libc or for the initialization of some static or global
>> object).
>> I know next to nothing about the ARM ABI, but on amd64 Linux
>> the callstack in this case contains things like
>>
>> ==1441== 4 bytes in 1 blocks are still reachable in loss record 1 of 2
>> ==1441== at 0x402DF66: operator new(unsigned long)
>> (vg_replace_malloc.c:417)
>> ==1441== by 0x401187: __static_initialization_and_destruction_0(int, int)
>> (source.cpp:1)
>> ==1441== by 0x4011A4: _GLOBAL__sub_I_pi (l.cpp:3)
>> ==1441== by 0x4011FC: __libc_csu_init (in /home/user/exe)
>> ==1441== by 0x4D48364: (below main) (in /usr/lib64/libc-2.17.so)
>>
>> Can you run your app under gdb, but a break on malloc and then run.
>> You should be able to see the callstack and then be able to tell if
>> Valgrind is telling you the right thing or not.
>>
>> A+
>> Paul
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>

Re: [Valgrind-users] No "by" message in memcheck output

[Paul F. <pj...@wa...>]

> De : "Michael Ortiz" 
> Objet : [Valgrind-users] No "by" message in memcheck output


Hi

It's possible that the call to malloc is before the start of main
(either from your libc or for the initialization of some static or global object).
I know next to nothing about the ARM ABI, but on amd64 Linux
the callstack in this case contains things like

==1441== 4 bytes in 1 blocks are still reachable in loss record 1 of 2
==1441== at 0x402DF66: operator new(unsigned long) (vg_replace_malloc.c:417)
==1441== by 0x401187: __static_initialization_and_destruction_0(int, int) (source.cpp:1)
==1441== by 0x4011A4: _GLOBAL__sub_I_pi (l.cpp:3)
==1441== by 0x4011FC: __libc_csu_init (in /home/user/exe)
==1441== by 0x4D48364: (below main) (in /usr/lib64/libc-2.17.so)

Can you run your app under gdb, but a break on malloc and then run.
You should be able to see the callstack and then be able to tell if
Valgrind is telling you the right thing or not.

A+
Paul

[Valgrind-users] No "by" message in memcheck output

[Michael O. <mto...@gm...>]

Hi,

I'm running valgrind version 3.15.

When I run the following:

valgrind --tool=memcheck --leak-check=yes <path to executable>

I get the following output:

==13501== HEAP SUMMARY:
==13501==     in use at exit: 5 bytes in 1 blocks
==13501==   total heap usage: 137,210 allocs, 137,209 frees, 4,188,260
bytes allocated
==13501==
==13501== Thread 1:
==13501== 5 bytes in 1 blocks are definitely lost in loss record 1 of 1
==13501==    at 0x4845BD4: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)

Notice, there is no "by" message indicating where the allocation occurred.
For example, I expected something like this:

==13501==    by 0x804840F: main (example.c:5)

directly following the "at" message, but it's not there. I have debug
symbols preserved in my executable.

Was this behavior (i.e. "by" output) added in some later version?

Thank you,
Mike

Re: [Valgrind-users] Problem with valgrind-3.17.0 and openmpi-4.0.5

[TESSER F. <fed...@po...>]

I have tried valgrind 3.17.0 and openmpi 4.0.2, and it 
works.

Do you know if there are some reported bugs with that 
specific
version?

Regards,

Federico Tesser



On Wed, 07 Jul 2021 10:25:52 +0200
  "TESSER FEDERICO" <fed...@po...> wrote:
> Good morning.
> 
> I have installed valgrind 3.17.0, having previously 
>loaded the
> module for openmpi 4.0.5, so it found the 
>"MPI2-compliant mpicc
> and mpi.h...".
> 
> However, trying to run just a simple program like this 
>one:
> 
> 
> 
> #include <mpi.h>
> #include <stdio.h>
> 
> int main(int argc, char** argv) {
> 
> MPI_Init(NULL, NULL);
> 
> int world_size;
> int world_rank;
> int name_len;
> char processor_name[MPI_MAX_PROCESSOR_NAME];
> 
> MPI_Comm_size(MPI_COMM_WORLD, &world_size);
> MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);
> MPI_Get_processor_name(processor_name, &name_len);
> 
> printf("Hello world from processor %s, rank %d out of %d 
>processors\n",
> 	   processor_name, world_rank, world_size);
> 
> MPI_Finalize();
> 
> }
> 
> 
> 
> will produce the following errors:
> 
> 
> 
> ==113228== Memcheck, a memory error detector
> ==113228== Copyright (C) 2002-2017, and GNU GPL'd, by 
>Julian Seward et al.
> ==113228== Using Valgrind-3.17.0 and LibVEX; rerun with 
>-h for copyright info
> ==113228== Command: ./pure_mpi_valgrind_try/a.out
> ==113228==
> valgrind MPI wrappers 113228: Active for pid 113228
> valgrind MPI wrappers 113228: Try MPIWRAP_DEBUG=help for 
>possible options
> vex amd64->IR: unhandled instruction bytes: 0x62 0xF2 
>0x7D 0x8 0x7C 0xC5 0xC5 0xF9 0xD6 0x43
> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
> ==113228== valgrind: Unrecognised instruction at address 
>0x5c79318.
> ==113228==    at 0x5C79318: opal_pointer_array_init (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5CA4BDB: mca_base_var_init (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5C82F11: opal_init_util (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5157FD9: ompi_mpi_init 
>(ompi_mpi_init.c:428)
> ==113228==    by 0x50FB3A8: PMPI_Init (pinit.c:69)
> ==113228==    by 0x4E4BC26: PMPI_Init 
>(libmpiwrap.c:2288)
> ==113228==    by 0x10893B: main (main.c:6)
> ==113228== Your program just tried to execute an 
>instruction that Valgrind
> ==113228== did not recognise.  There are two possible 
>reasons for this.
> ==113228== 1. Your program has a bug and erroneously 
>jumped to a non-code
> ==113228==    location.  If you are running Memcheck and 
>you just saw a
> ==113228==    warning about a bad jump, it's probably 
>your program's fault.
> ==113228== 2. The instruction is legitimate but Valgrind 
>doesn't handle it,
> ==113228==    i.e. it's Valgrind's fault.  If you think 
>this is the case or
> ==113228==    you are not sure, please let us know and 
>we'll try to fix it.
> ==113228== Either way, Valgrind will now raise a SIGILL 
>signal which will
> ==113228== probably kill your program.
> ==113228==
> ==113228== Process terminating with default action of 
>signal 4 (SIGILL): dumping core
> ==113228==  Illegal opcode at address 0x5C79318
> ==113228==    at 0x5C79318: opal_pointer_array_init (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5CA4BDB: mca_base_var_init (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5C82F11: opal_init_util (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5157FD9: ompi_mpi_init 
>(ompi_mpi_init.c:428)
> ==113228==    by 0x50FB3A8: PMPI_Init (pinit.c:69)
> ==113228==    by 0x4E4BC26: PMPI_Init 
>(libmpiwrap.c:2288)
> ==113228==    by 0x10893B: main (main.c:6)
> slurmstepd: error: *** JOB 159641 ON node01 CANCELLED AT 
>2021-07-07T10:21:29 ***
> srun: Job step aborted: Waiting up to 32 seconds for job 
>step to finish.
> srun: error: Timed out waiting for job step to complete
> slurmstepd: error: *** STEP 159641.0 ON node01 CANCELLED 
>AT 2021-07-07T10:22:48 ***
> 
> 
> 
> What am I doing wrong?
> 
> Regards,
> 
>Federico Tesser

[Valgrind-users] Problem with valgrind-3.17.0 and openmpi-4.0.5

[TESSER F. <fed...@po...>]

Good morning.

I have installed valgrind 3.17.0, having previously loaded 
the
module for openmpi 4.0.5, so it found the "MPI2-compliant 
mpicc
and mpi.h...".

However, trying to run just a simple program like this 
one:



#include <mpi.h>
#include <stdio.h>

int main(int argc, char** argv) {

MPI_Init(NULL, NULL);

int world_size;
int world_rank;
int name_len;
char processor_name[MPI_MAX_PROCESSOR_NAME];

MPI_Comm_size(MPI_COMM_WORLD, &world_size);
MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);
MPI_Get_processor_name(processor_name, &name_len);

printf("Hello world from processor %s, rank %d out of %d 
processors\n",
	   processor_name, world_rank, world_size);

MPI_Finalize();

}



will produce the following errors:



==113228== Memcheck, a memory error detector
==113228== Copyright (C) 2002-2017, and GNU GPL'd, by 
Julian Seward et al.
==113228== Using Valgrind-3.17.0 and LibVEX; rerun with -h 
for copyright info
==113228== Command: ./pure_mpi_valgrind_try/a.out
==113228==
valgrind MPI wrappers 113228: Active for pid 113228
valgrind MPI wrappers 113228: Try MPIWRAP_DEBUG=help for 
possible options
vex amd64->IR: unhandled instruction bytes: 0x62 0xF2 0x7D 
0x8 0x7C 0xC5 0xC5 0xF9 0xD6 0x43
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==113228== valgrind: Unrecognised instruction at address 
0x5c79318.
==113228==    at 0x5C79318: opal_pointer_array_init (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5CA4BDB: mca_base_var_init (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5C82F11: opal_init_util (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5157FD9: ompi_mpi_init 
(ompi_mpi_init.c:428)
==113228==    by 0x50FB3A8: PMPI_Init (pinit.c:69)
==113228==    by 0x4E4BC26: PMPI_Init (libmpiwrap.c:2288)
==113228==    by 0x10893B: main (main.c:6)
==113228== Your program just tried to execute an 
instruction that Valgrind
==113228== did not recognise.  There are two possible 
reasons for this.
==113228== 1. Your program has a bug and erroneously 
jumped to a non-code
==113228==    location.  If you are running Memcheck and 
you just saw a
==113228==    warning about a bad jump, it's probably your 
program's fault.
==113228== 2. The instruction is legitimate but Valgrind 
doesn't handle it,
==113228==    i.e. it's Valgrind's fault.  If you think 
this is the case or
==113228==    you are not sure, please let us know and 
we'll try to fix it.
==113228== Either way, Valgrind will now raise a SIGILL 
signal which will
==113228== probably kill your program.
==113228==
==113228== Process terminating with default action of 
signal 4 (SIGILL): dumping core
==113228==  Illegal opcode at address 0x5C79318
==113228==    at 0x5C79318: opal_pointer_array_init (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5CA4BDB: mca_base_var_init (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5C82F11: opal_init_util (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5157FD9: ompi_mpi_init 
(ompi_mpi_init.c:428)
==113228==    by 0x50FB3A8: PMPI_Init (pinit.c:69)
==113228==    by 0x4E4BC26: PMPI_Init (libmpiwrap.c:2288)
==113228==    by 0x10893B: main (main.c:6)
slurmstepd: error: *** JOB 159641 ON node01 CANCELLED AT 
2021-07-07T10:21:29 ***
srun: Job step aborted: Waiting up to 32 seconds for job 
step to finish.
srun: error: Timed out waiting for job step to complete
slurmstepd: error: *** STEP 159641.0 ON node01 CANCELLED 
AT 2021-07-07T10:22:48 ***



What am I doing wrong?

Regards,

Federico Tesser

Re: [Valgrind-users] No used_suppression in verbose memcheck output

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

If you use xml output, the used suppressions are only output when
you give the option --show-error-list=yes.

With xml, increasing the verbosity will not show the used suppressions.
Likewise, when xml output is selected, no ERROR SUMMARY is output
(and probably some other textual output is similarly not produced in xml).

The idea is that xml output is used by front end applications that will
use the relevant options (such as --show-error-list=yes) to select
what to show.

Of course, other choices of when to output what would be possible.
The current state is like it is partially based on history.

For more details of what is output for errors, summary and used suppressions,
you can look at the function VG_(show_all_errors) in file m_errormgr.c

Philippe



On Tue, 2021-06-29 at 16:20 +0000, Mallove, EthanX A wrote:
> Hello,
>  
> I’ve intentionally created a memory leak in my application by adding a malloc() without a corresponding free(), but it seems to be suppressed by this block of my .supp file:
>  
> {
>     libc-2
>     Memcheck:Leak
>     ...
>     obj:*/libc-2.17.so
> }
>  
> When I remove the above from my suppression file, I see the <error> leak in the output XML.
>  
> But when the libc suppression is active, why isn’t there a “used_suppression” line in the -v output?
>  
> Thank you,
> Ethan
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] No used_suppression in verbose memcheck output

[Mallove, E. A <eth...@in...>]

Hello,

I've intentionally created a memory leak in my application by adding a malloc() without a corresponding free(), but it seems to be suppressed by this block of my .supp file:

{
    libc-2
    Memcheck:Leak
    ...
    obj:*/libc-2.17.so
}

When I remove the above from my suppression file, I see the <error> leak in the output XML.

But when the libc suppression is active, why isn't there a "used_suppression" line in the -v output?

Thank you,
Ethan

Re: [Valgrind-users] how to attach valgrind to more than one process at a time

[gangadhara r. c. <mee...@gm...>]

Thank you Paul for your detailed response which gives a clear understanding
of valgrind.

Thanks,
Gangadhar


On Tue, Jun 1, 2021 at 3:18 PM Paul Floyd <pj...@wa...> wrote:

>
>
> > On 1 Jun 2021, at 06:46, gangadhara reddy chavva <
> mee...@gm...> wrote:
> >
> > Hi,
> >
> > I am working on network routers where there will be multiple protocols
> running as different processes. if i want to attach the valgrind for more
> than one process at the same time what is the command/option to use.
>
>
> Hi
>
> Valgrind does not  “attach” to a process, in the same way that debuggers
> like GDB do using the ptrace syscall.
>
> When Valgrind runs, there is only one process - the Valgrind tool. The
> guest application “runs” on a virtual machine within Valgrind. And this can
> only be done by starting the guest application. Transferring an already
> running process image into Valgrind (to be able to “attach”) would be
> fraught with serious problems (for instance, memcheck would not have the
> history of allocations and the init state of memory, DRD and Helgrind would
> not have the history of mutex locking).
>
> As already mentioned, it is possible to have Valgrind instrument child
> processes.
>
> A+
> Paul
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] how to attach valgrind to more than one process at a time

[gangadhara r. c. <mee...@gm...>]

Thank you John for your quick response.
So I have to invoke separate valgrind command for each process for which I
want to check the process memory.

Thanks,
Gangadhar


On Tue, Jun 1, 2021 at 10:53 AM John Reiser <jr...@bi...> wrote:

> if i want to attach the valgrind for more than one process at the same
> time what is the command/option to use.
>
> There is no such command or option.  Each valgrind tool applies to only
> one process.
> The closest you can come is to invoke each process using a (separate)
> valgrind tool.
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] how to attach valgrind to more than one process at a time

[Paul F. <pj...@wa...>]

> On 1 Jun 2021, at 06:46, gangadhara reddy chavva <mee...@gm...> wrote:
> 
> Hi,
> 
> I am working on network routers where there will be multiple protocols running as different processes. if i want to attach the valgrind for more than one process at the same time what is the command/option to use.


Hi

Valgrind does not  “attach” to a process, in the same way that debuggers like GDB do using the ptrace syscall.

When Valgrind runs, there is only one process - the Valgrind tool. The guest application “runs” on a virtual machine within Valgrind. And this can only be done by starting the guest application. Transferring an already running process image into Valgrind (to be able to “attach”) would be fraught with serious problems (for instance, memcheck would not have the history of allocations and the init state of memory, DRD and Helgrind would not have the history of mutex locking). 

As already mentioned, it is possible to have Valgrind instrument child processes.

A+
Paul

Re: [Valgrind-users] how to attach valgrind to more than one process at a time

[John C. <joh...@ta...>]

If a script or something fires off all processes, you can use
--trace-children=yes to grind the child processes as well.

You can also ...
    --trace-children-skip=patt1,patt2,...    specifies a list of executables
                              that --trace-children=yes should not trace
into
    --trace-children-skip-by-arg=patt1,patt2,...   same as
--trace-children-skip=
                              but check the argv[] entries for children,
rather
                              than the exe name, to make a follow/no-follow
decision

On Tue, Jun 1, 2021 at 4:47 PM gangadhara reddy chavva <
mee...@gm...> wrote:

> Hi,
>
> I am working on network routers where there will be multiple protocols
> running as different processes. if i want to attach the valgrind for more
> than one process at the same time what is the command/option to use.
>
> Thank you.
>
> Thanks,
> Gangadhar
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
New Zealand

-- 
This Communication is Confidential. We only send and receive email on the
basis of the terms set out at www.taitradio.com/email_disclaimer 
<http://www.taitradio.com/email_disclaimer>

Re: [Valgrind-users] how to attach valgrind to more than one process at a time

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

if i want to attach the valgrind for more than one process at the same time what is the command/option to use.

There is no such command or option.  Each valgrind tool applies to only one process.
The closest you can come is to invoke each process using a (separate) valgrind tool.

[Valgrind-users] how to attach valgrind to more than one process at a time

[gangadhara r. c. <mee...@gm...>]

Hi,

I am working on network routers where there will be multiple protocols
running as different processes. if i want to attach the valgrind for more
than one process at the same time what is the command/option to use.

Thank you.

Thanks,
Gangadhar

Re: [Valgrind-users] How to include the Valgrind stack traces in a stand-alone debug version?

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

For the example given, the backtrace command of gdb-8.3 already displays 80%
of the requested information for code compiled by g++-9.3.1 using -g.

The request:
 > If compiled with -g, the debug output will display
 > (1) C/C++ names down into the standard library
 > (2) source code names and signatures
 > (3) including template instantiations
 > (4) file names
 > (5) line numbers

(gdb) backtrace
#0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7aac895 in __GI_abort () at abort.c:79
#2  0x0000000000401144 in bar () at traceback-test.c:6
#3  0x0000000000401154 in foo<int> () at traceback-test.c:12
#4  0x0000000000401134 in main () at traceback-test.c:17

valgrind-3.17.0:
==16820== Process terminating with default action of signal 6 (SIGABRT): dumping core
==16820==    at 0x4BFCE35: raise (raise.c:51)
==16820==    by 0x4BE7894: abort (abort.c:79)
==16820==    by 0x401143: bar() (traceback-test.c:6)
==16820==    by 0x401153: void foo<int>(int) (traceback-test.c:12)
==16820==    by 0x401133: main (traceback-test.c:17)

In this example, item (3) is the only essential difference.
valgrind:
      void foo<int>(int) (traceback-test.c:12)
contains result type and argument type, while
gdb:
      in foo<int> () at traceback-test.c:12
lacks "void" and "(int)".

For items (1), (2), (4), and (5) the gdb output contains the same information
as the valgrind output.  In addition, gdb gives more information for (1):
the complete internal path for standard library code
      ../sysdeps/unix/sysv/linux/raise.c:50
in contrast to valgrind's
      (raise.c:51)

So, any request for a better backtrace should be much more explicit than what was posted originally.


On 5/26/21, Martin Licht via Valgrind-users wrote:
> Addressing the first point: what Valgrind's tracer does better than others is fetching more source code information and semantics. This can shown immediately with the following example:
> 
> ```
> #include <assert.h>
> #include <stdlib.h>
> 
> inline void bar()
> {
>      abort();
> }
> 
> template<typename T>
> inline void foo(T)
> {
>      bar();
> }
> 
> int main()
> {
>      foo(5);
>      return 0;
> }
> ```
> 
> If compiled with -g, the debug output will display (1) C/C++ names down into the standard library (2) source code names and signatures (3) including template instantiations (4) file names (5) line numbers, among other things. I would be great to have a stack tracer like that.
> 
> The prettiest alternatives without Valgrind go along the lines of
> https://eli.thegreenplace.net/2015/programmatic-access-to-the-call-stack-in-c/
> using libunwind and cxxabi. This still is not as close to the source as Valgrind's output.

Re: [Valgrind-users] How to include the Valgrind stack traces in a stand-alone debug version?

[Martin L. <ml...@uc...>]

Addressing the first point: what Valgrind's tracer does better than others
is fetching more source code information and semantics. This can shown
immediately with the following example:

```
#include <assert.h>
#include <stdlib.h>

inline void bar()
{
    abort();
}

template<typename T>
inline void foo(T)
{
    bar();
}

int main()
{
    foo(5);
    return 0;
}
```

If compiled with -g, the debug output will display (1) C/C++ names down
into the standard library (2) source code names and signatures (3)
including template instantiations (4) file names (5) line numbers, among
other things. I would be great to have a stack tracer like that.

The prettiest alternatives without Valgrind go along the lines of
https://eli.thegreenplace.net/2015/programmatic-access-to-the-call-stack-in-c/
using libunwind and cxxabi. This still is not as close to the source as
Valgrind's output.

Best,
Martin


On Mon, May 24, 2021 at 3:09 PM John Reiser <jr...@bi...> wrote:

> On 5/24/21, Martin Licht via Valgrind-users wrote:
>
> > I think the Valgrind stack tracer is pretty great and I would like to
> use it as a substitute for `backtrace` in my C++ debug builds.
>
> It would help to give an explicit list of why valgrind's backtrace() is
> "pretty great"
> in contrast to GNU's.  The comment
>
> https://urldefense.com/v3/__https://blog.mozilla.org/nnethercote/2011/01/11/using-valgrind-to-get-stack-traces/*comment-438__;Iw!!Mih3wA!UfTEqXmRbG-pQAMC4pm54vloAenaAZoBw-abVILaGfvzVPS2T4cKVx6_eFTqAPk$
> identifies one item: GNU backtrace() shows only global (non-static)
> symbols.
> What else?
>
> Also, a detailed list would make a good request for enhancement
> at
> https://urldefense.com/v3/__https://www.gnu.org/software/libc/bugs.html__;!!Mih3wA!UfTEqXmRbG-pQAMC4pm54vloAenaAZoBw-abVILaGfvzVPS2T4cKVx6_Yz5dunc$
> ,
> especially if accompanied by an actual test case
> that shows how much better valgrind backtrace() is currently.
>
> --
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
>
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/valgrind-users__;!!Mih3wA!UfTEqXmRbG-pQAMC4pm54vloAenaAZoBw-abVILaGfvzVPS2T4cKVx6_dyjVF6g$
>

Re: [Valgrind-users] How to include the Valgrind stack traces in a stand-alone debug version?

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

On 5/24/21, Martin Licht via Valgrind-users wrote:

> I think the Valgrind stack tracer is pretty great and I would like to use it as a substitute for `backtrace` in my C++ debug builds.

It would help to give an explicit list of why valgrind's backtrace() is "pretty great"
in contrast to GNU's.  The comment
      https://blog.mozilla.org/nnethercote/2011/01/11/using-valgrind-to-get-stack-traces/#comment-438
identifies one item: GNU backtrace() shows only global (non-static) symbols.
What else?

Also, a detailed list would make a good request for enhancement
at https://www.gnu.org/software/libc/bugs.html ,
especially if accompanied by an actual test case
that shows how much better valgrind backtrace() is currently.

-- 

Re: [Valgrind-users] How to include the Valgrind stack traces in a stand-alone debug version?

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

On Mon, 2021-05-24 at 10:31 -0700, Martin Licht via Valgrind-users wrote:
> Hello,
> 
> I think the Valgrind stack tracer is pretty great and I would like to use it as a substitute for `backtrace` in my C++ debug builds.
> 
> A blog post by Nicholas Nethercote (Using Valgrind to get stack traces) describes a similar idea:
> https://blog.mozilla.org/nnethercote/2011/01/11/using-valgrind-to-get-stack-traces/
> 
> However, while this is already fairly elegant, I am wondering whether this can be done without invoking the program under valgrind.
> 
> If the Valgrind stack tracer were a simple #include that would be best. 
> Alternatively, a means of including any necessary valgrind framework into the debug build would be helpful. I appreciate your feedback.
The valgrind unwinder is very fast, so having it as a "standalone" library that can be
linked to a normal executable and used outside of the valgrind JIT framework would
be really nice. 

However, I think this unwind logic/code has a lot of dependencies
to other parts of valgrind (debug info reader, address space manager, valgrind own malloc
library, valgrind log and debug framework, ...).

So, clearly not a small task to 'cleanly' lib-ify the valgrind unwinder,
in particular if this library must then be usable both in a valgrind context and in a
'native' context.

Philippe

[Valgrind-users] How to include the Valgrind stack traces in a stand-alone debug version?

[Martin L. <ml...@uc...>]

Hello,

I think the Valgrind stack tracer is pretty great and I would like to use
it as a substitute for `backtrace` in my C++ debug builds.

A blog post by Nicholas Nethercote (Using Valgrind to get stack traces)
describes a similar idea:
https://blog.mozilla.org/nnethercote/2011/01/11/using-valgrind-to-get-stack-traces/

However, while this is already fairly elegant, I am wondering whether this
can be done without invoking the program under valgrind.

If the Valgrind stack tracer were a simple #include that would be best.
Alternatively, a means of including any necessary valgrind framework into
the debug build would be helpful. I appreciate your feedback.

Regards,
Martin

Re: [Valgrind-users] valgrind aarch64 unitialized warnings

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

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 <ala...@gm...> 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 (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== Conditional jump or move depends on uninitialised value(s)
> ==26220==    at 0x401788: plotffts (agf.c:337)
> ==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 0x4017A4: plotffts (agf.c:339)
> ==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 0x4017EC: plotffts (agf.c:342)
> ==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== Invalid write of size 1
> ==26220==    at 0x4017EC: plotffts (agf.c:342)
> ==26220==    by 0x401DDF: makeframes (agf.c:442)
> ==26220==    by 0x402BA3: main (agf.c:714)
> ==26220==  Address 0x4dbb9dc is 4 bytes before an unallocated block of
> size 2,688,512 in arena "client"
> ==26220==
> ==26220== Use of uninitialised value of size 8
> ==26220==    at 0x401804: plotffts (agf.c:343)
> ==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== Invalid write of size 1
> ==26220==    at 0x401804: plotffts (agf.c:343)
> ==26220==    by 0x401DDF: makeframes (agf.c:442)
> ==26220==    by 0x402BA3: main (agf.c:714)
> ==26220==  Address 0x4dbb9dd is 3 bytes before an unallocated block of
> size 2,688,512 in arena "client"
> ==26220==
> ==26220== Use of uninitialised value of size 8
> ==26220==    at 0x40181C: plotffts (agf.c:344)
> ==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== Invalid write of size 1
> ==26220==    at 0x40181C: plotffts (agf.c:344)
> ==26220==    by 0x401DDF: makeframes (agf.c:442)
> ==26220==    by 0x402BA3: main (agf.c:714)
> ==26220==  Address 0x4dbb9de is 2 bytes before an unallocated block of
> size 2,688,512 in arena "client"
> ==26220==
>
> The invalid writes I can't figure out either.  The code section looks like
> this:
>
> void plotffts(void) { // draw to tmpbuf
>   int i = 0; // initialize everything for Valgrind
>   int ofs = 0;
>   float min = -99999.9;  // floats work better
>   float max = 99999.9;
>   int x = EDGESKIP; // start at left side
>   int y = 0;
>   int oldx = EDGESKIP;
>   int oldy = 0;
>   int first = 1;
>   half = HEIGHT/2; // redundant
>   for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // common values for both
> L&R
>     if (fft_r[i] < min)  // unitialized value
>       min = fft_r[i];
>     if (fft_r[i] > max) // something not initialized
>       max = fft_r[i];
>   }
>   for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // read other channel
>     if (fft_l[i] > max) // uninit
>       max = fft_l[i];
>     if (fft_l[i] < min) // uninit
>       min = fft_l[i];
>   }
>   for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) {  // right channel
>     x = i;  // correct?
>     y = ((fft_r[i] - min) / max) * half;
>     if (y > half) // uninit
>       y = half;
>     if (y < 0) // uninit
>       y = 0;
>     if (first > 0) {
>       oldy = y;
>       first = 0;
>     }
> //    line(oldx,oldy,x,y);
>     oldx = x;
>     oldy = y;
> ///*
>     ofs = (y * WIDTH * 3) + (x * 3);
>     tmpbuf[ofs] = 0x01;  // Use of uninitialised value of size 8
>     tmpbuf[ofs+1] = 0xf5; // Use of uninitialised value of size 8
>     tmpbuf[ofs+2] = 0xf6; // Use of uninitialised value of size 8
> //*/
>   }
>   oldx = EDGESKIP;
>   for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) {  // left channel
>     x = i;
>     y = ((fft_l[i] - min) / max) * half;
>     if (y > half)  // uninit
>       y = half;
>     if (y < 0) // uninit
>       y = 0;
>     ofs = ((y + half)* WIDTH * 3) + (x * 3);
>     tmpbuf[ofs] = 0x01; // uninitialised value of size 8 & Invalid
> write of size 1
>     tmpbuf[ofs+1] = 0xf5;  // uninitialised value of size 8 & Invalid
> write of size 1
>     tmpbuf[ofs+2] = 0xf6; // uninitialised value of size 8 & Invalid
> write of size 1
>   }
>   // lines instead of dots would work better
> }
>
> I've looked up the line numbers given in the Valgrind error messages
> and put comments on those lines above.  tmpbuf is where I'm doing
> graphics, it's a chunk of RAM from calloc with an int8_t  pointer
> making it accessible.  It's not live graphics but a buffer of 24-bit
> color values which get written out to jpegs.  Maybe I should use
> 32-bit color?  This code does work, but I'm adding to it (Bresenham
> line drawing) and the error messages are distracting me from errors in
> the new code I'm working on.  My hunch is that something is still
> incomplete in Valgrind on aarch64 platforms.
>
>   Alan
> --
> -------------
> Education is contagious.
>


-- 
-------------
Education is contagious.

[Valgrind-users] valgrind aarch64 unitialized warnings

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

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== Conditional jump or move depends on uninitialised value(s)
==26220==    at 0x401788: plotffts (agf.c:337)
==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 0x4017A4: plotffts (agf.c:339)
==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 0x4017EC: plotffts (agf.c:342)
==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== Invalid write of size 1
==26220==    at 0x4017EC: plotffts (agf.c:342)
==26220==    by 0x401DDF: makeframes (agf.c:442)
==26220==    by 0x402BA3: main (agf.c:714)
==26220==  Address 0x4dbb9dc is 4 bytes before an unallocated block of
size 2,688,512 in arena "client"
==26220==
==26220== Use of uninitialised value of size 8
==26220==    at 0x401804: plotffts (agf.c:343)
==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== Invalid write of size 1
==26220==    at 0x401804: plotffts (agf.c:343)
==26220==    by 0x401DDF: makeframes (agf.c:442)
==26220==    by 0x402BA3: main (agf.c:714)
==26220==  Address 0x4dbb9dd is 3 bytes before an unallocated block of
size 2,688,512 in arena "client"
==26220==
==26220== Use of uninitialised value of size 8
==26220==    at 0x40181C: plotffts (agf.c:344)
==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== Invalid write of size 1
==26220==    at 0x40181C: plotffts (agf.c:344)
==26220==    by 0x401DDF: makeframes (agf.c:442)
==26220==    by 0x402BA3: main (agf.c:714)
==26220==  Address 0x4dbb9de is 2 bytes before an unallocated block of
size 2,688,512 in arena "client"
==26220==

The invalid writes I can't figure out either.  The code section looks like this:

void plotffts(void) { // draw to tmpbuf
  int i = 0; // initialize everything for Valgrind
  int ofs = 0;
  float min = -99999.9;  // floats work better
  float max = 99999.9;
  int x = EDGESKIP; // start at left side
  int y = 0;
  int oldx = EDGESKIP;
  int oldy = 0;
  int first = 1;
  half = HEIGHT/2; // redundant
  for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // common values for both L&R
    if (fft_r[i] < min)  // unitialized value
      min = fft_r[i];
    if (fft_r[i] > max) // something not initialized
      max = fft_r[i];
  }
  for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // read other channel
    if (fft_l[i] > max) // uninit
      max = fft_l[i];
    if (fft_l[i] < min) // uninit
      min = fft_l[i];
  }
  for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) {  // right channel
    x = i;  // correct?
    y = ((fft_r[i] - min) / max) * half;
    if (y > half) // uninit
      y = half;
    if (y < 0) // uninit
      y = 0;
    if (first > 0) {
      oldy = y;
      first = 0;
    }
//    line(oldx,oldy,x,y);
    oldx = x;
    oldy = y;
///*
    ofs = (y * WIDTH * 3) + (x * 3);
    tmpbuf[ofs] = 0x01;  // Use of uninitialised value of size 8
    tmpbuf[ofs+1] = 0xf5; // Use of uninitialised value of size 8
    tmpbuf[ofs+2] = 0xf6; // Use of uninitialised value of size 8
//*/
  }
  oldx = EDGESKIP;
  for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) {  // left channel
    x = i;
    y = ((fft_l[i] - min) / max) * half;
    if (y > half)  // uninit
      y = half;
    if (y < 0) // uninit
      y = 0;
    ofs = ((y + half)* WIDTH * 3) + (x * 3);
    tmpbuf[ofs] = 0x01; // uninitialised value of size 8 & Invalid
write of size 1
    tmpbuf[ofs+1] = 0xf5;  // uninitialised value of size 8 & Invalid
write of size 1
    tmpbuf[ofs+2] = 0xf6; // uninitialised value of size 8 & Invalid
write of size 1
  }
  // lines instead of dots would work better
}

I've looked up the line numbers given in the Valgrind error messages
and put comments on those lines above.  tmpbuf is where I'm doing
graphics, it's a chunk of RAM from calloc with an int8_t  pointer
making it accessible.  It's not live graphics but a buffer of 24-bit
color values which get written out to jpegs.  Maybe I should use
32-bit color?  This code does work, but I'm adding to it (Bresenham
line drawing) and the error messages are distracting me from errors in
the new code I'm working on.  My hunch is that something is still
incomplete in Valgrind on aarch64 platforms.

  Alan
-- 
-------------
Education is contagious.

Re: [Valgrind-users] Valgrind musl 1.2.2 bug

[Paul F. <pj...@wa...>]

On 4/26/21 8:23 PM, Kyryl Melekhin wrote:
> Hello valgrind community!
>
> This is my first message ever to this mailing list.
>
> I am currently experiencing a weird bug in valgrind, where it
> mistakenly does not recognize malloc/free/realloc function and also produces
> weird warnings. But only on musl linux x86_64 version 1.2.2


Probably the same as this issue in bugzilla:


https://bugs.kde.org/show_bug.cgi?id=435441


A+

Paul

[Valgrind-users] Valgrind musl 1.2.2 bug

[<k.m...@gm...>]

Hello valgrind community!

This is my first message ever to this mailing list.

I am currently experiencing a weird bug in valgrind, where it
mistakenly does not recognize malloc/free/realloc function and also produces
weird warnings. But only on musl linux x86_64 version 1.2.2

Consider this simple C program:

#include "stdio.h"
#include "stdlib.h"

int main()
{
        char *mem = malloc(123);
        *mem = 5;
        *(mem+1) = 5;
        *(mem+2) = 5;

        mem = realloc(mem, 400);
        *(mem+1) = 5;
        *(mem+2) = 5;
        free(mem);
        return 0;
}

As you can see there can't be any bugs in this code, everything is
within bounds.

However when I run
$ valgrind ./a.out
==486== Memcheck, a memory error detector
==486== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==486== Using Valgrind-3.18.0.GIT and LibVEX; rerun with -h for copyright info
==486== Command: ./a.out
==486==
==486== Invalid free() / delete / delete[] / realloc()
==486==    at 0x48C589F: realloc (vg_replace_malloc.c:1192)
==486==    by 0x109298: main (in /root/test/a.out)
==486==  Address 0x48baf80 is in a rw- mapped file
/usr/local/libexec/valgrind/vgpreload_core-amd64-linux.so segment
==486==
==486== Invalid write of size 1
==486==    at 0x1092A5: main (in /root/test/a.out)
==486==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==486==
==486==
==486== Process terminating with default action of signal 11 (SIGSEGV)
==486==  Access not within mapped region at address 0x1
==486==    at 0x1092A5: main (in /root/test/a.out)
==486==  If you believe this happened as a result of a stack
==486==  overflow in your program's main thread (unlikely but
==486==  possible), you can try to increase the size of the
==486==  main thread stack using the --main-stacksize= flag.
==486==  The main thread stack size used in this run was 8388608.
==486==
==486== HEAP SUMMARY:
==486==     in use at exit: 0 bytes in 0 blocks
==486==   total heap usage: 1 allocs, 1 frees, 400 bytes allocated
==486==
==486== All heap blocks were freed -- no leaks are possible
==486==
==486== For lists of detected and suppressed errors, rerun with: -s
==486== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault

This happens. -----------------------------

musl version is 1.2.2 from KISS linux
https://github.com/kiss-community/repo-main/tree/master/core/musl

I built valgrind myself from source without any special
configuration. I also tested it on Valgrind-3.16.0.RC1 940ec1ca6 and same
results.

$ autogen.sh
$ configure
$ make install

OK. Now when I use the musl 1.2.1 version
this should be the correct output from valgrind.

==918== Memcheck, a memory error detector
==918== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==918== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==918== Command: ./a.out
==918==
==918==
==918== HEAP SUMMARY:
==918==     in use at exit: 468 bytes in 4 blocks
==918==   total heap usage: 7 allocs, 3 frees, 1,031 bytes allocated
==918==
==918== LEAK SUMMARY:
==918==    definitely lost: 0 bytes in 0 blocks
==918==    indirectly lost: 0 bytes in 0 blocks
==918==      possibly lost: 0 bytes in 0 blocks
==918==    still reachable: 468 bytes in 4 blocks
==918==         suppressed: 0 bytes in 0 blocks
==918== Rerun with --leak-check=full to see details of leaked memory
==918==
==918== For lists of detected and suppressed errors, rerun with: -s
==918== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Is this a bug in musl or a bug on valgrind side?

Regards,
Kyryl

[Valgrind-users] Unable to use Valgrind on the Android Apps

[Nikhil A. <nik...@gm...>]

Hi everyone,

I want to use Valgrind to get the dynamic instruction trace for the Android
Apps. I installed Valgrind through termux app (using apt-get) and I
confirmed the installation’s success by executing the command *./valgrind
--help *and also from Valgrind version 3.16.1 (./valgrind --version). The
output of the command is showing the desired usage. I am also successful in
executing the ls binary by executing

*./valgrind --tool=memcheck -- ls* and I got the equivalent output.

But when I wanted to use Valgrind for the *android App* by executing the
command

*./valgrind --tool=memcheck -- /path/to/the/app’s/odex/file* I am getting
Segmentation fault:

==30335== Memcheck, a memory error detector

==30335== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.

==30335== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info

==30335== Command:
/data/app/com.khaalijeb.inkdrops-aKgulq0D9iHWWdZa1l-EBA==/oat/arm64/base.odex

==30335==

==30335==

==30335== Process terminating with default action of signal 11 (SIGSEGV)

==30335==  Bad permissions for mapped region at address 0x108000

==30335==    at 0x108000: ??? (in
/data/app/com.khaalijeb.inkdrops-aKgulq0D9iHWWdZa1l-EBA==/oat/arm64/base.odex)

==30335==

==30335== HEAP SUMMARY:

==30335==     in use at exit: 0 bytes in 0 blocks

==30335==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated

==30335==

==30335== All heap blocks were freed -- no leaks are possible

==30335==

==30335== For lists of detected and suppressed errors, rerun with: -s

==30335== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Segmentation fault


*Device Configuration*: LG Nexus 5x rooted device 64-bit machine with
arm64-v8a architecture.


I wanted to know why I am getting the segmentation fault? I am not getting
the segmentation fault when I am attaching the ls binary with Valgrind. May
I know the reasons behind it.

Thank you for helping in my research journey.
-- 
Nikhil Agrawal,
MTech(Research) Student,
Computer Science and Automation Department
IISc Bangalore-560012