https://bugs.kde.org/show_bug.cgi?id=372991
--- Comment #10 from Peter Wu <pe...@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 watching all bug changes.
