This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/11769] New: process.mark probes losing arguments
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 30 Jun 2010 15:00:46 -0000
- Subject: [Bug translator/11769] New: process.mark probes losing arguments
- Reply-to: sourceware-bugzilla at sourceware dot org
On s390x (kernel 2.6.18-194.el5), the testsuite/semok/thirtysix.stp test fails:
# stap -vp3 ../src/testsuite/semok/thirtysix.stp
Pass 1: parsed user script and 71 library script(s) using
29468virt/20976res/2608shr kb, in 190usr/10sys/208real ms.
semantic error: unable to find local 'nosuchvar' near pc 0x8010035a in
<unknown>(../src/cache.cxx) (alternatives: $arg1 $arg2): identifier '$nosuchvar'
at ../src/testsuite/semok/thirtysix.stp:14:66
source: probe process("stap").mark("*")? {
println(@defined($arg1)?$arg1:$nosuchvar) } # valid
^
Pass 2: analyzed script: 228 probe(s), 25 function(s), 5 embed(s), 3 global(s)
using 106160virt/52596res/4852shr kb, in 620usr/120sys/745real ms.
Pass 2: analysis failed. Try again with another '--vp 01' option.
OK, so the failing line is the following:
probe process("stap").mark("*")? { println(@defined($arg1)?$arg1:$nosuchvar) }
The test is trying to make sure @defined() is working properly. The above test
can be simplified by removing @defined():
# stap -vp4 -e 'probe process("stap").mark("*") { println($arg1) }'
Pass 1: parsed user script and 71 library script(s) using
29368virt/20888res/2608shr kb, in 190usr/10sys/205real ms.
semantic error: not accessible at this address (0x8010035a): identifier '$arg1'
at <input>:1:43
source: probe process("stap").mark("*") { println($arg1) }
^
Pass 2: analyzed script: 19 probe(s), 16 function(s), 0 embed(s), 0 global(s)
using 43436virt/24164res/4088shr kb, in 60usr/0sys/60real ms.
Pass 2: analysis failed. Try again with another '--vp 01' option.
OK, let's look at all the mark probes and see if $arg1 exists:
# stap -L 'process("stap").mark("*")'
process("stap").mark("cache__add__module")
process("stap").mark("cache__add__source")
process("stap").mark("cache__clean") $arg1:char const* volatile
process("stap").mark("cache__get")
process("stap").mark("pass0__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass0__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass1__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass1a__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass1b__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass2__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass2__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass3__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass3__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass4__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass4__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass5__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass5__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass6__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass6__start") $arg1:struct systemtap_session* volatile
That's odd output, since in the source the markers without arguments do have
arguments:
STAP_PROBE2(stap, cache__add__module, module_src_path.c_str(), s.hash_path.c_\
str());
STAP_PROBE2(stap, cache__get, c_src_path.c_str(), s.hash_path.c\
_str());
STAP_PROBE2(stap, cache__add__source, s.translated_source.c_str(), c_dest_pat\
h.c_str());
I'm unsure if the fact that all the failing markers have 2 arguments is significant.
Here's a test of a single failing marker:
# stap -vp4 -e 'probe process("stap").mark("cache__get") { println($arg1) }'
Pass 1: parsed user script and 71 library script(s) using
29368virt/20888res/2608shr kb, in 190usr/10sys/209real ms.
semantic error: not accessible at this address (0x8010035a): identifier '$arg1'
at <input>:1:52
source: probe process("stap").mark("cache__get") { println($arg1) }
^
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s)
using 43048virt/23512res/3788shr kb, in 10usr/0sys/14real ms.
Pass 2: analysis failed. Try again with another '--vp 01' option.
On f13 x86 and rhel6 x86_64, the problem is actually worse - none of the markers
have arguments:
# stap -L 'process("stap").mark("*")'
process("stap").mark("cache__add__module")
process("stap").mark("cache__add__source")
process("stap").mark("cache__clean")
process("stap").mark("cache__get")
process("stap").mark("client__end")
process("stap").mark("client__start")
process("stap").mark("pass0__end")
process("stap").mark("pass0__start")
process("stap").mark("pass1__end")
process("stap").mark("pass1a__start")
process("stap").mark("pass1b__start")
process("stap").mark("pass2__end")
process("stap").mark("pass2__start")
process("stap").mark("pass3__end")
process("stap").mark("pass3__start")
process("stap").mark("pass4__end")
process("stap").mark("pass4__start")
process("stap").mark("pass5__end")
process("stap").mark("pass5__start")
process("stap").mark("pass6__end")
process("stap").mark("pass6__start")
process("stap").mark("stap_system__complete")
process("stap").mark("stap_system__spawn")
process("stap").mark("stap_system__start")
--
Summary: process.mark probes losing arguments
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: translator
AssignedTo: systemtap at sources dot redhat dot com
ReportedBy: dsmith at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=11769
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.