This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: 64-bit emacs crashes a lot
- From: Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>
- To: cygwin at cygwin dot com
- Date: Thu, 15 Aug 2013 16:55:18 -0400
- 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> <5205B364 dot 8090007 at cs dot utoronto dot ca> <52064730 dot 50404 at cornell dot edu> <"52065B3C dot 6060104 at cs dot utoronto <520CCA41.3000107"@cs.utoronto.ca> <520D089A dot 1020806 at cornell dot edu> <83ioz6op5v dot fsf at gnu dot org>
On 15/08/2013 1:10 PM, Eli Zaretskii wrote:
Date: Thu, 15 Aug 2013 12:58:02 -0400
From: Ken Brown <kbrown@cornell.edu>
CC: Eli Zaretskii <eliz@gnu.org>
Eli is the expert on bidi.c (he wrote it). He can probably tell you
whether you've really bumped into an emacs bug here.
There's nothing wrong with bidi.c here, it just aborts because it is
handed an invalid character codepoint. It would have been useful to
see the value of that character.
I guess I would just consider crashing to be overkill for a bad byte on
the input stream... and in any case, if 5-byte UTF-8 is illegal, and
worth dying for, wouldn't it make sense to die right away rather than
processing it so something else can croak down the road? However...
Anyway, I generally agree that this is probably some memory
corruption, as I'm guessing that the text in the window was all ASCII
in this case, so any character codepoint beyond 127 is not to be
expected.
I set a breakpoint there, since I thought it was guaranteed to lead to a
crash if it ever ran, but it turns out that's not true. Invoking M-x
compile triggers the breakpoint twice in a row with the following
(valid!) 5-byte UTF-8:
111110XX 10XXXXXX 10XXXXXX 10XXXXXX 10XXXXXX
11111000 10001111 10111111 10111101 10111111
The value is always the same, and corresponds to the code point
U+3FFF7F, FWIW. The backtrace seems to involve loading a file (maybe the
.elc contains 'compile or 'compilation-mode?), and the breakpoint does
not recur in subsequent compilations, presumably because they don't
re-load the file. Emacs continues normally from there, because the
leading bits are zero and the resulting code point doesn't pass the
0x3FFFFF limit.
At this point I'm pretty confident it's memory corruption of some kind.
Consider the following semi-STC:
1. Invoke: emacs-nox -Q; echo -e "att $(jobs -p)\nc" > /dev/clipboard; fg
2. ^Z
3. (switch to window running gdb and hit [shift]+[insert] to paste from
clipboard)
5. (switch to window running emacs): M-x compile C-a C-k ls [ret]
6. C-x o (to switch to the compilation output window)
7. Hit 'g' to keep repeating the "compilation" until gdb picks up a crash.
For its part, gdb needs the following to do its job effectively:
1. handle {SIGINT,SIGTSTP,SIGCONT} pass nostop noprint
2. b abort
3. b kill
4. b raise
5. b character.c:189 -if p[1] & 0x30 (catches the bad UTF-8 sequence as
it happens)
6. b regex.c:6256 (catches a failure/abort inside re_match_2_internal)
7. b data.c:854 (catches an abort inside do_symval_forwarding)
8. b bidi.c:107 (catches the bidi abort even when the character.c
breakpoint doesn't trigger)
It may take anywhere from five to fifty compilations to trigger the
crash; I repeated the process about 20 times (see below). There are
definitely some patterns, but in general it's all over the map. The only
thing in common is that all crashes have hit after emacs echoes the
command but before any of the command's output arrives. Oddly, the one
time the bidi.c crash returned, the breakpoint in character.c had not
triggered, so the culprit must have been elsewhere. Can anybody else
repro any of this?
I don't have any installed software fro the BLODA list, and antivirus
scans come up clean. I've posted the list of loaded dlls that gdb knew
about below, along with a taste of the crashes that were occurring.
Thoughts?
Ryan
/cygdrive/c/Windows/system32/apphelp.dll
/cygdrive/c/Windows/system32/DNSAPI.dll
/cygdrive/c/Windows/System32/fwpuclnt.dll
/cygdrive/c/Windows/system32/GDI32.dll
/cygdrive/c/Windows/system32/IMM32.DLL
/cygdrive/c/Windows/system32/IPHLPAPI.DLL
/cygdrive/c/Windows/system32/kernel32.dll
/cygdrive/c/Windows/system32/KERNELBASE.dll
/cygdrive/c/Windows/system32/LPK.dll
/cygdrive/c/Windows/system32/MSCTF.dll
/cygdrive/c/Windows/system32/msvcrt.dll
/cygdrive/c/Windows/System32/mswsock.dll
/cygdrive/c/Windows/system32/napinsp.dll
/cygdrive/c/Windows/system32/NLAapi.dll
/cygdrive/c/Windows/system32/NSI.dll
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
/cygdrive/c/Windows/system32/pnrpnsp.dll
/cygdrive/c/Windows/system32/rasadhlp.dll
/cygdrive/c/Windows/system32/RPCRT4.dll
/cygdrive/c/Windows/SYSTEM32/sechost.dll
/cygdrive/c/Windows/system32/user32.dll
/cygdrive/c/Windows/system32/USP10.dll
/cygdrive/c/Windows/system32/WINNSI.DLL
/cygdrive/c/Windows/System32/winrnr.dll
/cygdrive/c/Windows/system32/ws2_32.dll
/cygdrive/c/Windows/System32/wship6.dll
/cygdrive/c/Windows/System32/wshtcpip.dll
/usr/bin/cygdbus-1-3.dll
/usr/bin/cygffi-6.dll
/usr/bin/cyggmp-10.dll
/usr/bin/cyggnutls-28.dll
/usr/bin/cyghogweed-2.dll
/usr/bin/cygiconv-2.dll
/usr/bin/cygintl-8.dll
/usr/bin/cyglzma-5.dll
/usr/bin/cygncursesw-10.dll
/usr/bin/cygnettle-4.dll
/usr/bin/cygp11-kit-0.dll
/usr/bin/cygtasn1-6.dll
/usr/bin/cygwin1.dll
/usr/bin/cygxml2-2.dll
/usr/bin/cygz.dll
Breakpoint 6, re_match_2_internal (bufp=bufp@entry=0x1008bab40
<searchbufs+1472>, string1=0x100000000 <Address 0x100000000 out of bounds>,
string1@entry=0x6fffff00028 "-*- mode: compilation;
default-directory: \"~/projects/shore-compiler/\" -*-\nCompilation
started at Thu Aug 15 16:12:01\n\nls\n#bug-last.i#\t\t schema.py\t\t
sql_schema.h\n#sql_shore.cpp.rej#\t schema_impl.cpp\t"..., size1=0,
size1@entry=379, string2=0x2214bc "\001", string2@entry=0x6fffff00973
"", size2=370, size2@entry=0, pos=<optimized out>, pos@entry=138,
regs=<optimized out>,
regs@entry=0x1008ba560 <search_regs>, stop=<optimized out>,
stop@entry=370) at /usr/src/debug/emacs-24.3-4/src/regex.c:6256
6256 abort ();
(9x)
Breakpoint 7, do_symval_forwarding (valcontents=0x1008536a0
<o_fwd.20653>) at /usr/src/debug/emacs-24.3-4/src/data.c:854
854 default: emacs_abort ();
(4x)
#5 0x00000001004a0363 in emacs_abort () at
/usr/src/debug/emacs-24.3-4/src/sysdep.c:2152
#6 0x00000001004117af in produce_special_glyphs (it=it@entry=0x225380,
what=IT_COMPOSITION, what@entry=IT_CONTINUATION) at
/usr/src/debug/emacs-24.3-4/src/xdisp.c:24365
#7 0x000000010041b637 in init_iterator (it=it@entry=0x225380,
w=w@entry=0x100d37ca0 <bss_sbrk_buffer+4664768>,
charpos=charpos@entry=1, bytepos=bytepos@entry=1, row=0x6002d4000,
(2x)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3120.0x360]
allocate_string_data (s=s@entry=0x60024e9e0, nchars=nchars@entry=57,
nbytes=nbytes@entry=57) at /usr/src/debug/emacs-24.3-4/src/alloc.c:1743
1743 SDATA_NBYTES (old_data) = old_nbytes;
(gdb) bt
#0 allocate_string_data (s=s@entry=0x60024e9e0, nchars=nchars@entry=57,
nbytes=nbytes@entry=57) at /usr/src/debug/emacs-24.3-4/src/alloc.c:1743
#1 0x00000001004dd3d6 in make_uninit_multibyte_string (nchars=57,
nbytes=57) at /usr/src/debug/emacs-24.3-4/src/alloc.c:2186
#2 0x00000001004dd62c in make_uninit_string (length=<optimized out>) at
/usr/src/debug/emacs-24.3-4/src/alloc.c:2164
(2x)
#0 0x000000010055d520 in abort ()
#1 0x00000001004d49c5 in re_iswctype (ch=ch@entry=24,
cc=cc@entry=RECC_SPACE) at /usr/src/debug/emacs-24.3-4/src/regex.c:2087
(1x)
#6 0x000000010046d365 in bidi_get_type (ch=<optimized out>,
override=override@entry=NEUTRAL_DIR) at
/usr/src/debug/emacs-24.3-4/src/bidi.c:107
(1x)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2500.0x9dc]
0x000000010054da4f in record_backtrace (log=0x10090202d
<bss_sbrk_buffer+250189>, count=count@entry=80) at
/usr/src/debug/emacs-24.3-4/src/profiler.c:149
149 backtrace = HASH_KEY (log, index);
(gdb) bt
#0 0x000000010054da4f in record_backtrace (log=0x10090202d
<bss_sbrk_buffer+250189>, count=count@entry=80) at
/usr/src/debug/emacs-24.3-4/src/profiler.c:149
#1 0x000000010054de04 in malloc_probe (size=size@entry=80) at
/usr/src/debug/emacs-24.3-4/src/profiler.c:516
#2 0x00000001004dca9b in xmalloc (size=size@entry=80) at
/usr/src/debug/emacs-24.3-4/src/alloc.c:673
(1x)
Program received signal SIGSEGV, Segmentation fault.
___chkstk_ms () at
/usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
146 /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S: No such
file or directory.
(gdb) bt
#0 ___chkstk_ms () at
/usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
#1 0x00000001004cefdd in re_match_2_internal (bufp=0x0,
bufp@entry=0x1008bbef0 <searchbufs+6512>, string1=0x100000000 <Address
0x100000000 out of bounds>,
string1@entry=0x6fffff00028 "-*- mode: compilation;
default-directory: \"~/projects/shore-compiler/\" -*-\nCompilation
started at Thu Aug 15 16:00:09\n\nls\n#bug-last.i#\t\t schema.py\t\t
sql_schema.h\n#sql_shore.cpp.rej#\t schema_impl.cpp\t"...,
size1=size1@entry=379, string2=string2@entry=0x6fffff00a01 "",
size2=<optimized out>, size2@entry=0, pos=pos@entry=178,
regs=regs@entry=0x1008ba560 <search_regs>,
stop=stop@entry=370) at /usr/src/debug/emacs-24.3-4/src/regex.c:5055
#2 0x00000001004d5000 in re_search_2 (bufp=bufp@entry=0x1004ccf66
<search_command+310>,
str1=0x6fffff00028 "-*- mode: compilation; default-directory:
\"~/projects/shore-compiler/\" -*-\nCompilation started at Thu Aug 15
16:00:09\n\nls\n#bug-last.i#\t\t schema.py\t\t
sql_schema.h\n#sql_shore.cpp.rej#\t schema_impl.cpp\t"...,
str1@entry=0x2e903e <Address 0x2e903e out of bounds>,
size1=size1@entry=4304161216, str2=0x6fffff00a01 "",
str2@entry=0x100902032 <bss_sbrk_buffer+250194> "", size2=0,
size2@entry=4304161216, startpos=178, startpos@entry=122,
range=192, regs=0x1008ba560 <search_regs>, stop=370) at
/usr/src/debug/emacs-24.3-4/src/regex.c:4458
(1x)
--
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