From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31992 invoked by alias); 3 Feb 2009 07:50:42 -0000 Received: (qmail 31941 invoked by uid 48); 3 Feb 2009 07:50:25 -0000 Date: Tue, 03 Feb 2009 14:07:00 -0000 Message-ID: <20090203075025.31940.qmail@sourceware.org> From: "wenji dot huang at oracle dot com" To: systemtap@sources.redhat.com In-Reply-To: <20081024082201.6979.srikar@linux.vnet.ibm.com> References: <20081024082201.6979.srikar@linux.vnet.ibm.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access. X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q1/txt/msg00320.txt.bz2 ------- 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.