[Bug translator/6979] New: using $$parms under uprobe probes might result in a uninitialized variable access.

[Bug translator/6979] New: using $$parms under uprobe probes might result in a uninitialized variable access.

[srikar at linux dot vnet dot ibm dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]

$$parms fails seems to fail under a particular test.

$ sudo stap -k -v -v -v allfuncs.stp -c "./git-1.5.4/git clone git.systemtap
/tmp/systemtap"
where  allfuncs.stp  is
-------------------------------------------------------------------------------------
probe process("/home/srikar/git-1.5.4/git").function("*").call
{
        printf ("%s \n", $$parms);

}
--------------------------------------------------------------------------------
gives 
.....
cc1: warnings being treated as errors
/tmp/stapxK2Ynm/stap_18137.c: In function ‘probe_1683’:
/tmp/stapxK2Ynm/stap_18137.c:10419: warning: ‘s0’ is used uninitialized in this
function
make[1]: *** [/tmp/stapxK2Ynm/stap_18137.o] Error 1
make: *** [_module_/tmp/stapxK2Ynm] Error 2
make: Leaving directory `/home/srikar/work/linux-2.6.23'
Pass 4: compiled C into "stap_18137.ko" in 36650usr/1710sys/37410real ms.
Pass 4: compilation failed.  Try again with more '-v' (verbose) options.
Keeping temporary directory "/tmp/stapxK2Ynm"
$


code at /tmp/stapxK2Ynm/stap_18137.c:10419  looks like this


10415     { int32_t value = deref (4, addr);u.pieces.p0 = value; }
10416     { // DWARF expression: 0x51
10417       {
10418         intptr_t s0;
10419         addr = s0;
10420       }
10421     }
10422     { int32_t value = deref (4, addr);u.pieces.p4 = value; }
10423     THIS->__retvalue = u.whole;
10424   }

It looks we are trying to assign uninitialized ptr s0 to addr;

some information about probe_1683:

60563   { .finder = { .pathname="/home/srikar/git-1.5.4/git", },
.address=0x80763a2UL, .pp="process(\"/home/srikar/git-1.5.4/git\").          
function(\"find_packed_object@/home/srikar/git-1.5.4/builtin-pack-objects.c:213\").call",
.ph=&probe_1683, },

 1386     struct probe_1683_locals {
 1387       string_t __tmp0;
 1388       int64_t __tmp1;
 1389       int64_t __tmp2;
 1390       string_t __tmp3;
 1391     } probe_1683;

probe_1683 corresponds to 
static struct revindex_entry * find_packed_object(struct packed_git *p,
                                                   off_t ofs)

-- 
           Summary: using $$parms under uprobe probes might result in a
                    uninitialized variable access.
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: srikar at linux dot vnet dot ibm dot com


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2009-02-03 05:36 -------
Reproduced it using testsuite/systemtap.examples/general/para-callgraph.stp

$sudo stap -vv para-callgraph.stp 'kernel.function("*@fs/proc*.c")'
'kernel.function("sys_read")'
...
Pass 3: translated to C into
"/tmp/stapI6MOvi/stap_6d7c9a6d948642fb62a56ab0e7db8c2b_133065.c" in
1840usr/2400sys/4935real ms.
Running make -C "/lib/modules/2.6.29-rc3/build" M="/tmp/stapI6MOvi" modules
>/dev/null
cc1: warnings being treated as errors
/tmp/stapI6MOvi/stap_6d7c9a6d948642fb62a56ab0e7db8c2b_133065.c: In function
'probe_1422':
/tmp/stapI6MOvi/stap_6d7c9a6d948642fb62a56ab0e7db8c2b_133065.c:2569: warning:
's0' is used uninitialized in this function
make[1]: *** [/tmp/stapI6MOvi/stap_6d7c9a6d948642fb62a56ab0e7db8c2b_133065.o]
Error 1
make: *** [_module_/tmp/stapI6MOvi] Error 2
Pass 4: compiled C into "stap_6d7c9a6d948642fb62a56ab0e7db8c2b_133065.ko" in
17790usr/4530sys/22241real ms.
Pass 4: compilation failed.  Try again with another '--vp 0001' option.
$ stap -V
SystemTap translator/driver (version 0.8/0.131 commit d1d11e96 + changes)
Copyright (C) 2005-2008 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-9.0.1)




-- 


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[wenji dot huang at oracle dot com]

------- 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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-02-03 16:42 -------
This must depend on the compiler/architecture.  Perhaps it's passing a type
that we haven't dealt with before on loc2c.  Can you share the e.g. git binary
you had problem with?


-- 


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2009-02-04 02:17 -------
Created an attachment (id=3708)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=3708&action=view)
the generated stap_xxx.c, stap-symbols.h, Makefile.


-- 


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2009-02-04 02:56 -------
I added some print code to loc2c, before
 237       switch (expr[i].atom)
 238         {
found there was one kind of dwarf_location_atom happened, DW_OP_breg5 = 0x75
but not processed by loc2c. Maybe this will the culprit.

-- 


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2009-02-04 03:10 -------
(In reply to comment #5)
> I added some print code to loc2c, before
>  237       switch (expr[i].atom)
>  238         {
> found there was one kind of dwarf_location_atom happened, DW_OP_breg5 = 0x75
> but not processed by loc2c. Maybe this will the culprit.
Sorry, DW_OP_breg5 is covered. Please ignore the comment.


-- 


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-02-04 14:57 -------
Please make the ELF binary available somewhere.
Otherwise, you'd need to extract the debugging data dump (eu-readelf -w),
ideally narrowed down to the variable in question and its location list.


-- 


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2009-02-05 08:03 -------
Created an attachment (id=3720)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=3720&action=view)
debuginfo dump for the probe function, including info and loc.

Vmlinux is too big. I extracted the related info and location from debuginfo
file for the example function proc_reg_llseek

-- 


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-02-05 20:59 -------
I haven't reproduced this problem, and we still don't have the entire
copy of *some* affected elf file.  However, looking at the attachment
and the loc2c code, it seem the following combination is not being
handled by loc2c:

 [ e93f3]  0xc0189445 <proc_reg_llseek>..0xc0189455 <proc_reg_llseek+0x10> [  
0] reg2
                                  [   1] piece 4
                                  [   3] reg1
                                  [   4] piece 4

To wit, the reg1 piece.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roland at redhat dot com


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-02-20 12:43 -------
> Vmlinux is too big.

Then please post or send somewhere your git binary that showed the same problem.


-- 


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[srikar at linux dot vnet dot ibm dot com]

------- Additional Comments From srikar at linux dot vnet dot ibm dot com  2009-06-11 12:30 -------
Sorry for the delayed response.

I have verified that the problem reported is still reproducible with systemtap
snapshot for the week starting 8th June 2009. 

I have placed a bzipped binary at 
http://www.4shared.com/file/111179507/3598a80e/git.html



-- 


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-11-11 14:35 -------
Still reported as of systemtap 0.9.7
https://bugzilla.redhat.com/show_bug.cgi?id=536807

-- 


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[roland at gnu dot org]

------- Additional Comments From roland at gnu dot org  2009-11-11 20:20 -------
commit 56cfcfc

Please check for other regressions.

-- 


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.

[Bug translator/6979] using $$parms under uprobe probes might result in a uninitialized variable access.

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-11-18 17:32 -------
fixed

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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.

[Bug translator/6979] loc2c code generation error, uninitialized variable access, mishandling of multiple-piece $target vars

[fche at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|using $$parms under uprobe  |loc2c code generation error,
                   |probes might result in a    |uninitialized variable
                   |uninitialized variable      |access, mishandling of
                   |access.                     |multiple-piece $target vars


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.