This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.
- From: "wenji dot huang at oracle dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 3 Feb 2009 07:50:25 -0000
- Subject: [Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.
- References: <20081024082201.6979.srikar@linux.vnet.ibm.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From wenji dot huang at oracle dot com 2009-02-03 07:50 -------
Did some more tests. Seems it will happen on specific probe point combination
with $$parms. Such as,
stap -p4 -vve 'probe kernel.function("proc_reg_llseek"){printf("%s\n",$$parms)}'
But it can pass when executing
stap -p4 -vve 'probe kernel.function("proc_reg_llseek"){printf("%s\n",pp())}'
stap -p4 -vve 'probe kernel.function("proc_register"){printf("%s\n",$$parms)}'
The root cause is the generated incorrect code
{
intptr_t s0;
addr = s0;
}
It should be like,
{
intptr_t s0;
s0 = fetch_register (5) + -28L;
addr = s0;
}
Theses are from loc2c.c::emit_loc_address,
emit ("%s%*s%s = " STACKFMT ";\n", loc->address.program,
(indent + 1) * 2, "", target, 0);
In some cases, loc->address.program='\0' cause the error.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6979
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.