X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
From:	Kiyo Kelvin Lee <kiyolee AT hotmail DOT com>
Subject:	cygwin 1-5.19-4 crashes at tty_list::terminate() when using gvim in diff mode
Date:	Fri, 30 Jun 2006 14:15:53 +1000
Lines:	70
Message-ID:	<e828i0$ju6$1@sea.gmane.org>
Mime-Version:	1.0
User-Agent:	Thunderbird 1.5.0.4 (Windows/20060516)
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

I am using cygwin-1.5.19-4 (with all related packages being latest) on 
Windows XP SP2 and have built gvim 7.0 myself (official vim-6.4 from 
cygwin has the same problem though).

After I run gvim in diff mode like:
	gvim -d /tmp/a /tmp/b
When I quit gvim, the gvim process never terminates properly and becomes 
consuming all cpu cycles (90+%) forever. So I have to explicitly kill 
the process from task manager.

I took some time to debug into the gvim process and found that actually 
a crash (SIGSEGV as reported by gdb) would happen inside the function 
tty_list::terminate() (in tty.cc) all the time upon quiting from gvim. 
And somehow the crash would become consuming all cpu cycles.

I added my own logging code to the function like this:
.........
       termios_printf ("tty %d master about to finish", ttynum);
       _D(debug_log("cyg.log", __DBGARGS__, "<a> t->to_slave=%p", 
t->to_slave));
       ForceCloseHandle1 (t->to_slave, to_pty);
       _D(debug_log("cyg.log", __DBGARGS__, "<b> t->from_slave=%p", 
t->from_slave));
       ForceCloseHandle1 (t->from_slave, from_pty);
       _D(debug_log("cyg.log", __DBGARGS__, "<c> tty_master->inuse=%p", 
tty_master->inuse));
       CloseHandle (tty_master->inuse);
       _D(debug_log("cyg.log", __DBGARGS__, "<d>"));
       t->init ();
.........
and the log shows only:
.........
[ 2006-06-30 13:16:19.525 ] (pid=gvim.exe:416,tid=0x5d8) < 
tty_list::terminate @ ../../.././winsup/cygwin/tty.cc:144 >
entering (myself=0x611000d0)

[ 2006-06-30 13:16:19.525 ] (pid=gvim.exe:416,tid=0x5d8) < 
tty_list::terminate @ ../../.././winsup/cygwin/tty.cc:146 >
ttynum=1

[ 2006-06-30 13:16:19.525 ] (pid=gvim.exe:416,tid=0x5d8) < 
tty_list::terminate @ ../../.././winsup/cygwin/tty.cc:174 >
<a> t->to_slave=0x650

[ 2006-06-30 13:16:19.525 ] (pid=gvim.exe:416,tid=0x5d8) < 
tty_list::terminate @ ../../.././winsup/cygwin/tty.cc:177 >
<b> t->from_slave=0x644
.........
and that's all. It never reaches point <c>.

So it means that the crash happens upon the second call to 
ForceCloseHandle1() (macro just mapped to CloseHandle() normally and 
indeed so in my own build of cygwin1.dll), i.e. the crash happens inside 
the Windows API. The handle value looks like normal. Could that be just 
a double Close?

I don't know enough about cygwin internal to dive in any further.
Hope anyone of the cygwin developers can help to fix this annoying 
problem. I use gvim diff mode fairly so often. And hope my info helps.

BTW, notice that the problem does not happen if gvim is not detached 
from the terminal, like using this command:
	gvim -f -d /tmp/a /tmp/b

Or could this be a problem for vim instead? But, however, I think it 
would be nice if cygwin can be protected from this kind of cpu cycles 
sucking problem.

Regards,
Kiyo


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

- Raw text -