[Crash-utility] crash CPU bound waiting for user response

[Dave Anderson]

D. Hugh Redelmeier wrote:
> I am running crash in a shell window of JOVE.  JOVE is an EMACS-subset
> editor.
> 
> crash isn't really happy.  Here is an example:
>     crash> task
>     WARNING: terminal is not fully functional
>     -  (press RETURN)
> 
> ==> It does not say in what way the terminal is not fully functional.  That seems like a bug.

Sorry, but I have no idea where that WARNING message is coming from,
i.e., it's not coming from the crash/gdb code base, nor does the
string "functional" show up in any of the external libraries.  There
is a crash function that prints "WARNING:" before a passed-in message,
but no instances of it issue that "functional" message.  And the
"(press RETURN)" is most certainly not associated with the crash/gdb
code base.

So I don't know what the "It" is.

> 
> ==> Worse: while it is awaiting my RETURN, it is burning 100% of the CPU!
> 
> Here is what "ps laxgwf" says about the crash process and its child.
> 
> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
> 4     0  4426  4406  25   0 416812 332764 -     R+   pts/5     80:36              |               |           \_ crash --readnow /usr/lib/debug/lib/modules/2.6.21-1.3228.fc7/vmlinux /var/crash/2007-07-02-13:42/vmcore
> 0     0  4989  4426  18   0  73976   740 -      S+   pts/5      0:00              |               |               \_ /usr/bin/less -E -X -Ps -- MORE --  forward\: <SPACE>, <ENTER> or j  backward\: b or k  quit\: q
> 
> strace of the crash process shows an infinite sequence of:
>     wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
>     wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
>     wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
>     wait4(4989, 0x7fffcd9cae90, WNOHANG, NULL) = 0
> 
> This is very wasteful.
> 
> There are other ways to get into this state.  Other places less is
> being used and is waiting.  Probably wherever less is used even if it
> isn't waiting.
> 
> I just tested: this problem exists when using a normal xterm.

Yeah, I have seen this on occasions, but I have never been able
to reproduce it on demand.  There was a patch suggestion a while ago,
but I deferred it until I could reliably reproduce it for testing
before taking it in.

Dave