Re: [Valgrind-developers] Valgrind: r14898 - in /trunk: coregrind/m_aspacemgr/aspacemgr-linux.c include/pub_tool_aspacemgr.h

[Philippe W. <phi...@sk...>]

On Tue, 2015-02-03 at 17:18 +0100, Florian Krohm wrote:
> On 03.02.2015 14:39, Julian Seward wrote:
> > 
> > Hmm, the problem is, that gives us a new, if obscure, failure mode that
> > didn't exist before.  If a long running application dlopens and dlcloses
> > some .so, is it possible to run out of string table space now?
> 
> Sure. On the other hand there is no longer a limit in the number of
> segnames that you can have (other than exhausting the string table).
> The use case you describe is perhaps a corner case which will have more
> pressing issues other than running out of segment names; see
> https://bugs.kde.org/show_bug.cgi?id=79362
> But your point is an interesting one. And I will keep it in mind.
If I understood well, the leak happens only when merging 2 named
segments having a different name, but same device nr/inode nr.

It looks to me it might be better to just not merge these segments.

Not merging these has the following advantages:
1. The linux kernel already behaves like that : it does not
   merge such segments in /proc/<pid>/maps
   In other words, /proc/<pid>/maps consider different filenames
   as different 'entries' in the map
2. in case an error is reported for such a mmap-ed address,
   then it will be somewhat wrongly/surprisingly shown as belonging
   to another filename than the mmaped filename, if some merging was
   done. Such merging might or might not happen, depending
   on how valgrind choosed where to mmap the 2 filenames.
3. not merging solves this memleak.

If we do not do the merge, then we have to ensure aspacemgr selfcheck
uses the same checking rules as the rules used for merging.
If not, it will assert, and we fix :)


Philippe