X-Recipient: archive-cygwin AT delorie DOT com 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=qhOOjrCIH7+thAGujPz8kYO9Xvs3Q39NGN6UEY+VzFh N0eByEoQY4nAgYyYQ4NMhsqylEkI9MfYFbUiRFWaloWIihjeeYKb81QauIWikp14 +g7kC9xbkSk0mfRvfeaUvezuOfeaODeCG20mKIy8RmlTi+0EgQIMtka6TBW+2xF8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; 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; s=default; bh=VqwDcir2EvI4CHXfqLQwUCbuiNE=; b=Oa6xo9HF/SE2eFRbW 1+HOFUxkJL+eQgp6KypAndk9t1VdGqEfRkeSQUDON5x7crb5eJhMEVAaENIMQBLF IHipKGkFez1bExy6XS9AY3k8hA1pEwhsK9p+MnstoX8IWNuISXntZRJK/cdbP36v l3S2TvD5M8pjAvAC0J8Pwj2fUk= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RDNS_NONE,SPF_NEUTRAL autolearn=no version=3.3.1 Message-ID: <5205B364.8090007@cs.utoronto.ca> Date: Fri, 09 Aug 2013 23:28:36 -0400 From: Ryan Johnson 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 AT cygwin DOT com Subject: Re: 64-bit emacs crashes a lot References: <51F3151D DOT 7040000 AT cs DOT utoronto DOT ca> <51F33565 DOT 1090406 AT cornell DOT edu> <51F33F52 DOT 4060405 AT cs DOT utoronto DOT ca> <51FB1D9E DOT 5090102 AT cs DOT utoronto DOT ca> <20130802080211 DOT GA18054 AT calimero DOT vinschen DOT de> <51FB9228 DOT 2020309 AT cornell DOT edu> <51FBA100 DOT 90005 AT cs DOT utoronto DOT ca> <51FD5462 DOT 5020400 AT cs DOT utoronto DOT ca> <51FFBDFF DOT 7040501 AT cornell DOT edu> <51FFC4F2 DOT 8080909 AT cs DOT utoronto DOT ca> <5203D89E DOT 6030801 AT cornell DOT edu> <5203DCCA DOT 1010105 AT cs DOT utoronto DOT ca> In-Reply-To: <5203DCCA.1010105@cs.utoronto.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 08/08/2013 2:00 PM, Ryan Johnson wrote: > On 08/08/2013 1:42 PM, Ken Brown wrote: >> On 8/5/2013 11:29 AM, Ryan Johnson wrote: >>> On 05/08/2013 11:00 AM, Ken Brown wrote: >>>> 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. Got one! Looks like a stack overflow somewhere in the garbage collector: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 5316.0x1af4] 0x00000001004df44a in mark_object (arg=) at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903 5903 if (CONS_MARKED_P (ptr)) (gdb) bt #0 0x00000001004df44a in mark_object (arg=) at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903 #1 0x00000001004df66e in mark_object (arg=) at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914 #2 0x00000001004df593 in mark_object (arg=) at /usr/src/debug/emacs-24.3-4/src/alloc.c:5809 #3 0x00000001004df66e in mark_object (arg=) at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914 #4 0x00000001004df66e in mark_object (arg=) at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914 #5 0x00000001004df585 in mark_object (arg=) at /usr/src/debug/emacs-24.3-4/src/alloc.c:5808 #6 0x00000001004dfa4e in mark_vectorlike ( ptr=0x100f66f28 ) at /usr/src/debug/emacs-24.3-4/src/alloc.c:5501 ... snip ... #2606 0x00000001004dfaf4 in mark_buffer (buffer=) at /usr/src/debug/emacs-24.3-4/src/alloc.c:5552 #2607 0x00000001004dff2c in Fgarbage_collect () at /usr/src/debug/emacs-24.3-4/src/alloc.c:5181 #2608 0x0000000000000000 in ?? () I have the full backtrace saved to file, let me know if that would be useful (there wasn't anything obvious that I could see, just more of the same). Meanwhile, I verified that none of the addresses printed is repeated, so it doesn't seem to be due to an obvious cycle in the object graph. The crash happened when I foregrounded a stopped emacs. I tried playing around with various breakpoints while repeatedly sending ^Z, but no luck repeating the "feat" yet. Ideas? Ryan -- 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