[Bug tapsets/2433] New: sys_groupexit in blacklist

[Bug tapsets/2433] New: sys_groupexit in blacklist

[guanglei at cn dot ibm dot com]

in tapsets.cxx:
      ...
      (has_return && (funcname == "sys_exit" ||
                      funcname == "sys_groupexit")))
      ...
which intends to avoid probe returning of these two functions. But I think here
sys_groupexit is a typo for sys_exit_group.

-- 
           Summary: sys_groupexit in blacklist
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: guanglei at cn dot ibm dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=2433

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/2433] sys_groupexit in blacklist

[guanglei at cn dot ibm dot com]

------- Additional Comments From guanglei at cn dot ibm dot com  2006-04-06 03:01 -------
(In reply to comment #0)
> in tapsets.cxx:
>       ...
>       (has_return && (funcname == "sys_exit" ||
>                       funcname == "sys_groupexit")))
>       ...
> which intends to avoid probe returning of these two functions. But I think here
> sys_groupexit is a typo for sys_exit_group.

any updates on this?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2433

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/2433] sys_groupexit in blacklist

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-04-06 03:17 -------
It must indeed be just a typo.

However, I wonder whether the kretprobes situation is such that these two
blacklist items are no longer needed.  Or for that matter, why does
src/tapset/syscalls.stp make ".return" probe aliases to either of these two
never-returning calls.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2433

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/2433] sys_groupexit in blacklist

[guanglei at cn dot ibm dot com]

------- Additional Comments From guanglei at cn dot ibm dot com  2006-04-06 03:43 -------
(In reply to comment #2)
> It must indeed be just a typo.
> 
> However, I wonder whether the kretprobes situation is such that these two
> blacklist items are no longer needed.  Or for that matter, why does
> src/tapset/syscalls.stp make ".return" probe aliases to either of these two
> never-returning calls.
I think the syscall.exit & syscall.exit_group should be deleted from
src/tapset/syscalls.stp. And do_exit should also be added into blacklist.

For these never-return functions, it won't cause runtime error if a return probe
is putting on them since these probes will never be hit. But making tapsets.cxx
give warnings about return probles on these never-return functions could let the
user know it's useless to do that, instead of waiting for executions of probe
handlers. Not all users know about these never-return functions.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2433

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/2433] sys_groupexit in blacklist

[eteo at redhat dot com]

------- Additional Comments From eteo at redhat dot com  2006-05-05 18:01 -------
Committed the following patch.

===================================================================
RCS file: /cvs/systemtap/src/tapsets.cxx,v
retrieving revision 1.125
retrieving revision 1.126
diff -u -r1.125 -r1.126
--- src/tapsets.cxx	2006/05/04 00:01:24	1.125
+++ src/tapsets.cxx	2006/05/05 17:58:08	1.126
@@ -1981,8 +1981,9 @@
       (funcname == "__switch_to" && sess.architecture == "x86_64") ||
       filename_s == "kernel/kprobes.c" ||
       0 == fnmatch ("arch/*/kernel/kprobes.c", filename, 0) ||
-      (has_return && (funcname == "sys_exit" ||
-                      funcname == "sys_groupexit")))
+      (has_return && (funcname == "do_exit" ||
+                      funcname == "sys_exit" ||
+                      funcname == "sys_exit_group")))
     {
       if (sess.verbose>1)
         clog << "skipping function '" << funcname << "' file '"

===================================================================
RCS file: /cvs/systemtap/src/tapset/syscalls.stp,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- src/tapset/syscalls.stp	2006/04/21 04:40:13	1.11
+++ src/tapset/syscalls.stp	2006/05/05 17:58:09	1.12
@@ -440,10 +440,6 @@
 	status = $code
 	argstr = string($code)
 }
-probe syscall.exit.return = kernel.function("do_exit").return {
-	name = "exit"
-	retstr = returnstr(1)
-}
 
 # exit_group _________________________________________________
 /*
@@ -455,10 +451,6 @@
       name = "exit_group"
       status = $error_code
    }
-probe kernel.syscall.exit_group.return =
-   kernel.function("do_group_exit").return {
-      name = "exit_group.return"
-   }
 # fadvise64 __________________________________________________
 /*
  * asmlinkage long

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=2433

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/2433] sys_groupexit in blacklist

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-06-02 18:34 -------
done

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


http://sourceware.org/bugzilla/show_bug.cgi?id=2433

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.