From: Konstantin S. <kon...@gm...> - 2008-02-12 11:43:56
|
Hello, I am getting an error 'opreport error: basic_string::erase' from opreport. When trying to get a flat profile this error occurs rarely (<5% of times). When trying to get a callgraph (which does not seem to work on x86_64, see another thread) this error appears often (>50% of times when profiling a 32-bit executabl, always for 64-bit executables). I tried oprofile 0.9.2, 0.9.3 and 0.9.4cvs (Feb 4 2008). Linux is 2.6.18.5 mixed64-32 The issue has been discussed already: see http://marc.info/?l=oprofile-list&m=119188287310136&w=2 Thanks, --kcc |
From: SourceForge.net <no...@so...> - 2008-04-01 03:04:33
|
Bugs item #1930788, was opened at 2008-04-01 03:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: opreport error: basic_string::erase Initial Comment: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 |
From: SourceForge.net <no...@so...> - 2008-04-07 22:39:20
|
Bugs item #1930788, was opened at 2008-03-31 20:04 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: opreport error: basic_string::erase Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-04-07 15:39 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 |
From: SourceForge.net <no...@so...> - 2008-05-05 15:35:14
|
Bugs item #1930788, was opened at 2008-04-01 08:34 Message generated for change (Comment added) made by sacamano You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: opreport error: basic_string::erase Initial Comment: 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. ---------------------------------------------------------------------- Comment By: sacamano (sacamano) Date: 2008-05-05 20:59 Message: 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 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-04-08 04:09 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 |
From: SourceForge.net <no...@so...> - 2008-05-05 16:02:51
|
Bugs item #1930788, was opened at 2008-04-01 08:34 Message generated for change (Comment added) made by sacamano You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: opreport error: basic_string::erase Initial Comment: 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. ---------------------------------------------------------------------- Comment By: sacamano (sacamano) Date: 2008-05-05 21:32 Message: Logged In: YES user_id=1853302 Originator: NO Ok, I deleted /var/lib/oprofile/samples/current and restarted oprofiled, it worked. ---------------------------------------------------------------------- Comment By: sacamano (sacamano) Date: 2008-05-05 20:59 Message: 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 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-04-08 04:09 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 |
From: SourceForge.net <no...@so...> - 2008-05-09 17:55:49
|
Bugs item #1930788, was opened at 2008-03-31 20:04 Message generated for change (Comment added) made by gdankel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: opreport error: basic_string::erase Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Gisle Dankel (gdankel) Date: 2008-05-09 11:55 Message: 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] == '/') ---------------------------------------------------------------------- Comment By: sacamano (sacamano) Date: 2008-05-05 10:02 Message: Logged In: YES user_id=1853302 Originator: NO Ok, I deleted /var/lib/oprofile/samples/current and restarted oprofiled, it worked. ---------------------------------------------------------------------- Comment By: sacamano (sacamano) Date: 2008-05-05 09:29 Message: 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 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-04-07 16:39 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 |
From: SourceForge.net <no...@so...> - 2008-05-20 16:28:07
|
Bugs item #1930788, was opened at 2008-03-31 22:04 Message generated for change (Comment added) made by maynardj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: opreport error: basic_string::erase Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Maynard Johnson (maynardj) Date: 2008-05-20 11:28 Message: 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. ---------------------------------------------------------------------- Comment By: Gisle Dankel (gdankel) Date: 2008-05-09 12:55 Message: 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] == '/') ---------------------------------------------------------------------- Comment By: sacamano (sacamano) Date: 2008-05-05 11:02 Message: Logged In: YES user_id=1853302 Originator: NO Ok, I deleted /var/lib/oprofile/samples/current and restarted oprofiled, it worked. ---------------------------------------------------------------------- Comment By: sacamano (sacamano) Date: 2008-05-05 10:29 Message: 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 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-04-07 17:39 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 |
From: SourceForge.net <no...@so...> - 2008-06-22 05:57:05
|
Bugs item #1930788, was opened at 2008-04-01 03:04 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: opreport error: basic_string::erase Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-06-21 00:47 Message: 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). ---------------------------------------------------------------------- Comment By: Maynard Johnson (maynardj) Date: 2008-05-20 16:28 Message: 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. ---------------------------------------------------------------------- Comment By: Gisle Dankel (gdankel) Date: 2008-05-09 17:55 Message: 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] == '/') ---------------------------------------------------------------------- Comment By: sacamano (sacamano) Date: 2008-05-05 16:02 Message: Logged In: YES user_id=1853302 Originator: NO Ok, I deleted /var/lib/oprofile/samples/current and restarted oprofiled, it worked. ---------------------------------------------------------------------- Comment By: sacamano (sacamano) Date: 2008-05-05 15:29 Message: 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 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-04-07 22:39 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 |
From: SourceForge.net <no...@so...> - 2008-07-17 23:52:51
|
Bugs item #1930788, was opened at 2008-03-31 22:04 Message generated for change (Settings changed) made by maynardj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: opreport error: basic_string::erase Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-06-20 19:47 Message: 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). ---------------------------------------------------------------------- Comment By: Maynard Johnson (maynardj) Date: 2008-05-20 11:28 Message: 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. ---------------------------------------------------------------------- Comment By: Gisle Dankel (gdankel) Date: 2008-05-09 12:55 Message: 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] == '/') ---------------------------------------------------------------------- Comment By: sacamano (sacamano) Date: 2008-05-05 11:02 Message: Logged In: YES user_id=1853302 Originator: NO Ok, I deleted /var/lib/oprofile/samples/current and restarted oprofiled, it worked. ---------------------------------------------------------------------- Comment By: sacamano (sacamano) Date: 2008-05-05 10:29 Message: 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 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-04-07 17:39 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1930788&group_id=16191 |