Console issues in recent git

[Jerome Leclanche]

Anyone else's terminal emulators really acting up since the last git
batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if
there is a wine process running, until it's killed. This is probably a
konsole bug, but still...

CC eric.

--
J. Leclanche

[Reece Dunn]

On 2 September 2010 02:29, Jerome Leclanche  wrote:
> Anyone else's terminal emulators really acting up since the last git
> batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if
> there is a wine process running, until it's killed. This is probably a
> konsole bug, but still...

On gnome-terminal, running an application (StarCraft 2) via a bash
script, using the arrow keys does not cycle through the history and
pressing enter does not output a newline so the "user@computer: " bit
gets outputted next to the other one. This is after the second run.

I haven't had chance to investigate this yet (raise a bug report or
perform a bisect), but might be due to the wineconsole work recently
committed.

- Reece

[Saulius Krasuckas]

* On Thu, 2 Sep 2010, Reece Dunn wrote:
> On 2 September 2010 02:29, Jerome Leclanche  wrote:
> > Anyone else's terminal emulators really acting up since the last git
> > batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if
> > there is a wine process running, until it's killed. This is probably a
> > konsole bug, but still...
>
> On gnome-terminal, running an application (StarCraft 2) via a bash
> script, using the arrow keys does not cycle through the history and
> pressing enter does not output a newline so the "user@computer: " bit
> gets outputted next to the other one. This is after the second run.

Similar things happens here with xterm.  Killing wine processes and 
wineserver doesn't help me and xterm should be killed afterwards.

S.

[Octavian Voicu]

On Thu, Sep 2, 2010 at 4:29 AM, Jerome Leclanche  wrote:
> Anyone else's terminal emulators really acting up since the last git
> batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if
> there is a wine process running, until it's killed. This is probably a
> konsole bug, but still...

Actually, I've run into this yesterday, not sure what the cause is
(could be Eric's console patches, not cleaning up properly).

To fix it, type `reset' in the offending terminal (even if you don't
see anything you type, just type <enter>reset<enter>). It will reset
all terminal attributes.

Octavian

[Eric Pouech]

to summarize a bit:
- wineserver doesn't reset the terminal attributes if it's killed (to be
fixed)
- command line edition is not supported. it was not supported either in
previous console code (outside of wineconsole). this is to be provided in
next patches
- I have no idea on the blank outputs. is the wine program you're testing
the first one to be launched ?
- <enter> issues should be looked at (sounds like bad \r, \n, \n\r
conversions)

A+

2010/9/2 Octavian Voicu
> On Thu, Sep 2, 2010 at 4:29 AM, Jerome Leclanche 
> wrote:
> > Anyone else's terminal emulators really acting up since the last git
> > batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if
> > there is a wine process running, until it's killed. This is probably a
> > konsole bug, but still...
>
> Actually, I've run into this yesterday, not sure what the cause is
> (could be Eric's console patches, not cleaning up properly).
>
> To fix it, type `reset' in the offending terminal (even if you don't
> see anything you type, just type <enter>reset<enter>). It will reset
> all terminal attributes.
>
> Octavian

[Eric Pouech]

Le 02/09/2010 03:29, Jerome Leclanche a écrit :
> Anyone else's terminal emulators really acting up since the last git
> batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if
> there is a wine process running, until it's killed. This is probably a
> konsole bug, but still...
>
> CC eric.
>
> --
> J. Leclanche

not really
is the program you're running a CUI or GUI exec ?
if it's a CUI, then it's normal as it's supposed to get all your current 
input
if it's a GUI (without a win32 console), then it's more questionnable

A+

[Jerome Leclanche]

It's a GUI.

J. Leclanche

On Thu, Sep 2, 2010 at 8:41 PM, Eric Pouech  wrote:
> Le 02/09/2010 03:29, Jerome Leclanche a écrit :
> > Anyone else's terminal emulators really acting up since the last git
> > batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if
> > there is a wine process running, until it's killed. This is probably a
> > konsole bug, but still...
> >
> > CC eric.
> >
> > --
> > J. Leclanche
>
> not really
> is the program you're running a CUI or GUI exec ?
> if it's a CUI, then it's normal as it's supposed to get all your current
> input
> if it's a GUI (without a win32 console), then it's more questionnable
>
> A+
>
> --
> Eric Pouech
> "The problem with designing something completely foolproof is to
> underestimate the ingenuity of a complete idiot." (Douglas Adams)

[Jerome Leclanche]

To be more specific, it happens on any and every wine program.

J. Leclanche

