This can be reproduced with the following bash command: i=0; while true; do echo "$i $i $i $i $i $i $i $i $i $i $i" >&2; i=$((i+1)); done Once the numbers printed grow larger than about 2.1 million, Konsole starts repeatedly printing a message to its parent terminal: HistoryFile::add.seek: Invalid argument And if you try to scroll back, you'll see empty lines right above the first visible line. If you scroll more back, you'll get to the last line which has successfully been appended to the scrollback buffer. Saving the scrollback also gives this result, i.e. lines between the last screen and last successful scrollback update are completely empty. Reproducible: Always Steps to Reproduce: 0. Set scrollback to Unlimited in Konsole settings 1. Run Konsole (from another terminal to see its stderr) 2. Run this command in bash inside Konsole session: i=0; while true; do echo "$i $i $i $i $i $i $i $i $i $i $i" >&2; i=$((i+1)); done 3. Wait until numbers printed grow larger than about 2.1 million 4. Try to scroll back Actual Results: Nearest scrollback lines get lost Expected Results: The complete scrollback buffer should be saved correctly This happens both in KDE 4.14 and KF5.
I actually hit this. As a distro maintainer, I started a shell session on 11 December to start porting our base system to PowerPC. I then started building Qt 5.7 (and all its dependencies). Then KDE Frameworks 5. While building Phonon, I noticed weird corruption of the build results. I am using Konsole 16.08.3 with KF 5.28. When I saved the shell output, it was in very weird pieces/chunks, like this (the first few lines of the resultant file, unedited): storyn. /t mp/envi onment'. ch is o non-c ass type ‘int’ operator=(const QStyleOptionGraphicsItem&)’ first required here 64 -ggdb -mcpu=G3 -fno-omit-frame-pointer -Wall -Wextra -Wsign-compare -Wundef -Wpointer-arith -Wvolatile-registe It seems to me that somewhere, a signed 32-bit integer is being used: -rw------- 1 awilcox awilcox 2147485900 Jan 23 16:03 /tmp/konsole-hF4401.history That `ls -l` was run at 16:15 and Phonon was still building, so all the output was just being lost. Actually, the previous output was also being corrupted.
*** This bug has been marked as a duplicate of bug 374259 ***