Dear All
I am thankful to get such good guidance.
It was shared lib issue.
I had some issue in my code, that was converted to shared lib.
When I did a static linking, I was able to see the trace, and was able to
fix it.
Thank you all again.
Best regards
Austin
On Fri, Jan 2, 2015 at 8:10 PM, John Reiser <jrei...@bitwagon.com> wrote:
> >> ==28501== 7 bytes in 1 blocks are indirectly lost in loss record 33 of
> 152
> >> ==28501== at 0x402CFC7: malloc (vg_replace_malloc.c:296)
> >> ==28501== by 0x40AF985: ???
> >> ==28501== by 0x40AE2A1: ???
>
> As Philippe Waroquiers said in another thread,
> > So, probably you did not compile with debug info (-g option).
>
> While you wait for the re-compile and re-link using -g, it may be possible
> to get some clues by using low-level debugging techniques. Run the
> program again, and while it is runnning then use a different terminal
> session
> to run
> cat /proc/PID/maps
> where PID is the process ID; in the reported case PID was 28501.
> Then lookup the addresses to see which module (shared library or main
> program)
> contains each return address such as 0x40AF985, 0x40AE2A1, etc.
> Run "nm" and "readelf --symbols" on the associated modules, then
> interpolate.
>
> Those particular addresses look somewhat unusual. If they were 16 times
> smaller
> (0x4AF985) then that might well be inside the main program. If they were
> 16 times larger (0x400AF985) then that often is in some system-supplied
> shared library on a 32-bit i686 running Linux. But the actual address
> 0x40AF985
> is far away from either usual case. The original poster said
> > I checked memory leak (using Valgrind 3.10.1 in a Ubuntu 12.04 LTS
> machine)
> but omitted the hardware architecture; please state what it is.
>
> Use a debugger such as gdb to disassemble the code surrounding the return
> addresses,
> such as: (gdb) x/20i 0x40AF985 - 0x18
> Look for references to global variables, other subroutines, constant
> values, etc.
> In some cases the numerical value of the offset to a pointer may suggest
> the use of a particular data structure.
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
