I have figured out a possible source of this problem. On my system,
there was the following path:
/var/lib/oprofile/samples/current/{root}/usr/bin/env/{dep}/{anon:/home/...
I do not know how such a path came to be (possibly an earlier
differently buggy version of oprofile?), but when examining the
directory tree, opreport encounters "{anon:" when it expects
"{anon:<something>}". This gets passed to parse_anon
(libpp/parse_filename.cpp:78) which contains the following lines:
name.erase(0,6); // Get rid of "{anon:
name.erase(name.size() - 1,1); // Get rid of the trailing '}'
Now, since name is just "{anon:", it will be empty after the first line.
name.size() will return 0, and subtracting one will wrap around and make
it a Big Number. Thus the second erase will throw for an out-of-range
offset.
After getting rid of the corrupt samples directory, everything works
well again.
I'm not sure if anything needs to be done about this, since I couldn't
get oprofiled to produce such invalid paths anymore with a few tests.
I have oprofile 0.9.3-2 and kernel 2.6.25-rc8
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
