[Bug runtime/16278] New: orphaned stapsh goes to 100% CPU after stap closing

[Bug runtime/16278] New: orphaned stapsh goes to 100% CPU after stap closing

[jlebon at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16278

            Bug ID: 16278
           Summary: orphaned stapsh goes to 100% CPU after stap closing
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: jlebon at redhat dot com

When using --remote <ssh-remote>, if for some reason stap hangs during passes
1-4 and must be killed with SIGINT, the orphaned stapsh on the remote keeps
running. Not only that, it starts using up 100% CPU.

One way to get stap to hang is (prior to the fix from PR16276) to run the
following to get the server to fail (this is prior to the fix from PR16276):

stap -L 'kernel.trace("kfree_skb")' --remote <ssh-remote> --use-server <server>

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

[Bug runtime/16278] orphaned stapsh goes to 100% CPU after stap closing

[jlebon at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16278

--- Comment #1 from Jonathan Lebon <jlebon at redhat dot com> ---
Fixed in commit 2200b70. The 100% CPU usage comes from busy-looping between
poll() and fgets(), where poll() was returning POLLIN to indicate EOF and we
were not checking feof() after the failed fgets().

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

[Bug runtime/16278] orphaned stapsh goes to 100% CPU after stap closing

[jlebon at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16278

Jonathan Lebon <jlebon at redhat dot com> changed:

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

--- Comment #2 from Jonathan Lebon <jlebon at redhat dot com> ---
In master.

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