Re: [BUG] opgprof/opreport -> error: basic_string::erase

[Amitabha R. <ami...@gm...>]

On 10/13/07, John Levon <le...@mo...> wrote:
> On Sat, Oct 13, 2007 at 05:23:07PM +0100, Amitabha Roy wrote:
>
> > The solution is to harden the name by replacing the
> > anon:/lib/libgcrypt.so.11
> > with anon:\\/lib\\/libgcrypt.so.11
>
> No it's not! It's completely nonsensical to have such an "anon" name. We
> need to find out why it happens, and fix that

My expectation is that the anon name gets printed, regardless of its
contents slashes and all. What if in the future anon names contained
slashes ?

As regards the question of why a file gets mapped anonymously, we have
the following facts from the log that Melchior put out.

1. The event buffer from the kernel driver shows up PC "X" for tgid
"Y" and the sample was preceded by an anonymous cookie.

2. A read of /proc/"Y"/maps give a range that contains "X" but is
labeled with a filename.

3. In the log in question there is NO way the file contents are
executable because its ld.so.cache which is ASCII text of paths.

My first guess is that a cookies, probably a switch cookie has been
dropped and this sample should not really be anonymous or doesnt even
belong to this tgid.

Less likely the sample from the kernel could be wrong, or the contents
of /proc/<..>/maps  could be bogus.

Least likely, there could be a problem somewhere in the daemon but it
would seem unlikely to stem from the code that assigns names to anon
regions. And the rest of the code has been pretty stable before ....

If its really a problem of dropping switch cookies (back out of anon),
there is nothing much that could be done other than hardening the code
as in my patch or dropping the sample early on. Before the anon naming
patch, this would have resulted in the incorrect attribution of a
sample to anon space or to some other tgid/app.

-Amitabha