Re: 64-bit emacs crashes a lot

[Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>]

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