setup.exe makes mintty crash

Andy Koppe
Tue Oct 26 21:51:00 GMT 2010

On 16 October 2010 16:27, Andy Koppe wrote:
> Hi,
> I've been looking at a rather weird bug that was reported as mintty
> issue 225 [1]. I've reproduced it on a 64-bit Win7 and a 32-bit XP,
> both with Cygwin 1.7.7:
> - Create a shortcut with target 'C:\cygwin\bin\mintty.exe
> /bin/bash.exe --login', and 'C:\cygwin\bin' in the StartIn field.
> (Adjust Cygwin root as appropriate. Its location doesn't appear to
> matter.)
> - Invoke mintty through that shortcut.
> - Run setup, pointing it at the same Cygwin install.
> - Just keep clicking Next. No change to the package selection appears
> to be needed.
> - At some point during the download/install stage, probably when
> invoking scripts, mintty freezes or crashes, leaving the bash process
> behind.
> Fortunately, mintty's default shortcut is not affected, but still,
> this is quite a serious problem, and a very puzzling one too. I've
> tracked it back through svn history and found that the issue first
> appeared with r923 (for mintty 0.8). I've made it go away in r1057
> [2]. Trouble is, the r1057 change shouldn't make a difference, since
> all it does is swap calls to getenv and getpwuid that should be
> unrelated. I haven't managed to glean anything from stackdumps,
> dmalloc, or gdb.
> However, while the issue occurred with Cygwin 1.7.5 too, it's gone
> with recent 1.7.8 snapshots (even without r1057). I managed to track
> that welcome development down to this change:
> 2010-09-13  Corinna Vinschen
>        * (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.
> Can anyone see why that might have made the problem go away, or is
> this just another case of the underlying problem being obscured? Does
> it ring any other bells?
> Andy
> [1]
> [2]

This issue had somehow reappeared again, and this time the latest
Cygwin snapshot didn't make a difference. I can only guess that a
Windows update had changed something.

My latest "fix" replaces a C99 variable-length array in main() with a
heap-allocated one. Case closed as far as the Cygwin DLL is concerned.


More information about the Cygwin-developers mailing list