Setup.exe causes mintty to freeze about mintty HOT 10 CLOSED

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

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?

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.

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.)

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.)

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.
...

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.

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.

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.