On Thu, Sep 2, 2010 at 8:44 PM, Jerome Leclanche  wrote:
> It's a GUI.
>
> J. Leclanche
>
> On Thu, Sep 2, 2010 at 8:41 PM, Eric Pouech  wrote:
> > Le 02/09/2010 03:29, Jerome Leclanche a écrit :
> > > Anyone else's terminal emulators really acting up since the last git
> > > batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if
> > > there is a wine process running, until it's killed. This is probably a
> > > konsole bug, but still...
> > >
> > > CC eric.
> > >
> > > --
> > > J. Leclanche
> >
> > not really
> > is the program you're running a CUI or GUI exec ?
> > if it's a CUI, then it's normal as it's supposed to get all your current
> > input
> > if it's a GUI (without a win32 console), then it's more questionnable
> >
> > A+
> >
> > --
> > Eric Pouech
> > "The problem with designing something completely foolproof is to
> > underestimate the ingenuity of a complete idiot." (Douglas Adams)

[Austin English]

On Thu, Sep 2, 2010 at 2:44 PM, Jerome Leclanche  wrote:
> To be more specific, it happens on any and every wine program.

I see it as well, though an easy workaround is to run 'reset'. After
that, terminal returns to normal.

[PleegWat]

On 09/02/2010 09:41 PM, Eric Pouech wrote:
> Le 02/09/2010 03:29, Jerome Leclanche a écrit :
> > Anyone else's terminal emulators really acting up since the last git
> > batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if
> > there is a wine process running, until it's killed. This is probably a
> > konsole bug, but still...
> >
> > CC eric.
> >
> > --
> > J. Leclanche
>
> not really
> is the program you're running a CUI or GUI exec ?
> if it's a CUI, then it's normal as it's supposed to get all your current
> input
> if it's a GUI (without a win32 console), then it's more questionnable
>
> A+

I'm getting this problem as well, and I did a quick test - it also 
affects notepad and winecfg, although in those cases both the prompt and 
proper terminal function come back when the program exits. For many 
games, the prompt comes back shortly after the game was fully loaded. 
For these proper terminal function is not restored.

Could it be that a fork() is happening somewhere, and that the child 
(rather than the parent) tries to restore the terminal on exit?
And I'm not 100% on how this works in windows, but should the prompt be 
coming back at all before the program has exited? Could someone test 
this? Two programs I know this happens with are World of Warcraft and 
Starcraft 2.

PleegWat

[Eric Pouech]

Hi,

after the console patch series, it appears a couple of problems are left 
over:

to summarize, the problems with their status:

A/ when a program is running, no echo is seen for characters being typed.

B/ after running a wine program, the console is a bad shape and needs 
'reset' to get back in a sane state.

Status
A/ IMO, it's barely a bug as you can't make an hypothesis about what a 
program will do with character input. However, it's a change from 
previous behavior as one could see the echo. This only happens when the 
running program doesn't read its input. However, since now wine runs in 
raw console mode, it's likely the typed characters will not be useful to 
the shell when the program exits (as the shell will run in cooked mode 
and will start with an empty buffer). Low priority for a fix (if any)

B/ actually, it's likely a race (in the simple way of running one single 
program) about resetting the console in decent shape. Could the folks 
having the issue try the attached patch (file conclean) to see if it 
helps ? (I never could reproduce it here, tested with konsole & xterm. 
If you still see the issue, please detail console and shell program)
Clearly an annoying impact for most users, need fixing.

Actually, there's another issue with the same symptoms:
1- program A is launched from shell
2- program A starts another program B (for example winedbg when a fault 
occurs)
3- at this point, both A & B can read/write to the console
4- program A exits. As it way the group leader, B is set into the 
background and loses (read) access to the console.
5- When B exits, as it no longer has access to the console, the state of 
the console cannot be reset to normal

this was happening before the patch series, but as we didn't tweak the 
console, it was just fine (except that some program dies when in the 
background, eg winedbg)
fix will not be 100% easy

among the potential fixes:
S1: no longer do the console attribute management in server, but only in 
kernel32, and only for the livespan of the process creating the bare 
console. this means that the console will not be accessible to the 
children of this process after its death (but I don't see how to do it 
anyway)
S2: when the process that created the bare console, it's about to 
terminate it should wait for all its children to die. This would require 
a cloak of invisibility (from the win32 space) to let the other 
win32-process see that it actually died.
S3: combine S1 and S2
comments welcome

also, I may have forgotten (or misunderstood) some issue reports. Don't 
hesitate to jump in.

NB: I also have a patchset ready that shall enable key/arrows support in 
bare console mode (with history bells & whistles... handy for any 
program with a CLI)

A+

