delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2013/08/15/16:55:44

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:message-id:date:from:mime-version:to:subject
:references:in-reply-to:content-type:content-transfer-encoding;
q=dns; s=default; b=aAlo99Y0GJL591VF03RdyPOnhiNz79OQJCb3DeaIm2N
6IWs1spT/wTEPwgdZ5Zcqcl0Fw836mEwDvaTip8oNAnkQwYiHEhb1Aa9soZWhJkI
6tnJoejp1CpPBHDAlMInRqcn5pTs8ZGV7ByYvVs9p9ZYcoBL+RlfU/kVItb8uWlg
=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:message-id:date:from:mime-version:to:subject
:references:in-reply-to:content-type:content-transfer-encoding;
s=default; bh=HoGXLcfd4iqWyN0Nqfwxb8Zdb68=; b=o1xXcSYnQKJWngzyJ
m2qIIcmiuIDqOGFBClDgF4o2fw0ffcLI98NJfdJwXwraioG2Kw1Tsj17mGoftC8Z
366cGasuKxONaywSOp8HaMkgEBB5p3FN2BaqAxB7ylGQ1y/MPXire1IbW9ZUIgPm
Md/RwbvKsXNF+urRN4pkSULRHY=
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
X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_50,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RP_MATCHES_RCVD,SPF_NEUTRAL autolearn=ham version=3.3.2
Message-ID: <520D4036.8010303@cs.utoronto.ca>
Date: Thu, 15 Aug 2013 16:55:18 -0400
From: Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
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>
In-Reply-To: <83ioz6op5v.fsf@gnu.org> 

On 15/08/2013 1:10 PM, Eli Zaretskii wrote:
>> Date: Thu, 15 Aug 2013 12:58:02 -0400
>> From: Ken Brown <kbrown AT cornell DOT edu>
>> CC: Eli Zaretskii <eliz AT gnu DOT 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 AT entry=0x1008bab40 
<searchbufs+1472>, string1=0x100000000 <Address 0x100000000 out of bounds>,
     string1 AT 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 AT entry=379, string2=0x2214bc "\001", string2 AT entry=0x6fffff00973 
"", size2=370, size2 AT entry=0, pos=<optimized out>, pos AT entry=138, 
regs=<optimized out>,
     regs AT entry=0x1008ba560 <search_regs>, stop=<optimized out>, 
stop AT 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 AT entry=0x225380, 
what=IT_COMPOSITION, what AT entry=IT_CONTINUATION) at 
/usr/src/debug/emacs-24.3-4/src/xdisp.c:24365
#7  0x000000010041b637 in init_iterator (it=it AT entry=0x225380, 
w=w AT entry=0x100d37ca0 <bss_sbrk_buffer+4664768>, 
charpos=charpos AT entry=1, bytepos=bytepos AT entry=1, row=0x6002d4000,
(2x)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3120.0x360]
allocate_string_data (s=s AT entry=0x60024e9e0, nchars=nchars AT entry=57, 
nbytes=nbytes AT 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 AT entry=0x60024e9e0, nchars=nchars AT entry=57, 
nbytes=nbytes AT 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 AT entry=24, 
cc=cc AT 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 AT 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 AT 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 AT entry=80) at 
/usr/src/debug/emacs-24.3-4/src/profiler.c:149
#1  0x000000010054de04 in malloc_probe (size=size AT entry=80) at 
/usr/src/debug/emacs-24.3-4/src/profiler.c:516
#2  0x00000001004dca9b in xmalloc (size=size AT 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 AT entry=0x1008bbef0 <searchbufs+6512>, string1=0x100000000 <Address 
0x100000000 out of bounds>,
     string1 AT 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 AT entry=379, string2=string2 AT entry=0x6fffff00a01 "", 
size2=<optimized out>, size2 AT entry=0, pos=pos AT entry=178, 
regs=regs AT entry=0x1008ba560 <search_regs>,
     stop=stop AT entry=370) at /usr/src/debug/emacs-24.3-4/src/regex.c:5055
#2  0x00000001004d5000 in re_search_2 (bufp=bufp AT 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 AT entry=0x2e903e <Address 0x2e903e out of bounds>, 
size1=size1 AT entry=4304161216, str2=0x6fffff00a01 "", 
str2 AT entry=0x100902032 <bss_sbrk_buffer+250194> "", size2=0,
     size2 AT entry=4304161216, startpos=178, startpos AT 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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019