Bug 634802

Summary: pinfo does not refresh curses so shell job control suspend/resume causes 100% CPU endless loop
Product: [Fedora] Fedora Reporter: scott.m.mcdermott+rh-omnisys-bugs
Component: pinfoAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: mlichvar
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: pinfo-0.6.10-1.fc13 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-30 10:29:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to handle SIGTSTP by shutting down curses, then refresh after CONT none

Description scott.m.mcdermott+rh-omnisys-bugs 2010-09-17 03:42:35 UTC
Created attachment 447894 [details]
patch to handle SIGTSTP by shutting down curses, then refresh after CONT

Pinfo has a bug where it can't be used after being
continued from job stop in the shell (i.e.  control-z).
It will eat a CPU after resume, endlessly doing main
keypress handling loop because every time it calls
curses getch() after suspend, it will get ERR, until
curses has been "reset." The terminal needs to be
handed back to the calling program (i.e. bash) for
suspend, and then refreshed on resume.

I am surprised this bug went so long unfixed, because
using multiple jobs in a shell seems like a common
activity.

I debugged this and made the following patch, which
works well for me.

Please apply.  Thanks.

Comment 1 scott.m.mcdermott+rh-omnisys-bugs 2010-09-17 03:46:41 UTC
btw I tried mailing both of the authors from AUTHORS on Sept
8th, and then the pinfo-devel mailing list on Sept 13th, but
I have not yet received any responses.

Comment 2 scott.m.mcdermott+rh-omnisys-bugs 2010-09-17 03:49:07 UTC
er, make that 5th and 8th, respectively

Comment 3 scott.m.mcdermott+rh-omnisys-bugs 2010-09-17 17:45:28 UTC
hah, of course, after waiting two weeks, I finally submit
the bug here and the upstream maintainer responds.  He says
he'll roll the patch in "soonish."

I will update this bug once it's been done, and hopefully we
can cut a new package and get it out as an update.

Comment 4 scott.m.mcdermott+rh-omnisys-bugs 2010-09-19 18:43:53 UTC
From maintaner Bas Zoetekouw today: "Just checked into
trunk, and made a new release."  I verified it's
upstream.

Could we get a new release to -updates ? Thanks.

Comment 5 Fedora Update System 2010-09-21 14:06:40 UTC
pinfo-0.6.10-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/pinfo-0.6.10-1.fc14

Comment 6 Fedora Update System 2010-09-21 14:10:30 UTC
pinfo-0.6.10-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/pinfo-0.6.10-1.fc13

Comment 7 Fedora Update System 2010-09-22 00:35:16 UTC
pinfo-0.6.10-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pinfo'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/pinfo-0.6.10-1.fc13

Comment 8 Fedora Update System 2010-09-27 03:57:37 UTC
pinfo-0.6.10-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2010-09-30 10:29:22 UTC
pinfo-0.6.10-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.