DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=C3rwpli1/9ZJOTaol/7lKyJpQtNrOT8nk23qp1kzbNn
	w8GAbBD0AatajBCaVmEuSYCqzV7F16VdVr8MAxNv4y8oOi+JN1HYjS25vzRSN0eE
	TJo88g1RwYug5MzW7wWbze/3emH+SDG0HhzAIeGpc3AhTH1mCm4eS7LZS6+Q4fEo
	=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <51FFBDFF.7040501@cornell.edu>
Date: Mon, 05 Aug 2013 11:00:15 -0400
From: Ken Brown <kbrown@cornell.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: 64-bit emacs crashes a lot
References: <51F3151D.7040000@cs.utoronto.ca> <51F33565.1090406@cornell.edu> <51F33F52.4060405@cs.utoronto.ca> <51FB1D9E.5090102@cs.utoronto.ca> <20130802080211.GA18054@calimero.vinschen.de> <51FB9228.2020309@cornell.edu> <51FBA100.90005@cs.utoronto.ca> <51FD5462.5020400@cs.utoronto.ca>
In-Reply-To: <51FD5462.5020400@cs.utoronto.ca>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 8/3/2013 3:05 PM, Ryan Johnson wrote:
> On 02/08/2013 8:07 AM, Ryan Johnson wrote:
>> On 02/08/2013 7:04 AM, Ken Brown wrote:
>>> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>>>> On Aug  1 22:46, Ryan Johnson wrote:
>>>>> Here's a new one... I started a compilation, but before it actually
>>>>> invoked the command it started pegging the CPU. After ^G^G^G, it
>>>>> crashed with the following:
>>>>>> Auto-save? (y or n) y
>>>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** fatal
>>>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>>>>
>>>> That looks like a memory overwrite.  2268032 is 0x229b80, which looks
>>>> suspiciously like a stack address.  And the overwritten value is on the
>>>> stack, too, well within the cygwin TLS area.  If *this* value gets
>>>> overwritten, the TLS is probbaly totally hosed at this point. There's
>>>> just no way to infer the culprit from this limited info.
>>>
>>> Could this be BLODA?  Ryan, I noticed that you wrote in a different
>>> thread, "I recently migrated to 64-bit cygwin...and so far have not
>>> had to disable Windows Defender; the latter was a recurring source of
>>> trouble for my previous 32-bit cygwin install on Win7/64."
>> This would be a whole new level of nasty from a BLODA... I thought
>> they only interfered with fork()?
>>
>> However, this *is* Windows Defender we're talking about... service
>> disabled and all cygwin processes restarted. I'll let you know in a
>> day or so if the crashes go away.
> Rats. I just had another crash, the "Fatal error 6" variety. Windows
> Defender has not turned itself back on (it's been known to do that), and
> a scan of the BLODA list didn't match anything else on my system.
>
> So I don't think it's BLODA...
>
> Ideas?

Not really, other than the obvious: (a) Find a reproducible way of 
making emacs-nox crash.  (b) Catch the crash in gdb by setting a 
suitable break point.

Ken

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