X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By:	sourceware.org
MIME-Version:	1.0
In-Reply-To:	<20110701094339.GO9552@calimero.vinschen.de>
References:	<20110630072012 DOT GB9552 AT calimero DOT vinschen DOT de> <2BF01EB27B56CC478AD6E5A0A28931F202CFAFF7 AT A1DAL1SWPES19MB DOT ams DOT acs-inc DOT net> <20110630142353 DOT GH9552 AT calimero DOT vinschen DOT de> <20110630150502 DOT GJ9552 AT calimero DOT vinschen DOT de> <20110701083603 DOT GM9552 AT calimero DOT vinschen DOT de> <20110701094339 DOT GO9552 AT calimero DOT vinschen DOT de>
Date:	Fri, 1 Jul 2011 11:21:08 +0100
Message-ID:	<BANLkTi=SnBSF0NPfJfQS_aMVXX_fgp9tvg@mail.gmail.com>
Subject:	Re: Vim segv'ing
From:	Andy Koppe <andy DOT koppe AT gmail DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
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
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id p61ALVWr029880

On 1 July 2011 10:43, Corinna Vinschen wrote:
> On Jul  1 10:36, Corinna Vinschen wrote:
>> FYI, I tracked it down to the place where the stack overwrite occurs.
>> This is most puzzeling.  When typing :wq!, the following chain of functions
>> is called:
>>
>>   nv_colon
>>    do_cmdline
>>     ex_exit
>>      do_write
>>       open                           <- Here it calls into the Cygwin DLL
>>        fhandler_base::open_with_arch
>>         fhandler_base::open_fs
>>          fhandler_base::open
>>           NtCreateFile               <--Here it calls into NTDLL.DLL
>>
>> The open call tries to open the backup file "/etc/hosts~", not the
>> symlink itself.
>>
>> In the optimized version of vim, the local variable "cap" in the
>> function nv_colon is kept in register $esi.  When do_cmdline is called,
>> $esi is pushed onto the stack.  Then everything goes its normal ways,
>> until NtCreateFile is called.
>>
>> And here's the puzzler: This call to NtCreateFile overwrites the 4 byte
>> stack slot in which the "cap" pointer is saved with the value 0x10c!

What else has access to that? The signal thread?


>> [...]
>> Oh, and here's a last-minute surprise:  It does not happen if you run
>> gvim, rather than vim.  Maybe I should just give up to provide packages.
>
> And it also does not happen if I build Cygwin with gcc 4.5.1 rather than
> with gcc 4.3.4.  Is it possible that a compiler bug is playing a role
> here?  I can't quite believe it, the effect is too specific.

This sounds similar to some unexplained mintty crashes that Chris
Sutcliffe and I have seen with gcc 4.3.4, triggered by setup.exe
running postinstall scripts or vim accessing /etc/fstab. Unfortunately
we never managed to pin down the actual cause, inspite of a fair bit
of debugging and staring at the compiler's assembly output. The
crashes went away with changes that should have made no difference.

See here:
http://code.google.com/p/mintty/source/detail?r=928
http://code.google.com/p/mintty/source/detail?r=894
http://groups.google.com/group/mintty-discuss/browse_thread/thread/7f1afcb74c61fe99

Andy

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

- Raw text -