#164 opreport error: basic_string::erase

Greg Hazel

Sometimes, when issuing an opreport or opannotate command, I get:

opreport error: basic_string::erase

Deleting all the samples, killing the deamon, and starting over seems to fix it.


  • Logged In: NO

    I am hitting this too (oprofile 0.9.3, kernel). The basic cause seems to be the presence of files like:


    (that is one long path, it will probably get wordwrapped by the bug tracker).

    When that path gets parsed by parse_filename it calls parse_anon with "{anon:" and "bin" as arguments, but parse_anon expects its first argument to look like "{anon:[something]}". It tries to strip the {anon:" and "}" and basic_string::erase gets thrown because the string is not long enough.

    Since I do not know yet if "{anon:/bin/bash}" makes any sense I do not know if I should be patching parse_filename to call parse_anon with strings it understands here ("{anon:/bin/bash}" and "27091.0x8048000.0x80e6000") or whatever generated that filename to do something else. Probably the latter, but I will not get around to completely debugging this soon.

  • Sujith

    Logged In: YES
    Originator: NO

    I have the same issue. On issuing opreport I get the same error.
    And restarting oprofiled doesn't fix the issue.
    If there is a temporary workaround that I can employ to continue using oprofile,
    it would be great.

    oprofile version: 0.9.3
    kernel: 2.6.25-ARCH
    Distro: Archlinux

  • Sujith

    Logged In: YES
    Originator: NO

    Ok, I deleted /var/lib/oprofile/samples/current and restarted oprofiled, it worked.

  • Gisle Dankel
    Gisle Dankel

    Logged In: YES
    Originator: NO

    The problem in in opd_anon.c, where proc/<pid>/maps is being parsed.
    Some anonymous regions have labels which are interesting to some people, like [vdso], [vsyscall] etc.
    Therefore, the name is kept for anon regions. The problem is that there can be a big delay between when an anon sample is
    taken and when it's processed by the daemon. By that time the process could've exec'ed (changing the memory layout) or done some explicit munmaps / mmaps
    such that the map read from /proc/<pid>/maps now represent a named map and not the anonymous map that existed when the sample was taken.

    Here is a patch that should fix the crash. Samples can still get attributed to the wrong maps because the original maps have disappeared.

    Index: daemon/opd_anon.c

    RCS file: /cvsroot/oprofile/oprofile/daemon/opd_anon.c,v
    retrieving revision 1.9
    diff -r1.9 opd_anon.c
    < /* Note that this actually includes all mappings,
    < * since we want stuff like [heap]
    < */
    > /*
    > * Some anon maps have labels like
    > * [heap], [stack], [vdso], [vsyscall] ...
    > * Keep track of these labels. If a map has no name, call it "anon".
    > * Ignore all mappings starting with "/" (file or shared memory object)
    > */
    < if (ret < 6)
    > if (ret < 6 || name[0] == '/')

  • Logged In: YES
    Originator: NO

    Greg, is it possible for you to reproduce this problem and then verify that gdankel's patch below fixes the problem? I'm getting ready to roll out a new release, and I'd like to close this bug if possible.

  • Logged In: NO

    For what it's worth, gdankel's patch fixed the problem here (I'm the same person adding the comment all the way at the bottom here).

    • status: open --> closed