[konsole] [Bug 372991] Terminal gets stuck on interrupting a program that is outputting, preventing further output from being shown

[Peter Wu]

https://bugs.kde.org/show_bug.cgi?id=372991

--- Comment #10 from Peter Wu <peter at lekensteyn.nl> ---
(In reply to Hello71 from comment #5)
> this is clearly some type of race condition, since it only breaks sometimes.
> 
> you can try "taskset -c 0 konsole", which for me fixes the problem.

Even with "tasksel -c 0 konsole" I can reproduce the problem if I repeat the
experiment often enough.

(In reply to Egmont Koblinger from comment #9)
> Without having looked at the code, I'm wondering how FIONREAD can return
> 0... I mean I guess it's preceded by a select() or similar that waits for
> data to appear, and the reason for reaching FIONREAD is that it signaled
> some data available. But maybe this is where somehow (how?) multithreaded
> race condition-y stuff kicks in.

Comparing the "perf trace" output you can basically observe the following
pattern:
GOOD:
xxd: write(</dev/pts/7>, ..., count: 68) ...
konsole: write(</dev/ptmx>, ..., count: 1) = 1    (is this "^C"?)
konsole: poll() = 1
xxd: ... [continued] write = 67
konsole: ioctl(</dev/ptmx>, FIONREAD) = 0
konsole: read(</dev/ptmx>, ..., count: 2) = 2
bash: ... [continued] wait4() = (xxd)

BAD:
xxd: write(</dev/pts/7>, ..., count: 68) ...
konsole: write(</dev/ptmx>, ..., count: 1) = 1
konsole: poll() = 1
konsole: ioctl(</dev/ptmx>, FIONREAD) = 0
konsole: read(</dev/ptmx>, ..., count: 0) = 0
xxd: ... [continued] write = 67
bash: ... [continued] wait4() = (xxd)


In another (newer) trace I found this:
GOOD:
xxd: write(</dev/pts/60>, ..., count: 68) ...
konsole: write(</dev/ptmx>, ..., count: 1) = 1
konsole: poll() = 1
konsole: ioctl(</dev/ptmx>, FIONREAD) = 0
konsole: read(</dev/ptmx>, ..., count: 2) = 2
xxd: ... [continued] write = 67
bash: ... [continued] wait4() = (xxd)

BAD:
xxd: write(</dev/pts/60>, ..., count: 68) = 67
konsole: write(</dev/ptmx>, ..., count: 1) = 1
konsole: poll() = 1
konsole: ioctl(</dev/ptmx>, FIONREAD) = 0
konsole: read(</dev/ptmx>, ..., count: 0) = 0
bash: ... [continued] wait4() = (xxd)


So apparently there is a pending write from the slave device which seems to
trigger poll (I guess?). But when the input buffer of the master device is
checked, the data is not present (FIONREAD.available=0, hence read count 0).
Maybe it is a Linux kernel issue (currently 4.9.5-1-ARCH) or reliance on
invalid assumptions?

It shouldn't hurt to not disable the file watcher? If the class is destroyed,
then the watcher is killed anyway?

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