Maximus5 / ConEmu

Customizable Windows terminal with tabs, splits, quake-style, hotkeys and more
https://conemu.github.io/
BSD 3-Clause "New" or "Revised" License
8.59k stars 572 forks source link

Conemu hang and garbled output after update to windows 10 1809 build. #1736

Open gjhut opened 6 years ago

gjhut commented 6 years ago

Versions

ConEmu build: 180626 x64 OS version: Windows 10 1809 build Used shell version (Far Manager, git-bash, cmd, powershell, cygwin, whatever): Git-bash (wsl) with Ubuntu 18.04

Problem description

After upgrading to the newest Windows 10 build (1809) the console gives garbled output or hangs when running the below script on the svn command. The svn command used in this script links to the svn.exe file of TortoiseSVN (unfortunately, Ubuntu's svn doesn't work well with a windows filesystem workspace).

The script is supposed to walk through a directory of svn repositories, and update them all. This worked well before the update, and still works when executing it directly with the Ubuntu 18.04 shell in windows.

Steps to reproduce

  1. Have a number of svn workspaces in subdirectories.
  2. Have a TortoiseSVN install (I have 1.10.1, 64 bit installed)
  3. Run the below update bash script.
  4. Observe garbled output (cursor repeatedly seems to move to the start of the screen) and frequent hangs.

I linked the svn command with an executable file containing svn.exe $* . The TortoiseSVN binary was on the path in /mnt/c/Program Files/TortoiseSVN/bin/svn.exe

Actual results

Frequent garbled output, and a hanging shell, hanging in the svn command (as the updated workspace remains locked, this happens during svn.exe execution.

Expected results

No hang or garbled output.

Additional files

updateProjects.sh.txt

Maximus5 commented 6 years ago

Unclear and ambiguous

gjhut commented 6 years ago

I run the standard Bash::bash task, which executes set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pm:/mnt. It runs the Ubuntu 18.04 bash shell.

Typical output is: image

My guess is that the svn.exe process / shell prompt hangs, other conemu tab's and dialogs are still functional. What isn't in this screenshot is the other thing I see since the Windows 1809 update, which is that the cursor sometimes resets to the top left position when generating output for this job. This can happen multiple times, there is no predictable time when it hangs or when it resets the cursor to the top left, but it happens often enough to be annoying (and testable).

My guess that it is caused by something in conemu is because the script executes correctly in the standard windows Ubuntu 18.04 shell.

When I redirect the script output to a file, it also doesn't hang..

I hope this helps

Maximus5 commented 6 years ago

You should try to compare with wsltty.

gjhut commented 6 years ago

I tried to do the same multiple times with wsltty, but encountered no issues when running the script with this terminal emulator.

What I did notice was that after a process hangs, the following process tree is running under wslbridge.exe:

image

You can see the svn.exe process still executing, but halted. After killing conemu64 (by closing it with the close icon on the window top right) the following proces kept running, and held a full core:

image

I hope this helps..

littleq0903 commented 5 years ago

same here with git

Maximus5 commented 5 years ago

@littleq0903 Please be more detailed.

beletsky commented 5 years ago

It seems to me I have a similar problem. I'm using Windows 10, ConEmu64, MSYS2, and Git for Windows installed into MSYS2 MinGW64 environment. All of them updated to the last available versions.

Then, I try to use any git command requiring entering username/password, "git pull origin master", for example. The results differ when I run the command from bash/MSYS2 and cmd (both cases are under ConEmu64, of course).

Under cmd: 1) git asks for the username, but don't show any characters I types, 2) then asks for the password, again not showing any character, 3) and complete its work successfully. By the way, I see exactly the same using git outside the ConEmu64 environment.

Under bash/MSYS2: 1) git asks for username, SHOWING what I'm typing as username at this time, 2) after pressing Enter the caret is moved to the start of the same line, 3) and then the console tab hangs. No key combination like Ctrl-C helps, I have to hard close the tab to get rid of it.

I also try to use the same software combination under Windows 7, In all cases (bash/MSYS2 and cmd under ConEmu64, and cmd without ConEmu64) git works consistently and successfully, and characters I've typed were shown.

That is, it's obvious the ConEmu64 problem under Windows 10.

Please make me know if I can provide you any additional information about this case.

Belorus commented 5 years ago

After update from Win 10 1803 to 1809 build conemu became very slow with FAR Manager.

Running any .exe from FAR now includes 2-3 sec delay. After making window smaller delay became smaller as well.

loglux commented 5 years ago

I must confirm that I have the same problem on Windows 10 1809. ConEmu is very very slow, so I forced to quit using it now.

frolyo commented 5 years ago

I had same issues with Far Side manager in ConEmu. It looks like far can't work with such large console output (32766 lines by default). Try to decrease output buffer size, ie down to 2000 lines. image Worked for me.

https://conemu.github.io/en/SettingsSizePos.html

beletsky commented 5 years ago

I want to mention that my problem described above has nothing to do with FAR Manager. And it's still here, nothing changed with all latest Windows 10 and ConEmu updates.

virgo47 commented 1 year ago

I have seemingly the same problem, Windows 11 here and git-bash. About info says:

ConEmu 200615 [64] Startup Info OsVer: 10.0.22621.x64, Product: workstation, SP: 0.0, Suite: 0x100

For a few months, any mvn build gets stuck (visually), but it seems it actually finishes (target stuff is created for modules after the output gets stuck). I'm using plain git-bash console instead to avoid the problem.

gabriel-stackhouse commented 1 year ago

@virgo47 This seems to match the bug described here: https://github.com/Maximus5/ConEmu/issues/1510