|
From: <cha...@ya...> - 2003-04-04 21:11:18
|
Hi, I wonder if there are issues about profiling dinamically loaded plugins? valgrind --skin=cachegrind doesnt seem to produce any relevant info about code in those plugins, only code in statically linked libraries Greetings (btw: im using valgrind 1.9.2, gcc 3.2, redhat 7.2) ------------ ¡Internet GRATIS es Yahoo! Conexión! Usuario "yahoo", contraseña "yahoo". Desde Buenos Aires, 4004-1010. Otras ciudades: http://conexion.yahoo.com.ar/avanzados.html |
|
From: Nicholas N. <nj...@ca...> - 2003-04-07 12:40:40
|
On Fri, 4 Apr 2003, Charlls Quarra wrote: > I wonder if there are issues about profiling > dinamically loaded plugins? valgrind --skin=cachegrind > doesnt seem to produce any relevant info about code in > those plugins, only code in statically linked > libraries Hmm, in theory there should be no problems, Valgrind (and hence Cachegrind) can handle dlopen'd plugins ok... N |
|
From: Josef W. <Jos...@gm...> - 2003-04-07 14:48:57
|
On Monday 07 April 2003 14:40, Nicholas Nethercote wrote: > On Fri, 4 Apr 2003, Charlls Quarra wrote: > > I wonder if there are issues about profiling > > dinamically loaded plugins? valgrind --skin=cachegrind > > doesnt seem to produce any relevant info about code in > > those plugins, only code in statically linked > > libraries > > Hmm, in theory there should be no problems, Valgrind (and hence > Cachegrind) can handle dlopen'd plugins ok... But they are unmapped before program termination. You only get one cost line "discarded" for all plugins. The solution would be to allow dumping while the plugin is mapped. Or you dump the information of BBCCs when the according object is unmapped. Or you don't delete BBCCs and accumate cost to "discarded", but keep them. Now you have the problem that a BB start address isn't unique to get to the right BBCC, but you have to store the SegInfo* in the BBCCs to distinguish among BBs from different plugins at the same address. BTW, my Calltree skin should be buggy in this regard, as it doesn't delete any BBCCs on unmapping, but still only uses the BB address. But checking the SegInfo* should be easy enough for a fix. Perhaps it's even better to take BBCCs of unmapped objects from the hash into a list, and put them in again if the object is mapped again after adjusting the addresses if needed. The same object could be mapped on a different base address. Josef > > N > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@ca...> - 2003-04-07 14:55:32
|
On Mon, 7 Apr 2003, Josef Weidendorfer wrote: > > Hmm, in theory there should be no problems, Valgrind (and hence > > Cachegrind) can handle dlopen'd plugins ok... > > But they are unmapped before program termination. You only get one cost line > "discarded" for all plugins. The solution would be to allow dumping while the > plugin is mapped. Or you dump the information of BBCCs when the according > object is unmapped. > > Or you don't delete BBCCs and accumate cost to "discarded", but keep them. > Now you have the problem that a BB start address isn't unique to get to the > right BBCC, but you have to store the SegInfo* in the BBCCs to distinguish > among BBs from different plugins at the same address. > > BTW, my Calltree skin should be buggy in this regard, as it doesn't delete any > BBCCs on unmapping, but still only uses the BB address. But checking the > SegInfo* should be easy enough for a fix. > Perhaps it's even better to take BBCCs of unmapped objects from the hash into > a list, and put them in again if the object is mapped again after adjusting > the addresses if needed. The same object could be mapped on a different base > address. Another approach: I've been thinking about, and half-implemented, this solution: when a program munmap()s an executable segment, Valgrind doesn't really munmap it, but just leaves it in that address space. Then the symbols don't get unloaded. The only downside is that it wastes address space, but hopefully code sizes aren't so big that this is a problem. One problem is that debug info is currently read in lazily, which clashes with this, for tedious reasons. Getting back to this is somewhere in the lower half of my ever-growing todo list... N |
|
From: Josef W. <Jos...@in...> - 2003-04-07 15:21:20
|
On Monday 07 April 2003 16:55, Nicholas Nethercote wrote: > On Mon, 7 Apr 2003, Josef Weidendorfer wrote: > > > Hmm, in theory there should be no problems, Valgrind (and hence > > > Cachegrind) can handle dlopen'd plugins ok... > > > > But they are unmapped before program termination. You only get one cost > > line "discarded" for all plugins. The solution would be to allow dumping > > while the plugin is mapped. Or you dump the information of BBCCs when the > > according object is unmapped. > > > > Or you don't delete BBCCs and accumate cost to "discarded", but keep > > them. Now you have the problem that a BB start address isn't unique to > > get to the right BBCC, but you have to store the SegInfo* in the BBCCs to > > distinguish among BBs from different plugins at the same address. > > > > BTW, my Calltree skin should be buggy in this regard, as it doesn't > > delete any BBCCs on unmapping, but still only uses the BB address. But > > checking the SegInfo* should be easy enough for a fix. > > Perhaps it's even better to take BBCCs of unmapped objects from the hash > > into a list, and put them in again if the object is mapped again after > > adjusting the addresses if needed. The same object could be mapped on a > > different base address. > > Another approach: I've been thinking about, and half-implemented, this > solution: when a program munmap()s an executable segment, Valgrind doesn't > really munmap it, but just leaves it in that address space. Then the > symbols don't get unloaded. The only downside is that it wastes address > space, but hopefully code sizes aren't so big that this is a problem. I really see a problem if an application loads the same plugin multiple times in a row, and you get thus one plugin mapped multiple times simultaniously. E.g. in KDevelop (a C++ IDE), every feature for project development is in a plugin. Now every time you open another project, the plugins of the old project are unmapped and the plugins of the new one are mapped (around 20). It's easy to keep a list of objects the application has unmapped, and in a mmap, eventually return the already mapped object if a plugin is loaded a second time. > One problem is that debug info is currently read in lazily, which clashes > with this, for tedious reasons. Getting back to this is somewhere in the Why? If the same plugin is loaded at mostly once, I don't see a problem. Josef > lower half of my ever-growing todo list... > > N > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- -- Dipl.-Inform. Josef Weidendorfer LRR-TUM - Raum 01.06.056 - Tel. +49 / (0)89 / 289 - 18454 |
|
From: Nicholas N. <nj...@ca...> - 2003-04-07 15:36:47
|
On Mon, 7 Apr 2003, Josef Weidendorfer wrote: > > Another approach: I've been thinking about, and half-implemented, this > > solution: when a program munmap()s an executable segment, Valgrind doesn't > > really munmap it, but just leaves it in that address space. Then the > > symbols don't get unloaded. The only downside is that it wastes address > > space, but hopefully code sizes aren't so big that this is a problem. > > I really see a problem if an application loads the same plugin multiple times > in a row, and you get thus one plugin mapped multiple times simultaniously. > E.g. in KDevelop (a C++ IDE), every feature for project development is in a > plugin. Now every time you open another project, the plugins of the old > project are unmapped and the plugins of the new one are mapped (around 20). Urgh. > > One problem is that debug info is currently read in lazily, which clashes > > with this, for tedious reasons. Getting back to this is somewhere in the > > Why? If the same plugin is loaded at mostly once, I don't see a problem. It's a problem for Memcheck: if you have a leak in foo.so, often foo.so is dlclose()d before the program ends, currently the leak checker gives hopeless error messages about foo.so because the debug info has been unloaded. Now imagine I've implemented the don't-unload-the-symbols scheme, but there are no other errors in the program using foo.so. So the first time the debug info for foo.so is needed is during the leak check. But by this time, foo.so has already been loaded and unloaded, its debug info was never read (because it wasn't needed) and the error message is still uninformative. If debug info was needed even once before foo.so was dlclose()d there would be no problem, but we can't rely on that. N |