$ rpm -q xterm xterm-379-2.fc36.x86_64 $ xterm [Note: the terminal is 80x24] $ printf '\033[6;0H\033[10000D\033[K' Segmentation fault (core dumped) It happens because this calculation in CursorBack()... int length = in_row * MaxRows(screen); offset += ((-offset) / length + 1) * length; ...allows the offset to be set to exactly 'length' if the offset was a negative multiple of 'length', and that places the cursor off the bottom of the screen. Discovered this while using 'sbt' which for reasons best known to itself does actually output '\033[10000D' quite a lot.
Looks like the proper place to fix this is in set_cur_row, e.g., something like this (to replace the latter two assert's): value = Max(0, Min(LastRowNumber(screen), value)); set_cur_col could use a similar fix. (I'm debugging an unrelated change in xterm at the moment...)
Putting a check there would stop the crash, but would it place the cursor in the correct place? Certainly one could argue that someone doing 10000 back-arrows doesn't actually care where the cursor will end up, but if we are being pedantic then if the cursor ended up at exactly -(width*height) then it should actually appear at (0,0). I think the offset correction quoted above is wrong here and it should be ((-offset-1) / length + 1) * length .
sure - but the position of the cursor isn't the topic of this bug report (improving the calculation is something that I'd add in a separate item).
Actually the fix I just committed simply disallows wrapping before the beginning of the screen, and does not alter the expression. Looking at the code, it seems that's been a possibility from very old versions, but the current form was from my changes for left/right margins in 2012. I have a hunch that the original intent was (but not implemented) disallow backing up the cursor before a line which wasn't wrapped. Looking at sbt -- https://github.com/sbt/sbt -- and noting that gnome-terminal does not appear to implement the reverse-wrapping, I suppose that someone thought that this was a good way to get to the beginning of the current line. Someone who knew more about escape sequences might have used HPA to jump to the beginning of the line.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
A fix has been applied for xterm-380
FEDORA-2023-41985be6fa has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-41985be6fa
FEDORA-2023-41985be6fa has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-41985be6fa` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-41985be6fa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-41985be6fa has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.