Date: Wed, 23 May 2012 16:15:38 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: "emacs -nw" hangs in a terminal
Message-ID: <20120523141538.GI9200@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <7rmx513ol1.fsf@ws796-of-spb.ru.yotateam.com> <4FBA12C7.4070305@cornell.edu> <4FBA5FDA.7080801@cornell.edu> <20120521162908.GP7763@calimero.vinschen.de> <4FBA8EA0.4040905@cornell.edu> <20120522112828.GA9200@calimero.vinschen.de> <4FBB7BA6.9000409@cornell.edu> <20120522134119.GB9200@calimero.vinschen.de> <20120522134932.GC9200@calimero.vinschen.de> <4FBCD166.8080101@cornell.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4FBCD166.8080101@cornell.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On May 23 08:00, Ken Brown wrote:
> I've gotten some more information from gdb.  The crash occurs after
> a call to _longjmp, and gdb shows a new thread created right at that
> point.  This doesn't happen when I run emacs under X instead of in
> mintty.  Here's an excerpt from the gdb session, with the strange
> thread marked:
> 
> $ gdb -p 6492
> [...]
> Attaching to process 6048
> [New Thread 6048.0x668]
> [New Thread 6048.0x1a5c]
> [New Thread 6048.0x2630]
> [New Thread 6048.0x1d14]
> Reading symbols from /home/kbrown/src/emacs/test-nox/src/emacs.exe...done.
> [...]
> (gdb) b unwind_to_catch
> Breakpoint 3 at 0x52aca2: file eval.c, line 1234.
> (gdb) c
> Continuing.
> [Switching to Thread 6048.0x668]
> [...]
> Breakpoint 3, unwind_to_catch (catch=0x28a8d0, value=12985830) at
> eval.c:1234
> 1234      catch->val = value;
> (gdb) n
> [...]
> 1272      _longjmp (catch->jmp, 1);
> (gdb)
> [New Thread 6048.0x1e04]   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> Program received signal SIGSEGV, Segmentation fault.

I don't know what this has to do with the longjmp, but the thread
which gets crated right after pressing Ctrl-G is due to a select or
poll call.  The descriptor is a pipe, fifo, or pty.

> 0x76f3f8b1 in ntdll!RtlUpdateClonedSRWLock () from
> /c/windows/SysWOW64/ntdll.dll
> (gdb) thread apply all bt full
> 
> [compressed output attached]
> 
> And here's the stackdump:
> 
> Exception: STATUS_ACCESS_VIOLATION at eip=610CFA77

The problem with stackdumps is that the addresses only make sense
for a single version of the Cygwin DLL.  If that's a self-built
version, what does `addr2line -e /bin/cygwin1.dll 610CFA77' print?
If it's 1.7.15, please install the cygwin-debug package and call
the same addr2line.

I assume the address corresponds to select.cc, line 625, but I'm
quite busy with the pthread_cancel stuff, so I didn't look deeper
into this problem.

> eax=80106D50 ebx=34322D73 ecx=766231E7 edx=00000000 esi=00000001
> edi=00000050
> ebp=048FACC8 esp=048FACA0
> program=C:\cygwin\home\kbrown\src\emacs\test-nox\src\emacs.exe, pid
> 6492, thread pipesel
               ^^^^^^^
Yes, that's exactly the created thread.  Do you happen to know what
kind of descriptor has been given to select at this point?  Is that
a pty master side perhaps?


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