|
From: Dirk M. <dm...@gm...> - 2003-06-22 01:20:55
|
Hi, the backtraces of leak checking are useless when dlopened modules are interacting. Thats because by the time the leak checking occurs, the dlopened modules might have been unloaded again, and valgrind cannot find the debug symbols anymore, because the unmap removed the debug symbol table. Does anybody have a suggestion for cleanly fixing this? perhaps it should not unmap the debug symbols unless it really has to (i.e. another module maps at the current place?). But even then the leak check might fail.. hmm. The only safe way is probably to ensure that addresses that were used for dlopened modules are never recycled. any idea how to achieve this? -- Dirk |
|
From: Nicholas N. <nj...@ca...> - 2003-06-26 11:11:32
|
On Sun, 22 Jun 2003, Dirk Mueller wrote: > the backtraces of leak checking are useless when dlopened modules are > interacting. Thats because by the time the leak checking occurs, the > dlopened modules might have been unloaded again, and valgrind cannot find > the debug symbols anymore, because the unmap removed the debug symbol table. > > perhaps it should not unmap the debug symbols unless it really has to (i.e. > another module maps at the current place?). But even then the leak check > might fail.. hmm. The only safe way is probably to ensure that addresses > that were used for dlopened modules are never recycled. Other people have complained about this too. Your suggestion is probably the best, eg. when munmap() is uncalled, if it's for a code segment don't actually do the munmap(), and just leave the segment resident. This wastes virtual address space, but hopefully the total size of code segments mmapped in and out isn't so big. Perhaps an option to turn this off would be good. However, one complication would be from programs that repeatedly dlopen and dlclose the same code segment (I've been told that KDeveloper does this, for example); keeping track of mmapped/munmapped code segments would be necessary to avoid wasting space egregiously. Also, it clashes with the lazy debug reading done at the moment (debug info is not read until it's needed, eg. for producing an error message). For example, say your program dlopens some code with a memory leak, dlcloses it, and then the leak checker runs at the end. To print the error, the debug info is needed but by then it's too late. (The execution context -- the %eip values from the stack trace -- is recorded when the block is allocated, but the mapping from %eip values to file/function names isn't done until the error is printed.) So we would have to revert to strict debug reading first, too. I had a go at this once, but had trouble, and abandoned it... Another possibility would be to convert the %eip traces to full stack traces with names earlier, eg. when a code segment is munmapped. But that's probably more difficult. N |