Setup.exe causes mintty to freeze

[GoogleCodeExporter]

What steps will reproduce the problem?
   1. create shortcut in / with target "C:\cygwin\bin\mintty.exe /bin/bash.exe --login -i", and start in "c:\cygwin\bin" and pin this shortcut to the windows 7 taskbar.
   2. start several instances of mintty using the pinned shortcut (shift click)
   3. run cygwin.com/setup.exe and install something

What is the expected output? What do you see instead?

   I would expect no significant effect from running cygwin's setup.exe

   Instead, I can not interact with any of my previously open mintty windows -- I can not even close the windows by clicking on their close icon (nor by using the "close" option from the task bar). I must use task manager to get rid of the frozen windows.

What versions of mintty, Cygwin/MSYS, and Windows are you using?

   $ mintty --version
   mintty 0.9.1
   $ uname -movrs
   CYGWIN_NT-6.1-WOW64 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin

Please provide any additional information below.

   If this only happened during cygwin's setup, I could live with it.  But it also happens sometimes, randomly, for some unknown reason.

   I have seen this behavior both when I am running mintty as administrator and when I am a normal user.

Original issue reported on code.google.com by rauldmil...@gmail.com on 7 Oct 2010 at 6:19

[GoogleCodeExporter]

Is that with mintty installed through setup.exe, from the .zip, or from source? 
If the latter, which gcc version and build options?

Original comment by andy.koppe on 7 Oct 2010 at 9:45

[GoogleCodeExporter]

A couple more questions. How do you invoke mintty? Are you running mintty and 
setup.exe as administrator or limited user? At what stage exactly during 
setup.exe does the problem occur?

Original comment by andy.koppe on 8 Oct 2010 at 4:26

[GoogleCodeExporter]

This was with mintty installed by cygwin's setup.exe.

I am invoking mintty by clicking on the task bar icon (and by shift clicking on 
that task bar icon, for instances after the first instance).

I have had this experience both with mintty running as a normal user or (by 
changing the properties of the shortcut, unpinning and repinning to the task 
bar) with mintty running as administrator.

mintty freezes at the beginning of the package installation phase of setup.exe.

Original comment by rauldmil...@gmail.com on 8 Oct 2010 at 3:35

[GoogleCodeExporter]

I'm afraid I haven't been able to reproduce this, and I'm at a loss as to by 
what mechanism that problem could occur. Setup.exe and mintty of course are 
independent processes; in fact, setup.exe isn't even linked against the Cygwin 
DLL.

Have you got anything from the Big List of Dodgy Apps at 
http://cygwin.com/faq/faq.using.html#faq.using.bloda on your system that could 
be interfering here? Has this happened with previous mintty versions?

(ps: Sorry for the late reply. For some reason your post hadn't shown up in the 
list of updates.)

Original comment by andy.koppe on 13 Oct 2010 at 7:09

• Changed state: Undecided

[GoogleCodeExporter]

I am running anti-virus, yes (McAfee) -- no choice about that, it's a company 
laptop.

I had never used mintty before I got this new machine.

Is there some way I could turn on verbose debugging, or something, to collect 
information about what goes wrong?  (I was going to try mintty -log, just in 
case that provided something other than a log of stdout and stderr from the 
contained processes, but I could not even get that to work.  I got permission 
denied if the proposed log file existed and file not found if it did not exist. 
 This was with a session whose parent had had administrative privileges which 
perhaps su was not able to fully shed.)

Original comment by rauldmil...@gmail.com on 13 Oct 2010 at 7:18

[GoogleCodeExporter]

Since you've got administrator rights, you ought to be able to disable McAfee 
at least temporarily. There's little point trying anything else without 
excluding that possibility first. (Computius says: "Given the choice between 
McAfee and a virus, take the virus.")

The '--log <file>' feature does simply copy output coming from the child 
processes into a file. Note that the option starts with two dashes. If you only 
give one, it effectively becomes '-l og', i.e. it would try to create a file 
called 'og' in the current directory. A somewhat unfortunate feature of GNU 
options syntax.

Things you could try:
- Put the mintty shortcut outside the Cygwin directory.
- Run older versions.
- Build from source.
- Try both gcc-3 and gcc-4. The release is built with gcc-3. The compiler can 
be specified on the make line, e.g. 'make cc=gcc-3'.
- Change the optimisation settings in the makefile, e.g. remove -Os, or use -O 
instead.
- Enable debugging, with 'make debug=1'. You'll need the dmalloc package 
installed.
- Look for stackdumps from the failed minttys.
- Run through gdb.
...

Original comment by andy.koppe on 14 Oct 2010 at 4:52

[GoogleCodeExporter]

Actually I have been able to reproduce this now, by following your steps more 
carefully. Or perhaps it depends on what package is being installed in 
setup.exe. The netcat package does the trick anyway. No McAfee or other nasties 
involved.

Here's a workaround: set your shortcut target to 'C:\cygwin\bin\mintty.exe -', 
i.e. with a dash as the only argument. This tells mintty to invoke your default 
shell (usually bash) as a login shell. Or just use the mintty shortcut in the 
Cygwin folder of the start menu, which does just that anyway. I don't yet know 
why it makes a difference.

Original comment by andy.koppe on 14 Oct 2010 at 5:38

• Changed title: Setup.exe causes mintty to freeze
• Changed state: Accepted
• Added labels: Priority-High

[GoogleCodeExporter]

Going back through mintty history showed that it was r923 where the issue 
appeared. r1057 makes it go away. Trouble is, the "fix" shouldn't make any 
difference, since all it does is swap a couple of function calls that ought to 
be unrelated, so it's only hiding whatever the underlying issue is.

This is something of a recurring theme, with similar examples at r513, r894, 
and r928; only this time, gcc 4.3's size optimisation is in the clear as the 
issue appears to be independent of compiler version and optimisation setting. I 
didn't manage to turn up anything tangible in stackdumps or with dmalloc or gdb.

The issue also showed up with Cygwin 1.7.5, but interestingly, it no longer 
appeared with the latest 1.7.8 snapshots. I managed to track that rather 
welcome development down to this change on 2010-09-13:

* path.cc (symlink_info::check_reparse_point): Add comment.
    (symlink_info::check): Fetch FileNetworkOpenInformation rather than
    FileBasicInformation throughout, except on NFS.  Explain why.  Store
    FILE_NETWORK_OPEN_INFORMATION in conv_hdl.  Remove
    FILE_ATTRIBUTE_DIRECTORY attribute in conv_hdl for reparse point
    symlinks.
    * path.h (class path_conv_handle): Add FILE_NETWORK_OPEN_INFORMATION
    member _fnoi.

Unfortunately I've got no idea why that makes a difference, so that's one for 
the Cygwin developers.

Original comment by andy.koppe on 16 Oct 2010 at 2:48

• Changed state: Fixed
• Added labels: Difficulty-Medium, Milestone-0.9.2

[GoogleCodeExporter]

This had somehow reappeared again, and this time the latest Cygwin snapshot 
didn't make  a difference. Replacing the use of a variable length array for the 
window title in main() does appear to fix this, however. r1068.

Original comment by andy.koppe on 26 Oct 2010 at 9:40

[GoogleCodeExporter]

Original comment by andy.koppe on 27 Oct 2010 at 5:47

• Changed state: Verified