* Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 @ 2009-04-27 11:49 Pavan Naregundi 2009-04-27 14:43 ` Mark Wielaard 0 siblings, 1 reply; 15+ messages in thread From: Pavan Naregundi @ 2009-04-27 11:49 UTC (permalink / raw) To: systemtap Hi, Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 Arch: ppc64 Please contact me, for any other details. === systemtap Summary === # of expected passes 647 # of unexpected failures 63 # of unexpected successes 9 # of expected failures 195 # of unknown successes 1 # of known failures 6 # of untested testcases 50 # of unsupported tests 2 Unexpected failures ============================= FAIL: LOCAL1 (0) FAIL: STRUCT1 (0) FAIL: backtrace (1 0) FAIL: backtrace-unwindsyms (1 0) FAIL: systemtap.base/cast.stp FAIL: debugpath-bad (eof) FAIL: debugpath-good (eof) FAIL: gtod (9) FAIL: MAXACTIVE01 compilation FAIL: MAXACTIVE02 compilation FAIL: conditional probes (0) FAIL: OVERLOAD1 compilation FAIL: OVERLOAD2 compilation FAIL: OVERLOAD3 compilation FAIL: compiling sdt.c "" FAIL: compiling sdt.c additional_flags=-std=gnu89 FAIL: compiling sdt.c additional_flags=-ansi FAIL: compiling sdt.c additional_flags=-pedantic FAIL: compiling sdt.c additional_flags=-ansi additional_flags=-pedantic FAIL: compiling sdt.c additional_flags=-O2 FAIL: compiling sdt.c additional_flags="-O3" FAIL: static_uprobes compiling C -g FAIL: stmtvars - .function FAIL: system_func (0,0,0) FAIL: backtrace of yyy_func2 (1) FAIL: print_stack of yyy_func2 (1) FAIL: backtrace of yyy_func3 (1) FAIL: print_stack of yyy_func3 (1) FAIL: backtrace of yyy_func4 (1) FAIL: print_stack of yyy_func4 (1) FAIL: integer function arguments -- numeric FAIL: unsigned function arguments -- numeric FAIL: long function arguments -- numeric FAIL: int64 function arguments -- numeric FAIL: char function arguments -- numeric FAIL: string function arguments -- numeric FAIL: integer function arguments -- numeric --kelf --ignore-dwarf FAIL: unsigned function arguments -- numeric --kelf --ignore-dwarf FAIL: long function arguments -- numeric --kelf --ignore-dwarf FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf FAIL: char function arguments -- numeric --kelf --ignore-dwarf FAIL: string function arguments -- numeric --kelf --ignore-dwarf FAIL: systemtap.examples/general/para-callgraph build FAIL: systemtap.examples/general/para-callgraph run FAIL: buildok/maxactive01.stp FAIL: buildok/signal-all-probes.stp FAIL: buildok/thirteen.stp FAIL: semok/thirtytwo.stp FAIL: semok/twentyeight.stp FAIL: semok/twentyfour.stp FAIL: semok/twentynine.stp FAIL: semok/twentyseven.stp FAIL: systemtap.printf/bin6.stp FAIL: systemtap.stress/current.stp shutdown (eof) FAIL: 64-bit acct FAIL: 64-bit net1 FAIL: 64-bit readwrite FAIL: 64-bit signal FAIL: 32-bit acct FAIL: 32-bit net1 FAIL: 32-bit readwrite FAIL: 32-bit signal FAIL: 32-bit statfs ================ Thanks Pavan ------------------------------------------------------------------- Linux Technology Center IBM India Software Labs Bangalore ------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-27 11:49 Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 Pavan Naregundi @ 2009-04-27 14:43 ` Mark Wielaard 2009-04-28 5:11 ` Pavan Naregundi ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Mark Wielaard @ 2009-04-27 14:43 UTC (permalink / raw) To: Pavan Naregundi; +Cc: systemtap Hi Pavan, On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote: > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 > Arch: ppc64 > > Please contact me, for any other details. Thanks for testing this combination. Which elfutils version did you use? > Unexpected failures > ============================= > FAIL: LOCAL1 (0) I have seen this fail sporadically, is it failing always for you? > FAIL: STRUCT1 (0) Could you post the relevant part of the testsuite/systemtap.log? > FAIL: backtrace (1 0) > FAIL: backtrace-unwindsyms (1 0) This is http://sourceware.org/bugzilla/show_bug.cgi?id=6961 "backtrace from non-pt_regs probe context" > FAIL: systemtap.base/cast.stp > FAIL: debugpath-bad (eof) > FAIL: debugpath-good (eof) Could you post the relevant parts of the testsuite/systemtap.log for the above failures? > FAIL: gtod (9) This is probably http://sourceware.org/bugzilla/show_bug.cgi?id=5094 "gtod.exp fails on ppc64/i386" > FAIL: MAXACTIVE01 compilation > FAIL: MAXACTIVE02 compilation > FAIL: conditional probes (0) > FAIL: OVERLOAD1 compilation > FAIL: OVERLOAD2 compilation > FAIL: OVERLOAD3 compilation Could you post the relevant parts of the testsuite/systemtap.log for the above failures? > FAIL: compiling sdt.c "" > FAIL: compiling sdt.c additional_flags=-std=gnu89 > FAIL: compiling sdt.c additional_flags=-ansi > FAIL: compiling sdt.c additional_flags=-pedantic > FAIL: compiling sdt.c additional_flags=-ansi additional_flags=-pedantic > FAIL: compiling sdt.c additional_flags=-O2 > FAIL: compiling sdt.c additional_flags="-O3" > FAIL: static_uprobes compiling C -g That probably means the sdt.h header doesn't compile on ppc. Could you see if testsuite/systemtap.log gives more hints about what is wrong? What gcc version are you using? > FAIL: stmtvars - .function > FAIL: system_func (0,0,0) Could you post the relevant parts of the testsuite/systemtap.log for the above failures? > FAIL: backtrace of yyy_func2 (1) > FAIL: print_stack of yyy_func2 (1) > FAIL: backtrace of yyy_func3 (1) > FAIL: print_stack of yyy_func3 (1) > FAIL: backtrace of yyy_func4 (1) > FAIL: print_stack of yyy_func4 (1) These might need support for the dwarf unwinder on ppc to provide more accurate backtraces. http://sourceware.org/ml/systemtap/2009-q2/msg00307.html > FAIL: integer function arguments -- numeric > FAIL: unsigned function arguments -- numeric > FAIL: long function arguments -- numeric > FAIL: int64 function arguments -- numeric > FAIL: char function arguments -- numeric > FAIL: string function arguments -- numeric > FAIL: integer function arguments -- numeric --kelf --ignore-dwarf > FAIL: unsigned function arguments -- numeric --kelf --ignore-dwarf > FAIL: long function arguments -- numeric --kelf --ignore-dwarf > FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf > FAIL: char function arguments -- numeric --kelf --ignore-dwarf > FAIL: string function arguments -- numeric --kelf --ignore-dwarf Could you post the relevant parts of the testsuite/systemtap.log for the above failures? > FAIL: systemtap.examples/general/para-callgraph build > FAIL: systemtap.examples/general/para-callgraph run Likewise. > FAIL: buildok/maxactive01.stp > FAIL: buildok/signal-all-probes.stp > FAIL: buildok/thirteen.stp > FAIL: semok/thirtytwo.stp > FAIL: semok/twentyeight.stp > FAIL: semok/twentyfour.stp > FAIL: semok/twentynine.stp > FAIL: semok/twentyseven.stp > FAIL: systemtap.printf/bin6.stp > FAIL: systemtap.stress/current.stp shutdown (eof) Some of these might be solved with an updated elfutils (0.141). At least that was the case for s390. > FAIL: 64-bit acct > FAIL: 64-bit net1 > FAIL: 64-bit readwrite > FAIL: 64-bit signal > FAIL: 32-bit acct > FAIL: 32-bit net1 > FAIL: 32-bit readwrite > FAIL: 32-bit signal > FAIL: 32-bit statfs The net1 failures are http://sourceware.org/bugzilla/show_bug.cgi?id=6991 "accept system call missed on 2.6.27" For the others look in the systemtap.log file and/or try running the tests in testsuite/systemtap.syscall by hand. There is a README there explaining how the tests work and how to use the tcl framework to see how things should match. Thanks, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-27 14:43 ` Mark Wielaard @ 2009-04-28 5:11 ` Pavan Naregundi 2009-04-28 6:02 ` Pavan Naregundi 2009-04-28 6:56 ` Ananth N Mavinakayanahalli 2 siblings, 0 replies; 15+ messages in thread From: Pavan Naregundi @ 2009-04-28 5:11 UTC (permalink / raw) To: Mark Wielaard; +Cc: systemtap Mark Wielaard <mjw@redhat.com> wrote on 04/27/2009 08:12:50 PM: > From: > > Mark Wielaard <mjw@redhat.com> > > To: > > Pavan Naregundi/India/IBM@IBMIN > > Cc: > > systemtap@sourceware.org > > Date: > > 04/27/2009 08:10 PM > > Subject: > > Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 > > Hi Pavan, > > On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote: > > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 > > Arch: ppc64 > > > > Please contact me, for any other details. > > Thanks for testing this combination. Which elfutils version did you use? It is elfutils-0.141.tar.bz2.. > > > Unexpected failures > > ============================= > > FAIL: LOCAL1 (0) > > I have seen this fail sporadically, is it failing always for you? > > > FAIL: STRUCT1 (0) > > Could you post the relevant part of the testsuite/systemtap.log? > > > FAIL: backtrace (1 0) > > FAIL: backtrace-unwindsyms (1 0) > > This is http://sourceware.org/bugzilla/show_bug.cgi?id=6961 > "backtrace from non-pt_regs probe context" > > > FAIL: systemtap.base/cast.stp > > FAIL: debugpath-bad (eof) > > FAIL: debugpath-good (eof) > > Could you post the relevant parts of the testsuite/systemtap.log for the > above failures? > > > FAIL: gtod (9) > > This is probably http://sourceware.org/bugzilla/show_bug.cgi?id=5094 > "gtod.exp fails on ppc64/i386" > > > FAIL: MAXACTIVE01 compilation > > FAIL: MAXACTIVE02 compilation > > FAIL: conditional probes (0) > > FAIL: OVERLOAD1 compilation > > FAIL: OVERLOAD2 compilation > > FAIL: OVERLOAD3 compilation > > Could you post the relevant parts of the testsuite/systemtap.log for the > above failures? > > > FAIL: compiling sdt.c "" > > FAIL: compiling sdt.c additional_flags=-std=gnu89 > > FAIL: compiling sdt.c additional_flags=-ansi > > FAIL: compiling sdt.c additional_flags=-pedantic > > FAIL: compiling sdt.c additional_flags=-ansi additional_flags=-pedantic > > FAIL: compiling sdt.c additional_flags=-O2 > > FAIL: compiling sdt.c additional_flags="-O3" > > FAIL: static_uprobes compiling C -g > > That probably means the sdt.h header doesn't compile on ppc. > Could you see if testsuite/systemtap.log gives more hints about what is > wrong? What gcc version are you using? > > > FAIL: stmtvars - .function > > FAIL: system_func (0,0,0) > > Could you post the relevant parts of the testsuite/systemtap.log for the > above failures? > > > FAIL: backtrace of yyy_func2 (1) > > FAIL: print_stack of yyy_func2 (1) > > FAIL: backtrace of yyy_func3 (1) > > FAIL: print_stack of yyy_func3 (1) > > FAIL: backtrace of yyy_func4 (1) > > FAIL: print_stack of yyy_func4 (1) > > These might need support for the dwarf unwinder on ppc to provide more > accurate backtraces. > http://sourceware.org/ml/systemtap/2009-q2/msg00307.html > > > FAIL: integer function arguments -- numeric > > FAIL: unsigned function arguments -- numeric > > FAIL: long function arguments -- numeric > > FAIL: int64 function arguments -- numeric > > FAIL: char function arguments -- numeric > > FAIL: string function arguments -- numeric > > FAIL: integer function arguments -- numeric --kelf --ignore-dwarf > > FAIL: unsigned function arguments -- numeric --kelf --ignore-dwarf > > FAIL: long function arguments -- numeric --kelf --ignore-dwarf > > FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf > > FAIL: char function arguments -- numeric --kelf --ignore-dwarf > > FAIL: string function arguments -- numeric --kelf --ignore-dwarf > > Could you post the relevant parts of the testsuite/systemtap.log for the > above failures? > > > FAIL: systemtap.examples/general/para-callgraph build > > FAIL: systemtap.examples/general/para-callgraph run > > Likewise. > > > FAIL: buildok/maxactive01.stp > > FAIL: buildok/signal-all-probes.stp > > FAIL: buildok/thirteen.stp > > FAIL: semok/thirtytwo.stp > > FAIL: semok/twentyeight.stp > > FAIL: semok/twentyfour.stp > > FAIL: semok/twentynine.stp > > FAIL: semok/twentyseven.stp > > FAIL: systemtap.printf/bin6.stp > > FAIL: systemtap.stress/current.stp shutdown (eof) > > > Some of these might be solved with an updated elfutils (0.141). At least > that was the case for s390. > > > FAIL: 64-bit acct > > FAIL: 64-bit net1 > > FAIL: 64-bit readwrite > > FAIL: 64-bit signal > > FAIL: 32-bit acct > > FAIL: 32-bit net1 > > FAIL: 32-bit readwrite > > FAIL: 32-bit signal > > FAIL: 32-bit statfs > > The net1 failures are > http://sourceware.org/bugzilla/show_bug.cgi?id=6991 > "accept system call missed on 2.6.27" > > For the others look in the systemtap.log file and/or try running the > tests in testsuite/systemtap.syscall by hand. There is a README there > explaining how the tests work and how to use the tcl framework to see > how things should match. > > Thanks, > > Mark > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-27 14:43 ` Mark Wielaard 2009-04-28 5:11 ` Pavan Naregundi @ 2009-04-28 6:02 ` Pavan Naregundi 2009-04-28 6:07 ` Ananth N Mavinakayanahalli ` (2 more replies) 2009-04-28 6:56 ` Ananth N Mavinakayanahalli 2 siblings, 3 replies; 15+ messages in thread From: Pavan Naregundi @ 2009-04-28 6:02 UTC (permalink / raw) To: Mark Wielaard; +Cc: systemtap Mark Wielaard <mjw@redhat.com> wrote on 04/27/2009 08:12:50 PM: > From: > > Mark Wielaard <mjw@redhat.com> > > To: > > Pavan Naregundi/India/IBM@IBMIN > > Cc: > > systemtap@sourceware.org > > Date: > > 04/27/2009 08:10 PM > > Subject: > > Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 > > Hi Pavan, > > On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote: > > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 > > Arch: ppc64 > > > > Please contact me, for any other details. > > Thanks for testing this combination. Which elfutils version did you use? elfutils-0.141 > > > Unexpected failures > > ============================= > > FAIL: LOCAL1 (0) > > I have seen this fail sporadically, is it failing always for you? I have seen this every time. > > > FAIL: STRUCT1 (0) > > Could you post the relevant part of the testsuite/systemtap.log? Running /home/pavan/systemtap/src/testsuite/systemtap.base/alternatives.exp ... starting stap -vu -p2 -e { probe kernel.function("sys_getrlimit") { x = $z; } } Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real ms.^M Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real ms.^M wait results: 15196 exp6 0 1 FAIL: LOCAL1 (0) starting stap -vu -p2 -e { probe kernel.function("sys_getrlimit") { rlim_cur = $rlim->rlim_cud; } } Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/345real ms.^M Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/345real ms.^M semantic error: no match while resolving probe point kernel.function("sys_getrlimit")^M semantic error: no match while resolving probe point kernel.function("sys_getrlimit")^M semantic error: no probes found^M Pass 2: analyzed script: semantic error: no probes found^M 0 probe(s), 0 function(s), 0 embed(s), 0 global(s) in 1430usr/960sys/2385real ms.^M Pass 2: analysis failed. Try again with another '--vp 01' option.^M Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 global(s) in 1430usr/960sys/2385real ms.^M Pass 2: analysis failed. Try again with another '--vp 01' option.^M wait results: 15216 exp7 0 1 FAIL: STRUCT1 (0) testcase /home/pavan/systemtap/src/testsuite/systemtap.base/alternatives.exp completed in 114 seconds > > > FAIL: backtrace (1 0) > > FAIL: backtrace-unwindsyms (1 0) > > This is http://sourceware.org/bugzilla/show_bug.cgi?id=6961 > "backtrace from non-pt_regs probe context" > > > FAIL: systemtap.base/cast.stp > > FAIL: debugpath-bad (eof) > > FAIL: debugpath-good (eof) > > Could you post the relevant parts of the testsuite/systemtap.log for the > above failures? Running /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp ... executing: stap /home/pavan/systemtap/src/testsuite/systemtap.base/cast.stp -g FAIL: systemtap.base/cast.stp line 4: expected "tv_sec OK" Got "tv_sec 42 != 0" testcase /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp completed in 8 seconds Running /home/pavan/systemtap/src/testsuite/systemtap.base/debugpath.exp ... semantic error: no match while resolving probe point kernel.function("sys_open")^M semantic error: no probes found^M Pass 2: analysis failed. Try again with another '--vp 01' option.^M FAIL: debugpath-bad (eof) semantic error: no match while resolving probe point kernel.function("sys_open")^M semantic error: no probes found^M Pass 2: analysis failed. Try again with another '--vp 01' option.^M FAIL: debugpath-good (eof) testcase /home/pavan/systemtap/src/testsuite/systemtap.base/debugpath.exp completed in 6 seconds > > > FAIL: gtod (9) > > This is probably http://sourceware.org/bugzilla/show_bug.cgi?id=5094 > "gtod.exp fails on ppc64/i386" > > > FAIL: MAXACTIVE01 compilation > > FAIL: MAXACTIVE02 compilation Running /home/pavan/systemtap/src/testsuite/systemtap.base/maxactive.exp ... executing: stap -v -e { global foo probe kernel.function("sys_select").return, kernel.function("sys_read").return { foo++ } probe timer.ms(5000) { exit(); } probe begin { log("systemtap starting probe"); log("systemtap ending probe");} } Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/346real ms.^M semantic error: no match while resolving probe point kernel.function("sys_select").returnFAIL: MAXACTIVE01 compilation executing: stap -v -e { global foo probe kernel.function("sys_select").return.maxactive(1), kernel.function("sys_read").return.maxactive(1) { foo++ } probe timer.ms(5000) { exit(); } probe begin { log("systemtap starting probe"); log("systemtap ending probe");} } Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/347real ms.^M semantic error: no match while resolving probe point kernel.function("sys_select").return.maxactive(1)FAIL: MAXACTIVE02 compilation PASS: MAXACTIVE03 testcase /home/pavan/systemtap/src/testsuite/systemtap.base/maxactive.exp completed in 6 seconds > > FAIL: conditional probes (0) Running /home/pavan/systemtap/src/testsuite/systemtap.base/onoffprobe.exp ... semantic error: no match while resolving probe point kernel.function("sys_write").return if ((switch) == (1))^M semantic error: no match while resolving probe point kernel.function("sys_write") if ((switch) == (2))^M Pass 2: analysis failed. Try again with another '--vp 01' option.^M FAIL: conditional probes (0) testcase /home/pavan/systemtap/src/testsuite/systemtap.base/onoffprobe.exp completed in 3 seconds > > FAIL: OVERLOAD1 compilation > > FAIL: OVERLOAD2 compilation > > FAIL: OVERLOAD3 compilation testcase /home/pavan/systemtap/src/testsuite/systemtap.base/overflow_error.exp completed in 5 seconds Running /home/pavan/systemtap/src/testsuite/systemtap.base/overload.exp ... Pass 1: parsed user script and 53 library script(s) in 330usr/20sys/353real ms.^M semantic error: no match while resolving probe point kernel.function("sys_read")FAIL: OVERLOAD1 compilation Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real ms.^M semantic error: no match while resolving probe point kernel.function("sys_read")FAIL: OVERLOAD2 compilation Pass 1: parsed user script and 53 library script(s) in 330usr/20sys/350real ms.^M semantic error: no match while resolving probe point kernel.function("sys_read")FAIL: OVERLOAD3 compilation testcase /home/pavan/systemtap/src/testsuite/systemtap.base/overload.exp completed in 9 seconds > > Could you post the relevant parts of the testsuite/systemtap.log for the > above failures? > > > FAIL: compiling sdt.c "" > > FAIL: compiling sdt.c additional_flags=-std=gnu89 > > FAIL: compiling sdt.c additional_flags=-ansi > > FAIL: compiling sdt.c additional_flags=-pedantic > > FAIL: compiling sdt.c additional_flags=-ansi additional_flags=-pedantic > > FAIL: compiling sdt.c additional_flags=-O2 > > FAIL: compiling sdt.c additional_flags="-O3" > > FAIL: static_uprobes compiling C -g Running /home/pavan/systemtap/src/testsuite/systemtap.base/sdt.exp ... Executing on host: gcc /home/pavan/systemtap/src/testsuite/systemtap.base/sdt.c -g -I/home/pavan/systemtap/src/testsuite/../includes/sys -Wall -Wextra -Werror -lm -o sdt.c.exe.0 (timeout = 300) /tmp/ccastHp6.s: Assembler messages:^M /tmp/ccastHp6.s:57: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:116: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:179: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:246: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:317: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:392: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:471: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:554: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:640: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:729: Error: junk at end of line: `0'^M compiler exited with status 1 output is: /tmp/ccastHp6.s: Assembler messages:^M /tmp/ccastHp6.s:57: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:116: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:179: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:246: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:317: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:392: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:471: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:554: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:640: Error: junk at end of line: `0'^M /tmp/ccastHp6.s:729: Error: junk at end of line: `0'^M FAIL: compiling sdt.c "" UNTESTED: sdt "" > > That probably means the sdt.h header doesn't compile on ppc. > Could you see if testsuite/systemtap.log gives more hints about what is > wrong? What gcc version are you using? gcc version 4.3.2 20081007 (Red Hat 4.3.2-6) (GCC) > > > FAIL: stmtvars - .function Running /home/pavan/systemtap/src/testsuite/systemtap.base/stmtvars.exp ... SystemTap translator/driver (version 0.9.7/0.141 non-git sources)^M Copyright (C) 2005-2009 Red Hat, Inc. and others^M This is free software; see the source for copying conditions.^M Session arch: ppc64 release: 2.6.30-rc3-git2^M Created temporary directory "/tmp/stapQQdYat"^M Searched '/usr/local/share/systemtap/tapset/ppc64/*.stp', found 2^M Searched '/usr/local/share/systemtap/tapset/*.stp', found 51^M Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real ms.^M semantic error: no match while resolving probe point kernel.function("sys_open")^M semantic error: no probes found^M Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 global(s) in 1410usr/950sys/2361real ms.^M Pass 2: analysis failed. Try again with another '--vp 01' option.^M Running rm -rf /tmp/stapQQdYat^M pc=0 vars= FAIL: stmtvars - .function SystemTap translator/driver (version 0.9.7/0.141 non-git sources)^M Copyright (C) 2005-2009 Red Hat, Inc. and others^M > > FAIL: system_func (0,0,0) Running /home/pavan/systemtap/src/testsuite/systemtap.base/system_func.exp ... semantic error: no match while resolving probe point kernel.function("sys_open")^M Pass 2: analysis failed. Try again with another '--vp 01' option.^M FAIL: system_func (0,0,0) testcase /home/pavan/systemtap/src/testsuite/systemtap.base/system_func.exp completed in 2 seconds > > Could you post the relevant parts of the testsuite/systemtap.log for the > above failures? > > > FAIL: backtrace of yyy_func2 (1) > > FAIL: print_stack of yyy_func2 (1) > > FAIL: backtrace of yyy_func3 (1) > > FAIL: print_stack of yyy_func3 (1) > > FAIL: backtrace of yyy_func4 (1) > > FAIL: print_stack of yyy_func4 (1) > > These might need support for the dwarf unwinder on ppc to provide more > accurate backtraces. > http://sourceware.org/ml/systemtap/2009-q2/msg00307.html > > > FAIL: integer function arguments -- numeric > > FAIL: unsigned function arguments -- numeric > > FAIL: long function arguments -- numeric > > FAIL: int64 function arguments -- numeric > > FAIL: char function arguments -- numeric > > FAIL: string function arguments -- numeric > > FAIL: integer function arguments -- numeric --kelf --ignore-dwarf > > FAIL: unsigned function arguments -- numeric --kelf --ignore-dwarf > > FAIL: long function arguments -- numeric --kelf --ignore-dwarf > > FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf > > FAIL: char function arguments -- numeric --kelf --ignore-dwarf > > FAIL: string function arguments -- numeric --kelf --ignore-dwarf > sourcing: /home/pavan/systemtap/src/testsuite/systemtap.context/num_args.tcl READY^M yyy_int -4611686018425998288 -4611686018425998288 -4611686018425998288^M yyy_int returns 499^M FAIL: integer function arguments -- numeric yyy_uint 1389616 1389616 1389616^M yyy_uint returns 499^M FAIL: unsigned function arguments -- numeric yyy_long -4611686018425998288 -4611686018425998288 -4611686018425998288^M yyy_long returns 499^M FAIL: long function arguments -- numeric yyy_int64 -4611686018425998288 -4611686018425998288 -4611686018425998288^M yyy_int64 returns 499^M FAIL: int64 function arguments -- numeric yyy_char 0 0 0^M yyy_char returns Q^M FAIL: char function arguments -- numeric yyy_str ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc-ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc-ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc^M yyy_str returns XYZZY^M FAIL: string function arguments -- numeric READY^M yyy_int -4611686018425998288 -4611686018425998288 -4611686018425998288^M yyy_int returns 499^M FAIL: integer function arguments -- numeric --kelf --ignore-dwarf yyy_uint 1389616 1389616 1389616^M yyy_uint returns 499^M FAIL: unsigned function arguments -- numeric --kelf --ignore-dwarf yyy_long -4611686018425998288 -4611686018425998288 -4611686018425998288^M yyy_long returns 499^M FAIL: long function arguments -- numeric --kelf --ignore-dwarf yyy_int64 -4611686018425998288 -4611686018425998288 -4611686018425998288^M yyy_int64 returns 499^M FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf yyy_char 0 0 0^M yyy_char returns Q^M FAIL: char function arguments -- numeric --kelf --ignore-dwarf yyy_str ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc-ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc-ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc^M yyy_str returns XYZZY^M FAIL: string function arguments -- numeric --kelf --ignore-dwarf as_root /bin/rm -f /lib/modules/2.6.30-rc3-git2/kernel/systemtap_test_module1.ko OUT RC 0 as_root /sbin/rmmod systemtap_test_module1 OUT RC 0 as_root /bin/rm -f /lib/modules/2.6.30-rc3-git2/kernel/systemtap_test_module2.ko OUT RC 0 as_root /sbin/rmmod systemtap_test_module2 OUT RC 0 > Could you post the relevant parts of the testsuite/systemtap.log for the > above failures? > > > FAIL: systemtap.examples/general/para-callgraph build > > FAIL: systemtap.examples/general/para-callgraph run > > Likewise. > > > FAIL: buildok/maxactive01.stp > > FAIL: buildok/signal-all-probes.stp > > FAIL: buildok/thirteen.stp > > FAIL: semok/thirtytwo.stp > > FAIL: semok/twentyeight.stp > > FAIL: semok/twentyfour.stp > > FAIL: semok/twentynine.stp > > FAIL: semok/twentyseven.stp > > FAIL: systemtap.printf/bin6.stp > > FAIL: systemtap.stress/current.stp shutdown (eof) > > > Some of these might be solved with an updated elfutils (0.141). At least > that was the case for s390. Using the same elfutils-0.141. > > > FAIL: 64-bit acct > > FAIL: 64-bit net1 > > FAIL: 64-bit readwrite > > FAIL: 64-bit signal > > FAIL: 32-bit acct > > FAIL: 32-bit net1 > > FAIL: 32-bit readwrite > > FAIL: 32-bit signal > > FAIL: 32-bit statfs > > The net1 failures are > http://sourceware.org/bugzilla/show_bug.cgi?id=6991 > "accept system call missed on 2.6.27" > > For the others look in the systemtap.log file and/or try running the > tests in testsuite/systemtap.syscall by hand. There is a README there > explaining how the tests work and how to use the tcl framework to see > how things should match. > > Thanks, > > Mark > Thanks Pavan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-28 6:02 ` Pavan Naregundi @ 2009-04-28 6:07 ` Ananth N Mavinakayanahalli 2009-04-29 9:37 ` Mark Wielaard 2009-04-29 9:41 ` Mark Wielaard 2 siblings, 0 replies; 15+ messages in thread From: Ananth N Mavinakayanahalli @ 2009-04-28 6:07 UTC (permalink / raw) To: Pavan Naregundi; +Cc: Mark Wielaard, systemtap On Tue, Apr 28, 2009 at 11:30:09AM +0530, Pavan Naregundi wrote: > Mark Wielaard <mjw@redhat.com> wrote on 04/27/2009 08:12:50 PM: > > > From: > > > > Mark Wielaard <mjw@redhat.com> > > > > To: > > > > Pavan Naregundi/India/IBM@IBMIN > > > > Cc: > > > > systemtap@sourceware.org > > > > Date: > > > > 04/27/2009 08:10 PM > > > > Subject: > > > > Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 > > > > Hi Pavan, > > > > On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote: > > > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 > > > Arch: ppc64 > > > > > > Please contact me, for any other details. > > > > Thanks for testing this combination. Which elfutils version did you use? > > elfutils-0.141 > > > > > > Unexpected failures > > > ============================= > > > FAIL: LOCAL1 (0) > > > > I have seen this fail sporadically, is it failing always for you? > I have seen this every time. > > > > > > FAIL: STRUCT1 (0) > > > > Could you post the relevant part of the testsuite/systemtap.log? > > Running /home/pavan/systemtap/src/testsuite/systemtap.base/alternatives.exp > ... > starting stap -vu -p2 -e { > probe kernel.function("sys_getrlimit") { x = $z; } > } > Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real > ms.^M > Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real > ms.^M > wait results: 15196 exp6 0 1 > FAIL: LOCAL1 (0) > starting stap -vu -p2 -e { > probe kernel.function("sys_getrlimit") { rlim_cur = $rlim->rlim_cud; } > } This and some of the others here are victims of SYSCALL_WRAPPERS changes. I have a patch (yet to be checked in) for this. See bz10007. Can you please try with the patch at: http://sources.redhat.com/bugzilla/attachment.cgi?id=3896&action=view Ananth ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-28 6:02 ` Pavan Naregundi 2009-04-28 6:07 ` Ananth N Mavinakayanahalli @ 2009-04-29 9:37 ` Mark Wielaard 2009-04-29 19:01 ` Josh Stone 2009-04-29 9:41 ` Mark Wielaard 2 siblings, 1 reply; 15+ messages in thread From: Mark Wielaard @ 2009-04-29 9:37 UTC (permalink / raw) To: Pavan Naregundi; +Cc: systemtap, Josh Stone On Tue, 2009-04-28 at 11:30 +0530, Pavan Naregundi wrote: > Running /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp ... > executing: stap /home/pavan/systemtap/src/testsuite/systemtap.base/cast.stp > -g > FAIL: systemtap.base/cast.stp > line 4: expected "tv_sec OK" > Got "tv_sec 42 != 0" > testcase /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp > completed in 8 seconds That is strange, maybe struct timeval is different on ppc64 from what we expect in the @cast or get_timeval() in the script. Maybe Josh has a hunch what is going on (he wrote the test originally). Cheers, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-29 9:37 ` Mark Wielaard @ 2009-04-29 19:01 ` Josh Stone 0 siblings, 0 replies; 15+ messages in thread From: Josh Stone @ 2009-04-29 19:01 UTC (permalink / raw) To: Mark Wielaard; +Cc: Pavan Naregundi, systemtap Mark Wielaard wrote: > On Tue, 2009-04-28 at 11:30 +0530, Pavan Naregundi wrote: >> Running /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp ... >> executing: stap /home/pavan/systemtap/src/testsuite/systemtap.base/cast.stp >> -g >> FAIL: systemtap.base/cast.stp >> line 4: expected "tv_sec OK" >> Got "tv_sec 42 != 0" >> testcase /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp >> completed in 8 seconds > > That is strange, maybe struct timeval is different on ppc64 from what we > expect in the @cast or get_timeval() in the script. Maybe Josh has a > hunch what is going on (he wrote the test originally). The scenario where this would fail is a big-endian machine where the size of "long tv_sec" is different between kernel and user mode. AFAIK, ppc64 is one such machine. I would say that the @cast is working fine here -- it's just a bad assumption on my part in writing the test. I'll see if there's another struct type I can use that will be more robust... Josh ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-28 6:02 ` Pavan Naregundi 2009-04-28 6:07 ` Ananth N Mavinakayanahalli 2009-04-29 9:37 ` Mark Wielaard @ 2009-04-29 9:41 ` Mark Wielaard 2 siblings, 0 replies; 15+ messages in thread From: Mark Wielaard @ 2009-04-29 9:41 UTC (permalink / raw) To: Pavan Naregundi; +Cc: systemtap, scox On Tue, 2009-04-28 at 11:30 +0530, Pavan Naregundi wrote: > > > FAIL: compiling sdt.c "" > > > FAIL: compiling sdt.c additional_flags=-std=gnu89 > > > FAIL: compiling sdt.c additional_flags=-ansi > > > FAIL: compiling sdt.c additional_flags=-pedantic > > > FAIL: compiling sdt.c additional_flags=-ansi additional_flags=-pedantic > > > FAIL: compiling sdt.c additional_flags=-O2 > > > FAIL: compiling sdt.c additional_flags="-O3" > > > FAIL: static_uprobes compiling C -g > > Running /home/pavan/systemtap/src/testsuite/systemtap.base/sdt.exp ... > Executing on host: gcc > /home/pavan/systemtap/src/testsuite/systemtap.base/sdt.c -g > -I/home/pavan/systemtap/src/testsuite/../includes/sys -Wall -Wextra -Werror > -lm -o sdt.c.exe.0 (timeout = 300) > /tmp/ccastHp6.s: Assembler messages:^M > /tmp/ccastHp6.s:57: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:116: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:179: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:246: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:317: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:392: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:471: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:554: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:640: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:729: Error: junk at end of line: `0'^M > compiler exited with status 1 > output is: > /tmp/ccastHp6.s: Assembler messages:^M > /tmp/ccastHp6.s:57: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:116: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:179: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:246: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:317: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:392: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:471: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:554: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:640: Error: junk at end of line: `0'^M > /tmp/ccastHp6.s:729: Error: junk at end of line: `0'^M > > FAIL: compiling sdt.c "" > UNTESTED: sdt "" > > > > > That probably means the sdt.h header doesn't compile on ppc. > > Could you see if testsuite/systemtap.log gives more hints about what is > > wrong? What gcc version are you using? > > gcc version 4.3.2 20081007 (Red Hat 4.3.2-6) (GCC) Thanks, I think the new "nop 0" in sdt.h is wrong on ppc64 I don't have a ppc64 around, but maybe this will work (assuming these tests did work before): diff --git a/includes/sys/sdt.h b/includes/sys/sdt.h index f89b736..8e87942 100644 --- a/includes/sys/sdt.h +++ b/includes/sys/sdt.h @@ -58,7 +58,7 @@ #define STAP_UNINLINE_LABEL(label) \ __extension__ static volatile long labelval __attribute__ ((unused)) = (long) &&label -#if defined(__x86_64__) || defined(__i386__) +#if defined(__x86_64__) || defined(__i386__) || defined(__ppc64__) #define STAP_NOP "\tnop " #else #define STAP_NOP "\tnop 0 " Cheers, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-27 14:43 ` Mark Wielaard 2009-04-28 5:11 ` Pavan Naregundi 2009-04-28 6:02 ` Pavan Naregundi @ 2009-04-28 6:56 ` Ananth N Mavinakayanahalli 2009-04-29 8:57 ` Mark Wielaard 2 siblings, 1 reply; 15+ messages in thread From: Ananth N Mavinakayanahalli @ 2009-04-28 6:56 UTC (permalink / raw) To: Mark Wielaard; +Cc: Pavan Naregundi, systemtap On Mon, Apr 27, 2009 at 04:42:50PM +0200, Mark Wielaard wrote: > Hi Pavan, > > On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote: > > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 > > Arch: ppc64 > > > > Please contact me, for any other details. > > Thanks for testing this combination. Which elfutils version did you use? > > > Unexpected failures > > ============================= > > FAIL: LOCAL1 (0) I've seen the above fail with LOCAL1 (2), which actually needs to be flagged as a success. I guess the issue is with checking of rc -- down in alternatives.exp: - if {$rc == 1} { pass $test } else { fail "$test ($rc)" } + if {$rc >= 1} { pass $test } else { fail "$test ($rc)" } should fix the problem. Ananth ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-28 6:56 ` Ananth N Mavinakayanahalli @ 2009-04-29 8:57 ` Mark Wielaard 2009-04-29 9:26 ` Ananth N Mavinakayanahalli 0 siblings, 1 reply; 15+ messages in thread From: Mark Wielaard @ 2009-04-29 8:57 UTC (permalink / raw) To: ananth; +Cc: Pavan Naregundi, systemtap On Tue, 2009-04-28 at 12:26 +0530, Ananth N Mavinakayanahalli wrote: > On Mon, Apr 27, 2009 at 04:42:50PM +0200, Mark Wielaard wrote: > > On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote: > > > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 > > > Arch: ppc64 > > > > > > FAIL: LOCAL1 (0) > > I've seen the above fail with LOCAL1 (2), which actually needs to be > flagged as a success. I guess the issue is with checking of rc -- down > in alternatives.exp: > > - if {$rc == 1} { pass $test } else { fail "$test ($rc)" } > + if {$rc >= 1} { pass $test } else { fail "$test ($rc)" } > > should fix the problem. Yes, that seems fine. The LOCAL1 (0) failure case is as you observed because of the syscall wrappers issue (I am thinking about the patch you proposed in PR10007 and testing it locally - x86_64 only for now though). Cheers, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-29 8:57 ` Mark Wielaard @ 2009-04-29 9:26 ` Ananth N Mavinakayanahalli 2009-04-29 12:08 ` Mark Wielaard 0 siblings, 1 reply; 15+ messages in thread From: Ananth N Mavinakayanahalli @ 2009-04-29 9:26 UTC (permalink / raw) To: Mark Wielaard; +Cc: Pavan Naregundi, systemtap On Wed, Apr 29, 2009 at 10:57:01AM +0200, Mark Wielaard wrote: > On Tue, 2009-04-28 at 12:26 +0530, Ananth N Mavinakayanahalli wrote: > > On Mon, Apr 27, 2009 at 04:42:50PM +0200, Mark Wielaard wrote: > > > On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote: > > > > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 > > > > Arch: ppc64 > > > > > > > > FAIL: LOCAL1 (0) > > > > I've seen the above fail with LOCAL1 (2), which actually needs to be > > flagged as a success. I guess the issue is with checking of rc -- down > > in alternatives.exp: > > > > - if {$rc == 1} { pass $test } else { fail "$test ($rc)" } > > + if {$rc >= 1} { pass $test } else { fail "$test ($rc)" } > > > > should fix the problem. > > Yes, that seems fine. The LOCAL1 (0) failure case is as you observed > because of the syscall wrappers issue (I am thinking about the patch you > proposed in PR10007 and testing it locally - x86_64 only for now > though). Thanks Mark. I've attached an updated version just now. Ananth ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-29 9:26 ` Ananth N Mavinakayanahalli @ 2009-04-29 12:08 ` Mark Wielaard 2009-04-29 12:21 ` Ananth N Mavinakayanahalli 2009-04-29 13:15 ` David Smith 0 siblings, 2 replies; 15+ messages in thread From: Mark Wielaard @ 2009-04-29 12:08 UTC (permalink / raw) To: ananth; +Cc: systemtap Hi Ananth, On Wed, 2009-04-29 at 14:56 +0530, Ananth N Mavinakayanahalli wrote: > On Wed, Apr 29, 2009 at 10:57:01AM +0200, Mark Wielaard wrote: > > > > Yes, that seems fine. The LOCAL1 (0) failure case is as you observed > > because of the syscall wrappers issue (I am thinking about the patch you > > proposed in PR10007 and testing it locally - x86_64 only for now > > though). > > Thanks Mark. I've attached an updated version just now. So that patch does give some new failures for me (version 0.9.7/0.137 commit release-0.9.7-27-g9997403 + changes on 2.6.18-128.1.6.el5xen x86_64): attempting command stap -p4 para-callgraph.stp kernel.function("*@fs/proc*.c") syscall.read OUT semantic error: probe point mismatch at position 2 (alternatives: return): identifier 'syscall' at para-callgraph.stp:15:7 while resolving probe point syscall.read.call source: probe $2.call { ^ Pass 2: analysis failed. Try again with another '--vp 01' option. child process exited abnormally RC 1 FAIL: systemtap.examples/general/para-callgraph build So the problem there is that the function probe can have a .call attribute, but the syscall probe doesn't. spawn1 stap -p4 /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp semantic error: probe point mismatch at position 3 (alternatives:): identifier 'syscall' at /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp:3:7 while resolving probe point syscall.read.return.maxactive(3) semantic error: probe point mismatch at position 3 (alternatives:): identifier 'syscall' at /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp:3:7 while resolving probe point syscall.read.return.maxactive(3) source: probe syscall.read.return.maxactive(3) source: probe syscall.read.return.maxactive(3) ^ ^ semantic error: no probes found semantic error: no probes found Pass 2: analysis failed. Try again with another '--vp 01' option.^M Pass 2: analysis failed. Try again with another '--vp 01' option.^M wait results: 16579 exp33 0 1 FAIL: buildok/maxactive01.stp Similar problem, but now that a function.return probe can have a maxactive attribute, while a syscall.return probe cannot. The rest does seem to PASS as before, but I am somewhat concerned that the tests were originally designed to test function (.call/return) probes, which are different from syscall (.return) probes. So are we really still testing the correct things? Cheers, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-29 12:08 ` Mark Wielaard @ 2009-04-29 12:21 ` Ananth N Mavinakayanahalli 2009-04-29 12:27 ` Mark Wielaard 2009-04-29 13:15 ` David Smith 1 sibling, 1 reply; 15+ messages in thread From: Ananth N Mavinakayanahalli @ 2009-04-29 12:21 UTC (permalink / raw) To: Mark Wielaard; +Cc: systemtap On Wed, Apr 29, 2009 at 02:08:23PM +0200, Mark Wielaard wrote: > Hi Ananth, > > On Wed, 2009-04-29 at 14:56 +0530, Ananth N Mavinakayanahalli wrote: > > On Wed, Apr 29, 2009 at 10:57:01AM +0200, Mark Wielaard wrote: > > > > > > Yes, that seems fine. The LOCAL1 (0) failure case is as you observed > > > because of the syscall wrappers issue (I am thinking about the patch you > > > proposed in PR10007 and testing it locally - x86_64 only for now > > > though). > > > > Thanks Mark. I've attached an updated version just now. > > So that patch does give some new failures for me (version 0.9.7/0.137 > commit release-0.9.7-27-g9997403 + changes on 2.6.18-128.1.6.el5xen > x86_64): > > attempting command stap -p4 para-callgraph.stp kernel.function("*@fs/proc*.c") syscall.read > OUT semantic error: probe point mismatch at position 2 (alternatives: return): identifier 'syscall' at para-callgraph.stp:15:7 while resolving probe point syscall.read.call > source: probe $2.call { > ^ > Pass 2: analysis failed. Try again with another '--vp 01' option. > child process exited abnormally > RC 1 > FAIL: systemtap.examples/general/para-callgraph build > > So the problem there is that the function probe can have a .call > attribute, but the syscall probe doesn't. Ugh yes :( > spawn1 stap -p4 /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp > semantic error: probe point mismatch at position 3 (alternatives:): identifier 'syscall' at /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp:3:7 while resolving probe point syscall.read.return.maxactive(3) > semantic error: probe point mismatch at position 3 (alternatives:): identifier 'syscall' at /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp:3:7 while resolving probe point syscall.read.return.maxactive(3) > source: probe syscall.read.return.maxactive(3) > > source: probe syscall.read.return.maxactive(3) > ^ > > ^ > semantic error: no probes found > > semantic error: no probes found > Pass 2: analysis failed. Try again with another '--vp 01' option.^M > > Pass 2: analysis failed. Try again with another '--vp 01' option.^M > wait results: 16579 exp33 0 1 > FAIL: buildok/maxactive01.stp > > Similar problem, but now that a function.return probe can have a > maxactive attribute, while a syscall.return probe cannot. > > The rest does seem to PASS as before, but I am somewhat concerned that > the tests were originally designed to test function (.call/return) > probes, which are different from syscall (.return) probes. So are we > really still testing the correct things? Maybe the choice of functions weren't correct in the first place? Why don't we change this to say, vfs_read instead of sys_read? Ananth ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-29 12:21 ` Ananth N Mavinakayanahalli @ 2009-04-29 12:27 ` Mark Wielaard 0 siblings, 0 replies; 15+ messages in thread From: Mark Wielaard @ 2009-04-29 12:27 UTC (permalink / raw) To: ananth; +Cc: systemtap Hi Ananth, On Wed, 2009-04-29 at 17:51 +0530, Ananth N Mavinakayanahalli wrote: > On Wed, Apr 29, 2009 at 02:08:23PM +0200, Mark Wielaard wrote: > > The rest does seem to PASS as before, but I am somewhat concerned > that > > the tests were originally designed to test function (.call/return) > > probes, which are different from syscall (.return) probes. So are we > > really still testing the correct things? > > Maybe the choice of functions weren't correct in the first place? Why > don't we change this to say, vfs_read instead of sys_read? That sounds like a good plan to me. Cheers, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 2009-04-29 12:08 ` Mark Wielaard 2009-04-29 12:21 ` Ananth N Mavinakayanahalli @ 2009-04-29 13:15 ` David Smith 1 sibling, 0 replies; 15+ messages in thread From: David Smith @ 2009-04-29 13:15 UTC (permalink / raw) To: Mark Wielaard; +Cc: ananth, systemtap Mark Wielaard wrote: > The rest does seem to PASS as before, but I am somewhat concerned that > the tests were originally designed to test function (.call/return) > probes, which are different from syscall (.return) probes. So are we > really still testing the correct things? I've had some of the same concerns. Also, if we look ahead a bit, it is possible the syscall tapset will start using tracepoint probes instead of kprobes. Then the tests really won't be testing the correct things. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-04-29 19:01 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-04-27 11:49 Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 Pavan Naregundi 2009-04-27 14:43 ` Mark Wielaard 2009-04-28 5:11 ` Pavan Naregundi 2009-04-28 6:02 ` Pavan Naregundi 2009-04-28 6:07 ` Ananth N Mavinakayanahalli 2009-04-29 9:37 ` Mark Wielaard 2009-04-29 19:01 ` Josh Stone 2009-04-29 9:41 ` Mark Wielaard 2009-04-28 6:56 ` Ananth N Mavinakayanahalli 2009-04-29 8:57 ` Mark Wielaard 2009-04-29 9:26 ` Ananth N Mavinakayanahalli 2009-04-29 12:08 ` Mark Wielaard 2009-04-29 12:21 ` Ananth N Mavinakayanahalli 2009-04-29 12:27 ` Mark Wielaard 2009-04-29 13:15 ` David Smith
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).