Re: [Valgrind-users] profiling/debugging inside shared objects

[Nicholas N. <nj...@ca...>]

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