On 15/08/2013 1:10 PM, Eli Zaretskii wrote:
Date: Thu, 15 Aug 2013 12:58:02 -0400
From: Ken Brown <kbr...@cornell.edu>
CC: Eli Zaretskii <e...@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