[Dmitry Timoshkov]

Eric Pouech  wrote:
> +void close_console( struct process* process)

Shouldn't it be named close_bare_console()? Otherwise it won't compile.

[Alexandre Julliard]

Eric Pouech  writes:
> among the potential fixes:
> S1: no longer do the console attribute management in server, but only
> in kernel32, and only for the livespan of the process creating the
> bare console. this means that the console will not be accessible to
> the children of this process after its death (but I don't see how to
> do it anyway)
> S2: when the process that created the bare console, it's about to
> terminate it should wait for all its children to die. This would
> require a cloak of invisibility (from the win32 space) to let the
> other win32-process see that it actually died.
> S3: combine S1 and S2

I think S1 is the way to go. I also think we should not put the console
in raw mode until the app actually calls ReadConsole or similar
function. The vast majority of apps never need fancy console input.

[PleegWat]

On 09/06/2010 10:00 PM, Eric Pouech wrote:
> Actually, there's another issue with the same symptoms:
> 1- program A is launched from shell
> 2- program A starts another program B (for example winedbg when a fault
> occurs)
> 3- at this point, both A & B can read/write to the console
> 4- program A exits. As it way the group leader, B is set into the
> background and loses (read) access to the console.
> 5- When B exits, as it no longer has access to the console, the state of
> the console cannot be reset to normal
>
> this was happening before the patch series, but as we didn't tweak the
> console, it was just fine (except that some program dies when in the
> background, eg winedbg)
> fix will not be 100% easy

This is probably what I see happening in starcraft 2 and world of 
warcraft. Both of these applications use a launcher, which in turn 
launches the actual game.

PleegWat

[Reece Dunn]

On 6 September 2010 21:00, Eric Pouech  wrote:
> B/ actually, it's likely a race (in the simple way of running one single
> program) about resetting the console in decent shape. Could the folks having
> the issue try the attached patch (file conclean) to see if it helps ? (I
> never could reproduce it here, tested with konsole & xterm. If you still see
> the issue, please detail console and shell program)
> Clearly an annoying impact for most users, need fixing.

For StarCraft 2, the patch does not fix the issue.

+void close_console( struct process* process)

This needs to be s/close_console/close_bare_console/ for it to apply.

+extern int close_bare_console( struct process *process );

And this needs to be s/int/void/ as the function does not return a value.

- Reece

[Eric Pouech]

does the attached patch help with some of the concerns ?
I/ it should allow typing in the console (for all GUI programs) and 
still see output get buffer when the programs exits
II/ reduce the number of cases where the console is in raw mode after 
wine exits
Not all the cases are supposed to be fixed.
For example, this is one example of what still doesn't work

but in this case, the first program is killed at the same time as 
winedbg exits, which shouldn't the case)
what shall remain not fixed is the case where:
- pgm A is started from shell command line
- pgm A spawns child B
- B is a CUI and tries to interact with the console by reading the input
- A dies
I still sometimes see it when exiting winedbg after it has been launched 
upon a fault in a running program... but, something goes wrong here as 
quitting winedbg (B) shouldn't kill the program beeing debugged (A)

what's not yet fixed :
- regression in EOF management

A+

[Reece Dunn]

On 8 September 2010 21:04, Eric Pouech  wrote:
> does the attached patch help with some of the concerns ?
> I/ it should allow typing in the console (for all GUI programs) and still
> see output get buffer when the programs exits
> II/ reduce the number of cases where the console is in raw mode after wine
> exits
> Not all the cases are supposed to be fixed.
> For example, this is one example of what still doesn't work
>
> but in this case, the first program is killed at the same time as winedbg
> exits, which shouldn't the case)
> what shall remain not fixed is the case where:
> - pgm A is started from shell command line
> - pgm A spawns child B
> - B is a CUI and tries to interact with the console by reading the input
> - A dies
>
> I still sometimes see it when exiting winedbg after it has been launched
> upon a fault in a running program... but, something goes wrong here as
> quitting winedbg (B) shouldn't kill the program beeing debugged (A)
>
> what's not yet fixed :
> - regression in EOF management

This fixes the issue with StarCraft 2.

Thanks for looking into this,
- Reece

[Jerome Leclanche]

Eric,

When running a program with "r" in winedbg, I get:
fixme:winedbg:dbg_run_debuggee Re-running current program with "\r" as
args is broken

Does this have anything to do with the EOL conversion issues?

J. Leclanche

