From: Brent H. <br...@rs...> - 2004-12-06 19:15:43
|
I'm not sure what is triggering this issue, but it's come up several times now. After collecting data and using opreport for some time - and getting good reports - I start seeing the following error: # opreport opreport error: /var/lib/oprofile/samples/current/{kern}/af_packet/{dep}/{kern}/af_packet/CPU_CYCLES.100000.0.all.all.all: Invalid argument # Anyone seen this before? Is there a fix? I'm running the 0.8.1 bundle on an IA64 box with a CPU metric kernel patch + a perfmond patch to allow CPU metrics to be collected. The kernel is a SLES-9-SP-1-Beta3 setup - in case that matters. Any thoughts would be appreciated - fixes even more! :) thanks, brent |
From: Rekha SR <re...@gm...> - 2012-08-01 02:25:06
|
Hello Friends, I am new for Oprofile. If type opreport, i am getting an error message. I ran opcontrol --dump. But still getting the same message. Do you have idea? # opreport opreport error: No sample file found: try running opcontrol --dump or specify a session containing sample files -- Thank you |
From: Maynard J. <may...@us...> - 2012-08-01 12:28:39
|
On 07/31/2012 09:24 PM, Rekha SR wrote: > Hello Friends, > > I am new for Oprofile. > > If type opreport, i am getting an error message. > > I ran opcontrol --dump. But still getting the same message. > > Do you have idea? > > > # opreport > opreport error: No sample file found: try running opcontrol --dump > or specify a session containing sample files See http://oprofile.sourceforge.net/doc/results.html#no-results. -Maynard > > > -- > > Thank you > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: John L. <le...@mo...> - 2004-12-07 13:57:17
|
On Mon, Dec 06, 2004 at 01:14:08PM -0600, Brent Henderson wrote: > opreport error: > /var/lib/oprofile/samples/current/{kern}/af_packet/{dep}/{kern}/af_packet/CPU_CYCLES.100000.0.all.all.all: Invalid argument > # > > Anyone seen this before? Is there a fix? truss opreport to see where EINVAL is coming from > I'm running the 0.8.1 bundle on an IA64 box with a CPU metric kernel > patch + a perfmond patch to allow CPU metrics to be collected. The > kernel is a SLES-9-SP-1-Beta3 setup - in case that matters. You really shouldn't be reporting oprofile bugs without using a standard Linus kernel, but it probably doesn't matter here... What exactly are your "CPU metric" patches?? john |
From: Brent H. <br...@rs...> - 2004-12-08 17:23:18
|
John Levon wrote: > On Mon, Dec 06, 2004 at 01:14:08PM -0600, Brent Henderson wrote: > > >>opreport error: >>/var/lib/oprofile/samples/current/{kern}/af_packet/{dep}/{kern}/af_packet/CPU_CYCLES.100000.0.all.all.all: Invalid argument >># >> >>Anyone seen this before? Is there a fix? > > > truss opreport to see where EINVAL is coming from > > The whole log is huge, hopefully this will be enough info - if I read this right, close(4) is returning 0, then the 'opreport error' came out before any other calls were logged. . . . open("/usr/local/share/oprofile//ia64/itanium2/unit_masks", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=9144, ...}) = 0 mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2000000000700000 read(4, "# IA-64 Itanium 2 possible unit "..., 16384) = 9144 read(4, "", 16384) = 0 close(4) = 0 munmap(0x2000000000700000, 65536) = 0 open("/usr/local/share/oprofile//ia64/itanium2/events", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=24197, ...}) = 0 mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2000000000700000 read(4, "# IA-64 Itanium 2 events\n\n# IA64"..., 16384) = 16384 read(4, "ne is available\nevent:0xb8 count"..., 16384) = 7813 read(4, "", 16384) = 0 close(4) = 0 munmap(0x2000000000700000, 65536) = 0 open("/var/lib/oprofile/samples/current/{kern}/no-vmlinux/{dep}/{kern}/no-vmlinux/CPU_CYCLES.10000.0.all.all.all", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=82024, ...}) = 0 mmap(NULL, 82024, PROT_READ, MAP_SHARED, 4, 0) = 0x2000000000700000 munmap(0x2000000000700000, 82024) = 0 close(4) = 0 open("/var/lib/oprofile/samples/current/{kern}/af_packet/{dep}/{kern}/af_packet/CPU_CYCLES.100000.0.all.all.all", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0 mmap(NULL, 4084, PROT_READ, MAP_SHARED, 4, 0) = 0x2000000000700000 munmap(0x2000000000700000, 4084) = 0 close(4) = 0 write(2, "o", 1o) = 1 write(2, "p", 1p) = 1 write(2, "r", 1r) = 1 write(2, "e", 1e) = 1 write(2, "p", 1p) = 1 write(2, "o", 1o) = 1 write(2, "r", 1r) = 1 write(2, "t", 1t) = 1 write(2, " ", 1 ) = 1 write(2, "e", 1e) = 1 write(2, "r", 1r) = 1 write(2, "r", 1r) = 1 write(2, "o", 1o) = 1 write(2, "r", 1r) = 1 write(2, ":", 1:) = 1 . . . I set a breakpoint at exit of opreport, but it claimed the stack was hosed, so it is probably not useful, but here it is: Breakpoint 2, 0x2000000000441090 in exit () from /lib/tls/libc.so.6.1 (gdb) bt #0 0x2000000000441090 in exit () from /lib/tls/libc.so.6.1 #1 0x2000000000415830 in __libc_start_main () from /lib/tls/libc.so.6.1 #2 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) (gdb) Seems like the code should be way past __libc_start_main at this point. >>I'm running the 0.8.1 bundle on an IA64 box with a CPU metric kernel >>patch + a perfmond patch to allow CPU metrics to be collected. The >>kernel is a SLES-9-SP-1-Beta3 setup - in case that matters. > > > You really shouldn't be reporting oprofile bugs without using a standard > Linus kernel, but it probably doesn't matter here... > I've rebuild a new system with the SLES9 bits, and the issue still shows up. (I just wanted to rule out the Beta OS I was using.) > What exactly are your "CPU metric" patches?? > > john > The kernel patch was for enabling metrics on ia64 processors. Here's a link: http://sourceforge.net/mailarchive/message.php?msg_id=9286819 The oprofiled update was for a problem with sched_setaffinity - I'm using a very recent copy of opd_perfmon.c that addresses this issue. All the other code is stock. thanks, brent |
From: John L. <le...@mo...> - 2004-12-08 19:19:02
|
On Wed, Dec 08, 2004 at 11:21:36AM -0600, Brent Henderson wrote: > The whole log is huge, hopefully this will be enough info - if I read > this right, close(4) is returning 0, then the 'opreport error' came out > before any other calls were logged. The EINVAL is being set internally. If you want to investigate, grep oprofile sources for EINVAL and add printf()s. You should then be able to see what path is causing the EINVAL and can proceed from there. My suspect would be libdb/ john |
From: Brent H. <br...@rs...> - 2004-12-13 19:09:54
|
Hmm, more digging shows that is some memory corruption - possibly caused by popt or stl code. Hopefully I'm not 'off by one' in my debugging sequence. This might also explain why I'm still in __libc_start_main - static initializers - right? (The report was generated using an old copy of libdbmalloc I had lying around.) SLES9 has libpopt v 1.7 which appears to be the latest version although there appears to be little activity since 20-Sep-2002. Maybe I have the wrong source link though, I'm looking at: http://freshmeat.net/projects/popt/ brent shepton:/home/brent/oprofile-0.8.1/pp # ./opreport MALLOC Warning from free(): Data has overrun beyond requested number of bytes This error is *probably* associated with the following allocation: A call to malloc for 192 bytes in an unknown file. This was the 11th call to malloc. MALLOC Warning from free(): Data has overrun beyond requested number of bytes This error is *probably* associated with the following allocation: A call to malloc for 384 bytes in an unknown file. This was the 14th call to malloc. MALLOC Warning from free(): Data has overrun beyond requested number of bytes This error is *probably* associated with the following allocation: A call to malloc for 768 bytes in an unknown file. This was the 19th call to malloc. Segmentation fault shepton:/home/brent/oprofile-0.8.1/pp # gdb ./opreport GNU gdb 6.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ia64-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) b malloc Breakpoint 1 at 0x4000000000032911: file malloc.c, line 99. (gdb) c The program is not being run. (gdb) R Starting program: /home/brent/oprofile-0.8.1/pp/opreport Breakpoint 1, malloc (size=24) at malloc.c:99 99 return( debug_malloc(NULL,-1,size) ); Current language: auto; currently c (gdb) b debug_malloc Breakpoint 2 at 0x4000000000032970: file malloc.c, line 126. (gdb) d 1 (gdb) c Continuing. Breakpoint 2, debug_malloc (file=0x0, line=-1, size=24) at malloc.c:126 126 call_counter++; (gdb) d 2 (gdb) l 121 static IDTYPE call_counter; 122 123 /* 124 * increment the counter for the number of calls to this func. 125 */ 126 call_counter++; 127 128 return( DBFmalloc("malloc",M_T_MALLOC,call_counter,file,line,size) ); 129 130 } /* debug_malloc(... */ (gdb) b 128 Breakpoint 3 at 0x4000000000032982: file malloc.c, line 128. (gdb) condition Display all 13102 possibilities? (y or n) (gdb) help condition Specify breakpoint number N to break only if COND is true. Usage is `condition N COND', where N is an integer and COND is an expression to be evaluated whenever breakpoint N is reached. (gdb) condition 3 call_counter==11 (gdb) c Continuing. Breakpoint 3, debug_malloc (file=0x0, line=-1, size=192) at malloc.c:128 128 return( DBFmalloc("malloc",M_T_MALLOC,call_counter,file,line,size) ); (gdb) print call_counter $1 = 11 (gdb) bt #0 debug_malloc (file=0x0, line=-1, size=192) at malloc.c:128 #1 0x4000000000032930 in malloc (size=192) at malloc.c:99 #2 0x20000000002b6bf0 in operator new () from /usr/lib/libstdc++.so.5 #3 0x2000000000290650 in std::__default_alloc_template<true, 0>::allocate () from /usr/lib/libstdc++.so.5 #4 0x40000000000e17c0 in std::vector<poptOption, std::allocator<poptOption> >::_M_insert_aux (this=0x60000000000057e0, __position= {<std::iterator<std::random_access_iterator_tag, poptOption, long, poptOption*, poptOption&>> = {<No data fields>}, _M_current = 0x6000000000011150}, __x=@0x60000fffffffafd0) at vector.tcc:223 #5 0x40000000000dfba0 in option_base (this=0x6000000000012190, name=0x4000000000125038 "threshold", short_name=116 't', help=0x4000000000125048 "minimum percentage needed to produce output", arg_help=0x4000000000125078 "percent", data=0x60000000000121a0, popt_flags=1) at popt_options.cpp:246 #6 0x40000000000dff20 in option_imp (this=0x6000000000012190, val=@0x60000000000051b8, name=0x4000000000125038 "threshold", short_name=116 't', help=0x4000000000125048 "minimum percentage needed to produce output", arg_help=0x4000000000125078 "percent") at popt_options.cpp:288 #7 0x40000000000dffd0 in option<std::string> (this=0x6000000000005660, value=@0x60000000000051b8, name=0x4000000000125038 "threshold", short_name=116 't', ---Type <return> to continue, or q <return> to quit--- help=0x4000000000125048 "minimum percentage needed to produce output", arg_help=0x4000000000125078 "percent") at popt_options.cpp:229 #8 0x400000000002d780 in global constructors keyed to _ZN34_GLOBAL__N_common_option.cppgk6poM9thresholdE () at common_option.cpp:44 #9 0x4000000000124670 in __do_global_ctors_aux () #10 0x40000000001245e0 in __libc_csu_init () at elf-init.c:67 #11 0x2000000000415710 in __libc_start_main () from /lib/tls/libc.so.6.1 #12 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) (gdb) condition 3 call_counter==14 (gdb) c Continuing. Breakpoint 3, debug_malloc (file=0x0, line=-1, size=384) at malloc.c:128 128 return( DBFmalloc("malloc",M_T_MALLOC,call_counter,file,line,size) ); (gdb) bt #0 debug_malloc (file=0x0, line=-1, size=384) at malloc.c:128 #1 0x4000000000032930 in malloc (size=384) at malloc.c:99 #2 0x20000000002b6bf0 in operator new () from /usr/lib/libstdc++.so.5 #3 0x2000000000290650 in std::__default_alloc_template<true, 0>::allocate () from /usr/lib/libstdc++.so.5 #4 0x40000000000e17c0 in std::vector<poptOption, std::allocator<poptOption> >::_M_insert_aux (this=0x60000000000057e0, __position= {<std::iterator<std::random_access_iterator_tag, poptOption, long, poptOption*, poptOption&>> = {<No data fields>}, _M_current = 0x6000000000012300}, __x=@0x60000fffffffafc0) at vector.tcc:223 #5 0x40000000000dfba0 in option_base (this=0x6000000000012440, name=0x40000000001247b0 "output-file", short_name=111 'o', help=0x40000000001247c0 "output to the given filename", arg_help=0x40000000001247e0 "file", data=0x6000000000012450, popt_flags=1) at popt_options.cpp:246 #6 0x40000000000dff20 in option_imp (this=0x6000000000012440, val=@0x6000000000005188, name=0x40000000001247b0 "output-file", short_name=111 'o', help=0x40000000001247c0 "output to the given filename", arg_help=0x40000000001247e0 "file") at popt_options.cpp:288 #7 0x40000000000dffd0 in option<std::string> (this=0x6000000000005300, value=@0x6000000000005188, name=0x40000000001247b0 "output-file", short_name=111 'o', ---Type <return> to continue, or q <return> to quit--- help=0x40000000001247c0 "output to the given filename", arg_help=0x40000000001247e0 "file") at popt_options.cpp:229 #8 0x4000000000020f30 in global constructors keyed to _ZN37_GLOBAL__N_opreport_options.cppugaq4D7outfileE () at opreport_options.cpp:95 #9 0x4000000000124670 in __do_global_ctors_aux () #10 0x40000000001245e0 in __libc_csu_init () at elf-init.c:67 #11 0x2000000000415710 in __libc_start_main () from /lib/tls/libc.so.6.1 #12 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) (gdb) condition 3 call_counter==19 (gdb) c Continuing. MALLOC Warning from free(): Data has overrun beyond requested number of bytes This error is *probably* associated with the following allocation: A call to malloc for 192 bytes in an unknown file. This was the 11th call to malloc. Breakpoint 3, debug_malloc (file=0x0, line=-1, size=768) at malloc.c:128 128 return( DBFmalloc("malloc",M_T_MALLOC,call_counter,file,line,size) ); (gdb) bt #0 debug_malloc (file=0x0, line=-1, size=768) at malloc.c:128 #1 0x4000000000032930 in malloc (size=768) at malloc.c:99 #2 0x20000000002b6bf0 in operator new () from /usr/lib/libstdc++.so.5 #3 0x2000000000290650 in std::__default_alloc_template<true, 0>::allocate () from /usr/lib/libstdc++.so.5 #4 0x40000000000e17c0 in std::vector<poptOption, std::allocator<poptOption> >::_M_insert_aux (this=0x60000000000057e0, __position= {<std::iterator<std::random_access_iterator_tag, poptOption, long, poptOption*, poptOption&>> = {<No data fields>}, _M_current = 0x6000000000012670}, __x=@0x60000fffffffafc0) at vector.tcc:223 #5 0x40000000000dfba0 in option_base (this=0x6000000000012860, name=0x4000000000124870 "exclude-dependent", short_name=120 'x', help=0x4000000000124888 "exclude libs, kernel, and module samples for applications", arg_help=0x0, data=0x6000000000012878, popt_flags=0) at popt_options.cpp:246 #6 0x40000000000e0420 in option_imp (this=0x6000000000012860, val=@0x6000000000005199, name=0x4000000000124870 "exclude-dependent", short_name=120 'x', help=0x4000000000124888 "exclude libs, kernel, and module samples for applications") at popt_options.cpp:261 #7 0x40000000000e04d0 in option (this=0x6000000000005320, value=@0x6000000000005199, name=0x4000000000124870 "exclude-dependent", short_name=120 'x', ---Type <return> to continue, or q <return> to quit--- help=0x4000000000124888 "exclude libs, kernel, and module samples for applications") at popt_options.cpp:209 #8 0x4000000000021040 in global constructors keyed to _ZN37_GLOBAL__N_opreport_options.cppugaq4D7outfileE () at opreport_options.cpp:95 #9 0x4000000000124670 in __do_global_ctors_aux () #10 0x40000000001245e0 in __libc_csu_init () at elf-init.c:67 #11 0x2000000000415710 in __libc_start_main () from /lib/tls/libc.so.6.1 #12 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) (gdb) |
From: Andy F. <afl...@fr...> - 2004-12-07 18:07:14
|
I've seen that before. It looks like the old opreport files are corrupt, or ...something. Anyway, I found that opcontrol --reset fixes the problem. On Dec 6, 2004, at 13:14, Brent Henderson wrote: > I'm not sure what is triggering this issue, but it's come up > several times now. After collecting data and using opreport > for some time - and getting good reports - I start seeing the > following error: > > # opreport > opreport error: > /var/lib/oprofile/samples/current/{kern}/af_packet/{dep}/{kern}/ > af_packet/CPU_CYCLES.100000.0.all.all.all: Invalid argument > # > > Anyone seen this before? Is there a fix? > > I'm running the 0.8.1 bundle on an IA64 box with a CPU metric kernel > patch + a perfmond patch to allow CPU metrics to be collected. The > kernel is a SLES-9-SP-1-Beta3 setup - in case that matters. > > Any thoughts would be appreciated - fixes even more! :) > > thanks, > > brent > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > Andy Fleming |
From: <al...@fc...> - 2004-12-07 18:17:56
|
On Tue, Dec 07, 2004 at 12:03:58PM -0600, Andy Fleming wrote: > I've seen that before. It looks like the old opreport files are > corrupt, or ...something. Anyway, I found that opcontrol --reset fixes > the problem. Yes, but 'opcontrol --reset' just erases your old profile data files. In this case, the error seems to be repeating with new files gathered. Thanks, Alex |