This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with gitk after cygwin update


On Sep 19 23:04, Michael Lutz wrote:
> Hello,
> 
> I just updated my Cygwin installation with the newest packages, especially
> cygwin base from 1.7.5 to 1.7.7 and git from 1.7.1 to 1.7.2.3.
> 
> I'm now having problems when I launch gitk in the background from a xterm,
> i.e. "gitk &". First of all, if I press any key after I switch back to the
> xterm, it just closes. On the prompt "logout" is visible for just a moment
> before it closes.
> 
> Secondly, I got the following error log when clicking around in gitk to
> view some commits. I never had such problems before I updated.
> 
> Michael Lutz
> 
> --- snip 1 ----
> $ cygcheck -c cygwin git gitk
> Cygwin Package Information
> Package              Version        Status
> cygwin               1.7.7-1        OK
> git                  1.7.2.3-1      OK
> gitk                 1.7.2.3-1      OK
> 
> Windows 7 Pro x64 with all updates.
> 
> --- snip 2 ----
> 
>       0 [main] git 6884 C:\cygwin\bin\git.exe: *** fatal error - couldn't
> initialize fd 0 for /dev/tty1
> Stack trace:
> Frame     Function  Args
> 002838C8  6102749B  (002838C8, 00000000, 00000000, 00000000)
> 00283BB8  6102749B  (61177B80, 00008000, 00000000, 61179977)
> 00284BE8  61004AFB  (611A1670, 00000000, 6123AAC4, 00010000)
> End of stack trace
>       0 [main] git 6884 C:\cygwin\bin\git.exe: *** fatal error - couldn't
> initialize fd 0 for /dev/tty1

I can't reproduce the stack dumps, but I can reproduce the premature
exit of the parent shell.  This is a problem I'm still mulling over:
http://cygwin.com/ml/cygwin/2010-09/msg00237.html
Your scenario is equivalent since gitk uses the tk shell wish, which
starts its child processes like a native Windows application using the
CreateProcess call, rather than Cygwin's fork/exec.  This in turn leads
to a collision in the terminal foreground process group handling
between the child process started by wish, and the parent bash.
I have a simple solution for this problem, which is to revert the code
in Cygwin to the 1.7.5 state.  However, this isn't a satisfying solution,
because this results in another problem:

  Microsoft Windows [Version 6.1.7600]
  Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

  C:\cygwin\bin>set CYGWIN=tty

  C:\cygwin\bin>bash --login

  corinna@vmbert7 ~
  $ cmd
  Microsoft Windows [Version 6.1.7600]
  Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

  C:\cygwin\home\corinna>bash --login    <== HANGS taking 100% CPU!!!

I'd rather find a fix for both problems...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]