On Wed, Sep 8, 2010 at 9:32 PM, Reece Dunn  wrote:
> On 8 September 2010 21:04, Eric Pouech  wrote:
> > does the attached patch help with some of the concerns ?
> > I/ it should allow typing in the console (for all GUI programs) and still
> > see output get buffer when the programs exits
> > II/ reduce the number of cases where the console is in raw mode after wine
> > exits
> > Not all the cases are supposed to be fixed.
> > For example, this is one example of what still doesn't work
> >
> > but in this case, the first program is killed at the same time as winedbg
> > exits, which shouldn't the case)
> > what shall remain not fixed is the case where:
> > - pgm A is started from shell command line
> > - pgm A spawns child B
> > - B is a CUI and tries to interact with the console by reading the input
> > - A dies
> >
> > I still sometimes see it when exiting winedbg after it has been launched
> > upon a fault in a running program... but, something goes wrong here as
> > quitting winedbg (B) shouldn't kill the program beeing debugged (A)
> >
> > what's not yet fixed :
> > - regression in EOF management
>
> This fixes the issue with StarCraft 2.
>
> Thanks for looking into this,
> - Reece

[Eric Pouech]

Le 09/09/2010 18:13, Jerome Leclanche a écrit :
> Eric,
>
> When running a program with "r" in winedbg, I get:
> fixme:winedbg:dbg_run_debuggee Re-running current program with "\r" as
> args is broken
>
> Does this have anything to do with the EOL conversion issues?

no, it has been broken for years
(if you really used 'r' or 'r foo bar' as command in winedbg)
A+

[Jerome Leclanche]

Hi Eric,

Ive been running your patch for a couple of days and I just noticed
another case where it's not resetting terminal properties:
 - Run a program in winedbg (in my case, it was in a virtual desktop, too)
 - Wait for program to crash
 - Hit ctrl-c
 - (?) Terminate process in the virtual desktop when it asks
 - When exiting, terminal isn't cleared

I haven't really managed to repro, but these are the steps that lead
to my issue. Hope it helps.

J. Leclanche

On Thu, Sep 9, 2010 at 8:15 PM, Eric Pouech  wrote:
> Le 09/09/2010 18:13, Jerome Leclanche a écrit :
> > Eric,
> >
> > When running a program with "r" in winedbg, I get:
> > fixme:winedbg:dbg_run_debuggee Re-running current program with "\r" as
> > args is broken
> >
> > Does this have anything to do with the EOL conversion issues?
>
> no, it has been broken for years
> (if you really used 'r' or 'r foo bar' as command in winedbg)
> A+
>
> --
> Eric Pouech
> "The problem with designing something completely foolproof is to
> underestimate the ingenuity of a complete idiot." (Douglas Adams)

[Eric Pouech]

Le 12/09/2010 00:26, Jerome Leclanche a écrit :
> Hi Eric,
>
> Ive been running your patch for a couple of days and I just noticed
> another case where it's not resetting terminal properties:
> - Run a program in winedbg (in my case, it was in a virtual desktop, too)
> - Wait for program to crash
> - Hit ctrl-c
> - (?) Terminate process in the virtual desktop when it asks
> - When exiting, terminal isn't cleared
>
> I haven't really managed to repro, but these are the steps that lead
> to my issue. Hope it helps.
>
> J. Leclanche

what do you mean by virtual desktop ?
A+

[Jerome Leclanche]

Set a 1440x900 virtual desktop in winecfg.

J. Leclanche

On Sun, Sep 12, 2010 at 12:46 PM, Eric Pouech  wrote:
> Le 12/09/2010 00:26, Jerome Leclanche a écrit :
> > Hi Eric,
> >
> > Ive been running your patch for a couple of days and I just noticed
> > another case where it's not resetting terminal properties:
> >  - Run a program in winedbg (in my case, it was in a virtual desktop, too)
> >  - Wait for program to crash
> >  - Hit ctrl-c
> >  - (?) Terminate process in the virtual desktop when it asks
> >  - When exiting, terminal isn't cleared
> >
> > I haven't really managed to repro, but these are the steps that lead
> > to my issue. Hope it helps.
> >
> > J. Leclanche
>
> what do you mean by virtual desktop ?
> A+
>
> --
> Eric Pouech
> "The problem with designing something completely foolproof is to
> underestimate the ingenuity of a complete idiot." (Douglas Adams)

[Eric Pouech]

Le 12/09/2010 14:09, Jerome Leclanche a écrit :
> Set a 1440x900 virtual desktop in winecfg.

what do you mean by:
- run a program in winedbg (in my case, it was in a virtual desktop, 
too) => does it mean you got 2 virtual desktops ? or got a shell running 
in one virtual desktop ?
- (?) Terminate process in the virtual desktop when it asks => where 
does this prompt come from ?
A+