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: [email protected] ReportedBy: [email protected]
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.
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #1 from Vitaliy Margolen [email protected] 2008-05-13 09:46:28 --- Are you using wineconsole?
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #2 from Yu-Ning Feng [email protected] 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.
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #3 from Yu-Ning Feng [email protected] 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..
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #4 from Yu-Ning Feng [email protected] 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.
http://bugs.winehq.org/show_bug.cgi?id=13188
Yu-Ning Feng [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |kernel32
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #5 from Yu-Ning Feng [email protected] 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.
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #6 from Yu-Ning Feng [email protected] 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.
http://bugs.winehq.org/show_bug.cgi?id=13188
Kirill K. Smirnov [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #7 from Kirill K. Smirnov [email protected] 2008-05-16 07:15:42 --- What is kd? Please, provide a link to download location, if possible.
http://bugs.winehq.org/show_bug.cgi?id=13188
Yu-Ning Feng [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.microsoft.com/whd | |c/devtools/debugging/default | |.mspx Difficulty|--- |Hours
http://bugs.winehq.org/show_bug.cgi?id=13188
Dmitry Timoshkov [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Difficulty|Hours |---
--- Comment #8 from Dmitry Timoshkov [email protected] 2008-05-16 08:32:51 --- That's a developer's field.
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #9 from Yu-Ning Feng [email protected] 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.
http://bugs.winehq.org/show_bug.cgi?id=13188
Eric Pouech [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1
--- Comment #10 from Eric Pouech [email protected] 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+
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #11 from Yu-Ning Feng [email protected] 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.
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #12 from Eric Pouech [email protected] 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.
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #13 from Yu-Ning Feng [email protected] 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.
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #14 from Yu-Ning Feng [email protected] 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.
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #15 from Eric Pouech [email protected] 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
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #16 from Yu-Ning Feng [email protected] 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.
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #17 from Yu-Ning Feng [email protected] 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
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #18 from Yu-Ning Feng [email protected] 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
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #19 from Yu-Ning Feng [email protected] 2008-05-22 09:12:19 --- Created an attachment (id=13243) --> (http://bugs.winehq.org/attachment.cgi?id=13243) a kd session on Windows
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #20 from FENG Yu Ning [email protected] 2008-06-14 21:49:37 --- So the issue will be left as is?
http://bugs.winehq.org/show_bug.cgi?id=13188
Austin English [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
--- Comment #21 from Austin English [email protected] 2008-12-13 17:31:34 --- Is this still an issue in current (1.1.10) or newer wine?
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #22 from Austin English [email protected] 2009-06-16 14:13:14 --- Eric, ping.
http://bugs.winehq.org/show_bug.cgi?id=13188
--- Comment #23 from Austin English [email protected] 2009-06-16 14:22:39 --- Is this still an issue in current (1.1.23 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=13188
Austin English [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |ABANDONED
--- Comment #24 from Austin English [email protected] 2009-12-31 12:28:27 --- No response in a year and a half, marking abandoned.
http://bugs.winehq.org/show_bug.cgi?id=13188
Dmitry Timoshkov [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Dmitry Timoshkov [email protected] 2009-12-31 23:45:19 --- Closing abandoned.
-
wine-bugs＠winehq.org