(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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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
145,147c145,150
< /* 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)
> */
151c154,155
< if (ret < 6)
---
>
> if (ret < 6 || name[0] == '/')
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: NO
I am hitting this too (oprofile 0.9.3, 2.6.24.4 kernel). The basic cause seems to be the presence of files like:
/var/lib/oprofile/samples/current/{root}/usr/bin/sudo/{dep}/{anon:/bin/bash}/27091.0x8048000.0x80e6000/CPU_CLK_UNHALTED.100000.0.all.all.all
(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.
Logged In: YES
user_id=1853302
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
Logged In: YES
user_id=1853302
Originator: NO
Ok, I deleted /var/lib/oprofile/samples/current and restarted oprofiled, it worked.
Logged In: YES
user_id=2083179
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
145,147c145,150
< /* 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)
> */
151c154,155
< if (ret < 6)
---
>
> if (ret < 6 || name[0] == '/')
Logged In: YES
user_id=1355714
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.
Thanks.
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).