Re: [Crash-utility] crash endlessly looping on stdout error

----- Original Message ----- > We have a recurring problem in our crash analysis system, where remote users > get disconnected and crash starts endlessly looping trying to write to stdout. > An strace of a recent instance is looping on: > > write(1, " JIFFIES\n", 10) = -1 EIO (Input/output error) > > but that isn't always the output string. > > this is a problem in out shared environment because the orphaned crash tasks > eat up the CPUs, and we don't have the privilege to kill each others tasks. > > thanks, > --Guy Hmmm, upon initial glance, this seemed to be related to the crash-5.0.2 fix that you guys reported: - Fix to prevent a crash session that is run over a network connection that is killed/removed from going into 100% cpu-time loop. Without the patch, the behavior of the built-in readline() library call in gdb-7.0 has changed such that the function returns when the EOF is encountered on /dev/tty, and the crash session goes into an endless loop; whereas in gdb-6.1, the readline() call never returns because the crash session gets killed while running in the library code. (anderson(a)redhat.com) But if the orphaned task is repetetively writing the same thing, it would never get to the next readline() call, where it would kill itself. Taking your example, the "JIFFIES" write() is part of a "timer" command, but I'm trying to understand how/why the command is not just completing a series of (failed) fprintf's, and then falling into the next readline() -- where it should kill itself? By any chance was the remote caller doing a "repeat" command on the live system, or something like that? (sounds doubtful since you'd have to have root privileges to do that...)