Mail Archives: cygwin/2012/10/24/09:09:17
X-Recipient: | archive-cygwin AT delorie DOT com
|
X-SWARE-Spam-Status: | No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,SPF_NEUTRAL
|
X-Spam-Check-By: | sourceware.org
|
Message-ID: | <5087E872.4070902@cs.utoronto.ca>
|
Date: | Wed, 24 Oct 2012 09:09:06 -0400
|
From: | Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT ca>
|
User-Agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
|
MIME-Version: | 1.0
|
To: | cygwin AT cygwin DOT com
|
Subject: | Re: Emacs crashing on C-x C-g
|
References: | <5069E625 DOT 9050803 AT cs DOT utoronto DOT ca> <5069EA0D DOT 7080303 AT cornell DOT edu> <5069F83D DOT 5060502 AT cs DOT utoronto DOT ca>
|
In-Reply-To: | <5069F83D.5060502@cs.utoronto.ca>
|
X-IsSubscribed: | yes
|
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm
|
List-Id: | <cygwin.cygwin.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
|
On 01/10/2012 4:08 PM, Ryan Johnson wrote:
> On 01/10/2012 3:07 PM, Ken Brown wrote:
>> On 10/1/2012 2:51 PM, Ryan Johnson wrote:
>>> I'm hitting a strange behavior with emacs lately, where hitting
>>> C-x C-g [1] sometimes causes it to quit instantly: no request to
>>> save files, no seg fault, no error message, just gone (have to
>>> reset the terminal to clear out emacs' ncurses settings). It
>>> invariably happens after I've been away from the terminal for a
>>> while (days) and then come back use it again.
>>>
>>> has anyone else had this happen to them?
>> I haven't seen it, and I do leave emacs running for days or weeks.
>> But I almost always run emacs under X, not in a terminal. Also, I
>> generally use the latest Cygwin snapshot. Have you tried that?
>> Maybe you're being bitten by the /etc problem that Corinna fixed in
>> late July (http://cygwin.com/ml/cygwin/2012-07/msg00666.html).
> OK, I'll give the snapshot a try when I get a chance.
Rats. I thought it was working, but the problem just it again. This time
the emacs session had just been created by a mercurial check-in (to edit
the changelog message) and crashed when I hit C-g to cancel an ESC I no
longer needed.
Packages:
cygwin snapshot 1.7.17s(0.262/5/3) 20120917
bash-4.1.10-4
emacs-24.2-1
emacs-x11-24.2-1
mercurial-2.3.1-1
mintty-1.1.2-1
This time the crash is reproducible, and the test case below paints an
"interesting" story:
mkdir foo
cd foo
hg init
touch foo
hg add foo
EDITOR='emacs -q -nw' hg ci
ESC C-g
<<<crash>>>
reset
<<<"reset is control-G (^G).">>>
EDITOR='emacs -q -nw' hg ci
C-g
<<<"interrupted!">>>
python
C-g
<<<"KeyboardInterrupt">>>
quit # python still running
reset -i ^c
<<<no message>>>
hg record foo
C-g
<<<"Quit (core dumped)">>>
hg record foo
C-c
<<<"interrupted">>>
python
C-g
<<<"Quit (core dumped)">>>
python
C-c
<<<"KeyboardInterrupt">>>
quit # python still running
Apparently, emacs sets the terminal's interrupt character to ^G, causing
^G to interrupt the python script controlling emacs, causing the latter
to not set interrupt back to ^C (due to abnormal exit), and causing
serious (and permanent) confusion for bash: after setting the interrupt
char back to ^C, ^C behaves as expected, but ^G crashes the app. In
addition to mercurial/python above, the same core dump occurs with
gnuplot, cat, and bash history search (^R). Hitting ^G during any of
those commands in a fresh mintty has the usual harmless result.
The stackdump for python killed by a zombie ^G contains:
Stack trace:
Frame Function Args
# 767... => kernel32.dll
0028A49C 767F1A2C (00000003, FFFDE000, 00000000, FFFFFFFF)
0028A4B8 767F4220 (00000003, 0028A4F0, 00000000, FFFFFFFF)
# 610... => cygwin1.dll
0028A608 610D17C8 (0028A6D8, 0028A670, 0028A650, 0028A630)
0028A738 610D1FBF (0028A790, FFFFFFFF, 0000000C, 610FD52A)
0028A7D8 610D244F (00000001, 0028A828, 00000000, 00000000)
0028A848 610D66C5 (611876B0, 61187720, FFF46034, 800D0000)
# 64B => libpython2.6.dll
0028A888 64B45128 (611876B0, 61187720, FFF46034, FFFFF000)
0028A8D8 64B45CB6 (0028A8A0, 61106469, 0053002B, 002B002B)
0028A998 64B46CD7 (800ACF40, 0028A9DC, 0028A9D8, 64B428F9)
0028A9F8 64B423A4 (0028AA3C, 0028AA58, 64C442C0, 00000100)
0028AA78 64C01327 (611876B0, 64C78A32, 00000100, FFF46034)
0028AAD8 64C02559 (611876B0, 64C78A32, 0028AC2C, 64C78A32)
0028AB28 64C02786 (611876B0, 64C78A32, 0028AC2C, 6102C349)
0028AB68 64C0424B (611876B0, 64C78A32, 00000000, 0028AC2C)
0028AC48 64C11589 (00000001, 0028AC90, 00000000, 0028CE64)
# 004... => python2.6.exe
0028AC68 00401190 (00000001, 0028AC90, 80010100, 61275B98)
End of stack trace (more stack frames may be present)
Pulling down the .dbg for this snapshot and running the cygwin1.dll
addresses though addr2line gives:
select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*,
unsigned long) at select.cc:368
select at select.cc:190
cygwin_select at select.cc:125
?? at ??:0
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
- Raw text -