Fwd: No "by" message in memcheck output

Michael Ortiz <[email protected]>
Newsgroups gmane.comp.debugging.valgrind
Message-ID <CACB6cKO7eAvngGT23r5LTzJ=d3VYz1bU671wNRO9L6gv4xyM_A@mail.gmail.com>
---------- Forwarded message ---------
From: Michael Ortiz <[email protected]>
Date: Tue, Jul 13, 2021 at 3:52 PM
Subject: Re: [Valgrind-users] No "by" message in memcheck output
To: Paul FLOYD <[email protected]>


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 <[email protected]>
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 <[email protected]> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>

_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.