Menu
▾
▴
valgrind-users
|
From: Austin E. <aus...@gm...> - 2015-01-02 11:45:00
|
Dear All I have a C based application, it runs fine. I wanted to do memory leak check. I checked memory leak (using Valgrind 3.10.1 in a Ubuntu 12.04 LTS machine). Valgrind is really helpful. It helped me to great extent to fix memory leaks, uninitialized sections etc. Now I see some leaks (possible leaks) but stack it shows is empty one something as below. ==28501== ==28501== 5 bytes in 1 blocks are indirectly lost in loss record 32 of 152 ==28501== at 0x402CFC7: malloc (vg_replace_malloc.c:296) ==28501== by 0x40C48E7: ??? ==28501== by 0x40B7B7F: ??? ==28501== by 0x40E4830: ??? ==28501== by 0x40E4BC7: ??? ==28501== by 0x406FEAF: ??? ==28501== by 0x406C4EF: ??? ==28501== by 0x406AA9E: ??? ==28501== by 0x406489F: ??? ==28501== by 0x40646C9: ??? ==28501== by 0x4A2CE99: start_thread (pthread_create.c:308) ==28501== ==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: ??? ==28501== by 0x40ADB1B: ??? ==28501== by 0x40ADAAC: ??? ==28501== by 0x40C3B24: ??? ==28501== by 0x40BDAE2: ??? ==28501== by 0x40BDFA7: ??? ==28501== by 0x40BE6F2: ??? ==28501== by 0x40BF290: ??? ==28501== by 0x40BF483: ??? ==28501== by 0x40E63C0: ??? ==28501== My query is, why stack trace is empty. In such situations how do I catch where from problem origins. Many thanks. Austin |
|
From: Philippe W. <phi...@sk...> - 2015-01-02 13:35:54
|
On Fri, 2015-01-02 at 17:14 +0530, Austin Einter 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: ??? > ==28501== by 0x40ADB1B: ??? > ==28501== by 0x40ADAAC: ??? > ==28501== by 0x40C3B24: ??? > ==28501== by 0x40BDAE2: ??? > ==28501== by 0x40BDFA7: ??? > ==28501== by 0x40BE6F2: ??? > ==28501== by 0x40BF290: ??? > ==28501== by 0x40BF483: ??? > ==28501== by 0x40E63C0: ??? > ==28501== > > > My query is, why stack trace is empty. In such situations how do I > catch where from problem origins. Usually, when Valgrind cannot show function name, file name and linenr, it is because there is no debug information for this part of the code. So, probably you did not compile with debug info (-g option). So, check your compilation options, and add -g. Philippe |
|
From: Tom H. <to...@co...> - 2015-01-02 14:04:25
|
On 02/01/15 13:36, Philippe Waroquiers wrote: > On Fri, 2015-01-02 at 17:14 +0530, Austin Einter 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: ??? >> ==28501== by 0x40ADB1B: ??? >> ==28501== by 0x40ADAAC: ??? >> ==28501== by 0x40C3B24: ??? >> ==28501== by 0x40BDAE2: ??? >> ==28501== by 0x40BDFA7: ??? >> ==28501== by 0x40BE6F2: ??? >> ==28501== by 0x40BF290: ??? >> ==28501== by 0x40BF483: ??? >> ==28501== by 0x40E63C0: ??? >> ==28501== >> >> >> My query is, why stack trace is empty. In such situations how do I >> catch where from problem origins. > Usually, when Valgrind cannot show function name, file name and linenr, > it is because there is no debug information for this part > of the code. > > So, probably you did not compile with debug info (-g option). Given that this is a leak report the other likely cause is that the addresses are in a shared object that has been unloaded, though it's surprising that none at all are translatable. Otherwise I would at least expect to see the object name. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Philippe W. <phi...@sk...> - 2015-01-02 14:23:43
|
On Fri, 2015-01-02 at 14:04 +0000, Tom Hughes wrote: > Given that this is a leak report the other likely cause is that the > addresses are in a shared object that has been unloaded, though it's > surprising that none at all are translatable. Yes, that is strange. Effectively, maybe an unloaded shared object. Or maybe some JIT-ted code ? Is that a only a 'compiled executable' ? Or does it contain a JIT, e.g. a Java or Javascript library ? It looks also like the default limit of 12 callers is reached at least for some stack traces. > > Otherwise I would at least expect to see the object name. Yes, you are correct : even for a stripped executable, the object name is given. Philippe |
|
From: John R. <jr...@bi...> - 2015-01-02 14:40:23
|
>> ==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. |
|
From: Austin E. <aus...@gm...> - 2015-01-03 02:41:55
|
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 <jr...@bi...> 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
Thanks for helping keep SourceForge clean.
X