[Bug 13188] New: command-line kernel debugger kd display problem

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

Summary: command-line kernel debugger kd display problem
           Product: Wine
           Version: 1.0-rc1
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

No matter how many lines have been output by kd, the input starts at column 1,
at the line immediately following the last input line. e.g.

kd> some_command<enter>
_
^ new input starts from here, even if this line already has some output in it.

The results are:
1. if last command has no output, then the "kd>" prompt will be erased by the
new input.
2. if there are lines of output, then the new input command and the new output
will mix with previous input and output, which makes the screen unreadable.

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #1 from Vitaliy Margolen   2008-05-13 09:46:28 ---
Are you using wineconsole?

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #2 from Yu-Ning Feng   2008-05-13 20:15:26 ---
(In reply to comment #1)
> Are you using wineconsole?

Yes. A seperate window, Windows font, right-click configure, etc.

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #3 from Yu-Ning Feng   2008-05-15 05:52:02 ---
Created an attachment (id=13074)
 --> (http://bugs.winehq.org/attachment.cgi?id=13074)
debug output of cdb debug session

WINEDEBUG=trace+console

cdb does not suffer from this bug. This log is for comparison with that of kd.
Note Line 115. About that moment, the debugger's output has just finished, and
user input began. ReadConsoleW does not appear in the kd session log (another
attachment), in which the corresponding point should be Line 259..

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #4 from Yu-Ning Feng   2008-05-15 06:03:27 ---
Created an attachment (id=13075)
 --> (http://bugs.winehq.org/attachment.cgi?id=13075)
debug output of a kd debug session

Lines from 259 are logged after user input began. Note the coordinate before
that was (4,48), while it was (0,0) afterward.

[Bug 13188] command-line kernel debugger kd display problem

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

Yu-Ning Feng  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|-unknown                    |kernel32

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #5 from Yu-Ning Feng   2008-05-15 17:21:17 ---
Created an attachment (id=13088)
 --> (http://bugs.winehq.org/attachment.cgi?id=13088)
backtrace after something wrong happened

1. The pos{X=0x1 Y=0x9} passed to SetConsoleCursorPosition was wrong. In this
case, it should have been {X=0x4 Y=0xe} (previous output had 5 lines).

2. Being different from what appeared to be in the backtrace, ReadConsoleW did
not call SetConsoleCursorPosition directly, CONSOLE_Readline did, according to
the source code. Since ctx is initialized in CONSOLE_Readline and finally
passed to SetConsoleCursorPosition, the problematic place should be in
CONSOLE_Readline.

3. I have tried to find the accurate point. However, before the problematic
SetConsoleCursorPosition, breakpoint CONSOLE_Readline was never triggered,
which stopped me from going further.

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #6 from Yu-Ning Feng   2008-05-16 03:02:15 ---
(In reply to comment #1)

After some effort debugging, I found this bug to be a sync problem.

kd runs in 2 threads. WriteConsole[AW] and ReadConsoleW are in different
threads. Most of the time, CONSOLE_Readline is called before a series of
WriteConsole[AW]. When CONSOLE_Readline is waiting for input at

809     while (!ctx.done && !ctx.error && WCEL_Get(&ctx, &ir))

it will be swapped out, and WriteConsole[AW] is swapped in, updates the window
by some output. When CONSOLE_Readline is swapped in again, the ctx is already
outdated, causing the echo be at a wrong place.

A solution could be to add a GetConsoleScreenBufferInfo between

809     while (!ctx.done && !ctx.error && WCEL_Get(&ctx, &ir))

and

854             SetConsoleCursorPosition(ctx.hConOut, WCEL_GetCoord(&ctx,
ctx.ofs));

As not involved in developing, the solution may be not elegant. With the reason
discovered, however, a proper solution should be easy to get.

Really looking forward to the bug being resolved in the coming release.

[Bug 13188] command-line kernel debugger kd display problem

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

Kirill K. Smirnov  changed:

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

--- Comment #7 from Kirill K. Smirnov   2008-05-16 07:15:42 ---
What is kd? Please, provide a link to download location, if possible.

[Bug 13188] command-line kernel debugger kd display problem

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

Yu-Ning Feng  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://www.microsoft.com/whd
                   |                            |c/devtools/debugging/default
                   |                            |.mspx
         Difficulty|---                         |Hours

[Bug 13188] command-line kernel debugger kd display problem

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

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Difficulty|Hours                       |---

--- Comment #8 from Dmitry Timoshkov   2008-05-16 08:32:51 ---
That's a developer's field.

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #9 from Yu-Ning Feng   2008-05-16 16:06:57 ---
Created an attachment (id=13106)
 --> (http://bugs.winehq.org/attachment.cgi?id=13106)
fix the kd display problem bug

This patch fixes the kd display problem bug. It is diff'ed against 1.0-rc1
release code.

The "rewrite" path is tested with kd. Other paths(leaving blanks, forget) not
tested.

[Bug 13188] command-line kernel debugger kd display problem

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

Eric Pouech  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1

--- Comment #10 from Eric Pouech   2008-05-17 09:42:23 ---
the patch isn't correct, the start position is always kept (try using home and
end keys, you'll see it's not modified)
what seems to be not 100% compatible with what MS does is that when echoing a
single char we should simply use WriteConsole and not going back to updating
the whole buffer once again
I'll send a patch later on (this week end likely)
A+

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #11 from Yu-Ning Feng   2008-05-17 13:32:15 ---
(In reply to comment #10)
> the patch isn't correct, the start position is always kept (try using home and
> end keys, you'll see it's not modified)

<home> and <end> keys work as expected to me. As I understand (from the
original code), the start position is kept before <enter> is hit. That is right
and thus I do not change that. The start position is not kept (updated) when
other threads output before input is done. My patch does this.

Or, do I misunderstand your words?

BTW, M-<backspace> (M-<DEL> in emacs' term) does nothing in emacs editing mode.
I expect it to kill a word backward. A bug? Another topic, though.
> what seems to be not 100% compatible with what MS does is that when echoing a
> single char we should simply use WriteConsole and not going back to updating
> the whole buffer once again

Discard the "rewrite" path then. The "forget" path may behave as you describe.
> I'll send a patch later on (this week end likely)

It is much better that a developer handles the bug, and thanks.

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #12 from Eric Pouech   2008-05-18 02:29:46 ---
Created an attachment (id=13143)
 --> (http://bugs.winehq.org/attachment.cgi?id=13143)
Patch

In reply to comment #11:
- the start position of the edition is never changed (in windows). Using a
simple test program that replicates what it's described in this PR (one thread
reading a string on console, a second one calling WriteConsole), it's clear
that the start position is not changed (e.g. using <home> key brings back the
cursor to its initial position)
- you can switch to the emacs emulation mode by right-clicking in the
wineconsole window (if you're using the user backend)

let me know if the attached patch fixes your issues.

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #13 from Yu-Ning Feng   2008-05-18 04:36:01 ---
(In reply to comment #12)
> Created an attachment (id=13143)

--> (http://bugs.winehq.org/attachment.cgi?id=13143) [details]
> Patch

Applied to my local tree and tested. Not work as expected. See below.
> In reply to comment #11:
> - the start position of the edition is never changed (in windows). Using a
>
> simple test program that replicates what it's described in this PR (one thread
> reading a string on console, a second one calling WriteConsole), it's clear
> that the start position is not changed (e.g. using <home> key brings back the
> cursor to its initial position)

I see. However, it is(seems) not true. I verified just now in my Windows xp
sp2(host, target is another machine also running xp). Here is a kd session:

(copyright messages)

Opened \.\com1
Waiting to reconnect...
verConnected to Windows XP 2600 x86 compatible target, ptr64 FALSE
~~~
(...)
kd> command
    ^
I input 'ver' before connect, and 'command' after being prompted. Then, <home>
hit and the cursor is at where '^' indicates. As you can see, start position is
changed. If not, 'ver' would have been echo'ed before copyright messages, which
is the behavior of original code. I have tried that, with your patch applied,
'ver' and 'command' appear at the right place, but after <home> hit, the cursor
is at the very beginning, as you would expect.
> - you can switch to the emacs emulation mode by right-clicking in the
>
> wineconsole window (if you're using the user backend)

I was in emacs mode. Most keys work, say, C-a, C-e, C-k, M-d etc., but not
M-<backspace>. Anyway, I cannot help to say I like this emacs mode feature very
much.
> let me know if the attached patch fixes your issues.

Hope you can confirm what I have described above.

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #14 from Yu-Ning Feng   2008-05-18 04:59:06 ---
(In reply to comment #13)
> I input 'ver' before connect, and 'command' after being prompted. Then, <home>
> hit and the cursor is at where '^' indicates. As you can see, start position is
> changed. If not, 'ver' would have been echo'ed before copyright messages, which
> is the behavior of original code. I have tried that, with your patch applied,

Please ignore the misleading "if not..." sentence, though it is correct.

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #15 from Eric Pouech   2008-05-21 14:40:12 ---
I think there are two different issues:
- the "start position" I'm talking about is not necessary the position of the
first character echoed, but the cursor position when ReadConsole is called. In
your last try, "ver" is keyed in before the ReadConsole is called. It's the 'c'
of  command the "real" start position. The current difference between windows
and wine seems to be that windows echoes a character as soon it's keyed in
while Wine only does it while inside ReadConsole. So the behavior you describe
in your last post is "expected".
- the patch I sent deals with changing the cursor position while waiting in
ReadConsole. And you the tests I've done don't show that the "start position"
(as I described earlier) is changed.
- however, I'm still unsure (and I reread your first post) of the issue you
really have. Could precisely describe the difference you see between wine and
windows

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #16 from Yu-Ning Feng   2008-05-22 09:07:01 ---
(In reply to comment #15)
> I think there are two different issues:
> - the "start position" I'm talking about is not necessary the position of the
>
> ..
> in your last post is "expected".

Understand. Thanks for clarifying. Don't like that mixed behavior, though. With
your patch applied, if I made a mistake and <Backspace>, I would end up messing
up my display. Please see my attachment later. Note that I just hit
<Backspace>, did not retype 'vercomman'. Went on typing would have a similar
result with that of original wine 1.0-rc1.
> - however, I'm still unsure (and I reread your first post) of the issue you
>
> really have. Could precisely describe the difference you see between wine and
> windows

I am attaching screenshots, FYI.

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #17 from Yu-Ning Feng   2008-05-22 09:09:13 ---
Created an attachment (id=13241)
 --> (http://bugs.winehq.org/attachment.cgi?id=13241)
a kd session with Eric's patch applied

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #18 from Yu-Ning Feng   2008-05-22 09:10:47 ---
Created an attachment (id=13242)
 --> (http://bugs.winehq.org/attachment.cgi?id=13242)
a kd session on original wine 1.0-rc1

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #19 from Yu-Ning Feng   2008-05-22 09:12:19 ---
Created an attachment (id=13243)
 --> (http://bugs.winehq.org/attachment.cgi?id=13243)
a kd session on Windows

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #20 from FENG Yu Ning   2008-06-14 21:49:37 ---
So the issue will be left as is?

[Bug 13188] command-line kernel debugger kd display problem

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

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #21 from Austin English   2008-12-13 17:31:34 ---
Is this still an issue in current (1.1.10) or newer wine?

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #22 from Austin English   2009-06-16 14:13:14 ---
Eric, ping.

[Bug 13188] command-line kernel debugger kd display problem

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

--- Comment #23 from Austin English   2009-06-16 14:22:39 ---
Is this still an issue in current (1.1.23 or newer) wine?

[Bug 13188] command-line kernel debugger kd display problem

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

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |ABANDONED

--- Comment #24 from Austin English   2009-12-31 12:28:27 ---
No response in a year and a half, marking abandoned.

[Bug 13188] command-line kernel debugger kd display problem

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

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #25 from Dmitry Timoshkov   2009-12-31 23:45:19 ---
Closing abandoned.