[Bug 59044] New: lldb.exe: After breakpoint got hit and next character is entered, cursor jumps a few lines upwards

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=59044

Bug ID: 59044
           Summary: lldb.exe: After breakpoint got hit and next character
                    is entered, cursor jumps a few lines upwards
           Product: Wine
           Version: 10.19
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: programs
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Created attachment 79811
  --> http://bugs.winehq.org/attachment.cgi?id=79811
steps to reproduce, and a workaround-patch

I tried using lldb.exe from the llvm-mingw-nightly package.
It kind of works, can attach to process, create breakpoints,
stops at breakpoints, shows source.

But one thing I noticed is when hitting a breakpoint and when entering
the first character of the next command,
the cursor jumps a few lines upwards.
By that the output of the next command gets mixed into the previous output.

This happens in both, plain kde-plasma konsole and wineconsole.

From my debugging attempts it looks like in update_read_output
the edit_line's home_y got not updated by lldb.exe printing some lines.

Attached file contains my steps to reproduce it with
a debian trixie and with winehq packages.
At the end there is a workaround I found working well for my purposes.

I selected the component programs, because it looks to be about conhost.exe.

[Bug 59044] lldb.exe: After breakpoint got hit and next character is entered, cursor jumps a few lines upwards

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=59044

Bernhard Übelacker  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://github.com/mstorsjo
                   |                            |/llvm-mingw/releases/downlo
                   |                            |ad/nightly/llvm-mingw-night
                   |                            |ly-ucrt-x86_64.zip
           Keywords|                            |download, source
       Distribution|---                         |Debian

[Bug 59044] lldb.exe: After breakpoint got hit and next character is entered, cursor jumps a few lines upwards

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=59044

Eric Pouech  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Eric Pouech  ---
it could also be a mixed usage of old and new console APIs

a WINEDEBUG=+console trace could be helpful here

TIA

[Bug 59044] lldb.exe: After breakpoint got hit and next character is entered, cursor jumps a few lines upwards

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=59044

--- Comment #2 from Bernhard Übelacker  ---
Created attachment 79814
  --> http://bugs.winehq.org/attachment.cgi?id=79814
+console log (to not interfere with lldb with wineconsole and TERM=dumb)

[Bug 59044] lldb.exe: After breakpoint got hit and next character is entered, cursor jumps a few lines upwards

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=59044

--- Comment #3 from Bernhard Übelacker  ---
Created attachment 79815
  --> http://bugs.winehq.org/attachment.cgi?id=79815
+console picture after reaching breakpoint, before entering a #

Thanks for taking a look, I attached the log in the previous comment and
a picture of the result here.

Using TERM=dumb makes it visible even after hitting the breakpoint,
not just after entering the first character after hitting the breakpoint.

[Bug 59044] lldb.exe: After breakpoint got hit and next character is entered, cursor jumps a few lines upwards

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=59044

Eric Pouech  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #4 from Eric Pouech  ---
thanks

this looks like (didn't check the exact values from log though) a discrepancy
on how lines are folded:
- native when having lines longer than window width fold the line (in
presentation) on several display lines, but keep the y-position at a single
value
(ie you have y-position in screen buffer which gives you the buffer line, and
y-position at display, which can use more than 1 lines).
- Wine OTOH has a fix mapping and fold the long line (hence having full
equivalence of y-position in screen buffer vs y-position at display)
this can be seen by extending the console width: native refolds the lines
according to screen width, while Wine keeps the original screen size

fixing that (and assuming it's the only cause) will require to move line
folding from write time to display time, and implement the reverse operation (y
on display => screen buffer line)
not utterly complicated (except for unix consoles, where we don't have the
resize events)

to be looked at after code freeze (with also the support of esc sequences in
conhost)