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 (t...@compton.nu) http://compton.nu/ ------------------------------------------------------------------------------ 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
