"emacs -nw" hangs in a terminal
Ken Brown
kbrown@cornell.edu
Thu May 24 12:19:00 GMT 2012
On 5/23/2012 12:02 PM, Corinna Vinschen wrote:
> On May 23 11:56, Ken Brown wrote:
>> On 5/23/2012 10:15 AM, Corinna Vinschen wrote:
>>> On May 23 08:00, Ken Brown wrote:
>>> 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.
>>
>> After the longjmp, emacs has finished processing the C-g and goes
>> back into its idle loop, in which it repeatedly calls select.
>>
>> gdb doesn't normally show the threads created by select. If it did,
>> it would always create voluminous output. Can you infer anything
>> from the fact that it shows this one?
>>
>>> 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.
>>
>> Yes, that's correct. (I'm using the 20120516 snapshot.)
>>
>>>> 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?
>>
>> Based on the emacs code, I think that's right. But maybe I need to
>> download the source for the snapshot I'm using (or build cygwin1.dll
>> myself) so that I can step through the first call to select after
>> the longjmp and see exactly where the crash is happening.
>
> That would be most helpful. I don't grok this crash. It's one of
> the "this should never possibly happen" kind...
I'm now using an unoptimized build of the 20120523 snapshot. The gdb
session is below. I first started emacs and started the shell process;
this guarantees that when emacs calls select, one of the descriptors is
a pty master. Then I attached gdb and put a breakpoint at the emacs
function unwind_to_catch, which is triggered when I press C-g. It took
two presses of C-g to get the crash. I think the rest is self-explanatory.
(gdb) b unwind_to_catch
Breakpoint 3 at 0x52aca2: file eval.c, line 1234.
(gdb) c
Continuing.
[Switching to Thread 860.0x2390]
Breakpoint 3, unwind_to_catch (catch=0x28a8d0, value=12929854) at
eval.c:1234
1234 catch->val = value;
(gdb) b thread_pipe
Breakpoint 4 at 0x610d871a: file
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc,
line 618.
(gdb) n
1237 set_poll_suppress_count (catch->poll_suppress_count);
[stepping through unwind_to_catch...]
1272 _longjmp (catch->jmp, 1);
(gdb)
[Switching to Thread 860.0x1d8c]
Breakpoint 4, thread_pipe (arg=0x80104d00)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:618
618 select_pipe_info *pi = (select_pipe_info *) arg;
(gdb) n
619 DWORD sleep_time = 0;
(gdb)
620 bool looping = true;
(gdb)
622 while (looping)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
627 if (peek_pipe (s, true))
(gdb)
629 if (pi->stop_thread)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
636 if (!looping)
(gdb)
638 Sleep (sleep_time >> 3);
(gdb)
639 if (sleep_time < 80)
(gdb)
640 ++sleep_time;
(gdb)
641 if (pi->stop_thread)
(gdb)
622 while (looping)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
627 if (peek_pipe (s, true))
(gdb)
629 if (pi->stop_thread)
(gdb)
631 select_printf ("stopping");
(gdb)
632 looping = false;
(gdb)
633 break;
(gdb)
636 if (!looping)
(gdb)
637 break;
(gdb)
644 return 0;
(gdb)
645 }
(gdb)
cygthread::callfunc (this=0x6119e080, issimplestub=false)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/cygthread.cc:53
53 }
(gdb) c
Continuing.
Breakpoint 4, thread_pipe (arg=0x80104cf0)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:618
618 select_pipe_info *pi = (select_pipe_info *) arg;
(gdb) disable 4
(gdb) c
Continuing.
[Switching to Thread 860.0x2390]
Breakpoint 3, unwind_to_catch (catch=0x28a8d0, value=12996910) at
eval.c:1234
1234 catch->val = value;
[stepping through unwind_to_catch...]
1272 _longjmp (catch->jmp, 1);
(gdb)
[New Thread 860.0x2280] <<<<<<<<<<<<<<<<<<<<<<<<<<<
[Switching to Thread 860.0x2280]
Breakpoint 4, thread_pipe (arg=0x80104d00)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:618
618 select_pipe_info *pi = (select_pipe_info *) arg;
(gdb) n
619 DWORD sleep_time = 0;
(gdb)
620 bool looping = true;
(gdb)
622 while (looping)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
627 if (peek_pipe (s, true))
(gdb)
629 if (pi->stop_thread)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
636 if (!looping)
(gdb)
638 Sleep (sleep_time >> 3);
(gdb)
639 if (sleep_time < 80)
(gdb)
640 ++sleep_time;
(gdb)
641 if (pi->stop_thread)
(gdb)
622 while (looping)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
627 if (peek_pipe (s, true))
(gdb)
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 860.0x1d8c]
0x610d87df in thread_pipe (arg=0x80104cf0)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:638
638 Sleep (sleep_time >> 3);
(gdb) n
Program received signal SIGILL, Illegal instruction.
0x610d87df in thread_pipe (arg=0x80104cf0)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:638
638 Sleep (sleep_time >> 3);
(gdb) n
Program received signal SIGILL, Illegal instruction.
0x610d87df in thread_pipe (arg=0x80104cf0)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:638
638 Sleep (sleep_time >> 3);
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 860.0x2390]
0x76f3f8b1 in ntdll!RtlUpdateClonedSRWLock () from
/c/windows/SysWOW64/ntdll.dll
(gdb) thread apply all bt full
[compressed output attached]
The stackdump this time contains only one line:
Exception: STATUS_PRIVILEGED_INSTRUCTION at eip=610D87DF
But the following was printed on the terminal:
eax=9FA8007D ebx=079ACE64 ecx=766231E7 edx=00000000 esi=00000000
edi=00000000
ebp=079AACA8 esp=079AAC80
program=C:\cygwin\home\kbrown\src\emacs\test-nox\src\emacs.exe, pid
9636, thread pipesel
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
079AACA8 610D873E (80104830, 00000000, 00000000, 00000000)
079AACE8 61003902 (611B048C, 00000000, 00000000, 00000000)
079AFF88 61003AC4 (6119E470, 079AFFD4, 76F59EF2, 6119E470)
079AFF94 74F6339A (6119E470, 5A1FC24C, 00000000, 00000000)
079AFFD4 76F59EF2 (61083BE2, 6119E470, 00000000, 00000000)
Segmentation fault
$ addr2line -e /bin/cygwin1.dll 610D87DF
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:638
$ addr2line -e /bin/cygwin1.dll 61003902
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/cygthread.cc:51
$ addr2line -e /bin/cygwin1.dll 61003AC4
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/cygthread.cc:101
I still wonder why gdb shows the creation of that one pipesel thread
that I marked.
Let me know if there's some other place I should be setting a breakpoint
in order to track this down.
Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bt.out.bz2
Type: application/octet-stream
Size: 4615 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20120524/971ff255/attachment.obj>
-------------- next part --------------
--
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
More information about the Cygwin
mailing list