delorie.com/archives/browse.cgi | search |
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:from:to:subject:date:reply-to:message-id | |
:references:in-reply-to:mime-version:content-type | |
:content-transfer-encoding; q=dns; s=default; b=f3Hyrdqk3T8O2ICX | |
HDFt4ao24Xp6smRT+RoupOzBpZLxFM+L7d15h02PrcnE9kHx45RIKI67BSJkMn7P | |
V72g8e/KBnbxWhoo3wLhWHJcwVxyFON5BnCYWnve9MUAxYvbR0c61TshaUIdRdVZ | |
Z0KdKd2TQHD2qqvw9HJ6qCkkv0Y= | |
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:from:to:subject:date:reply-to:message-id | |
:references:in-reply-to:mime-version:content-type | |
:content-transfer-encoding; s=default; bh=0jSm/RZ2XxDTsUq1Tid86C | |
PsO9A=; b=V5cFxTSrY76ZgZ9ah+rROYHKfIpONPHCd/cXRtmGvTpxLnb2mhuGwD | |
sp6cIFg8EnpfWp4PGTZmgDzElEskBf6eta2Yhdefmutfh9C7OOxz/OdE01mwIXUI | |
iDYKoV1x892Xwdt7eSc2iZAFMnr6s9nvYLJMKqCbvRw6OHQVPwLdM= | |
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=-3.4 required=5.0 tests=BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.2 |
From: | Bengt Larsson <lists DOT cygwin4 AT bengtl DOT net> |
To: | cygwin AT cygwin DOT com |
Subject: | Re: 64-bit emacs crashes a lot |
Date: | Fri, 16 Aug 2013 11:07:45 +0200 |
Reply-To: | cygwin AT cygwin DOT com |
Message-ID: | <4mqr09du7v3rm4gn5oo2400grh0kovampd@4ax.com> |
References: | <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> <520D4036 DOT 8010303 AT cs DOT utoronto DOT ca> |
In-Reply-To: | <520D4036.8010303@cs.utoronto.ca> |
User-Agent: | ForteAgent/7.10.32.1214 |
MIME-Version: | 1.0 |
Ryan Johnson wrote: >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. Modern Emacs uses an extended UTF-8 as internal representation. http://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Representations.html -- 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |