Re: Crash during access_keymap
> On Tue, 15 Nov 2005 00:42:57 -0500, "Richard M. Stallman" <[EMAIL > PROTECTED]> said: > If the problem is reproducible, it should be fairly straightforward > to debug. Is there clobbered data or not? I myself don't see the problem, but according to the report from David, some keymap seems to be clobbered. >> I think compile-time analysis would not become perfect because of >> dynamic bindings. > Sorry, I don't understand. Symbols are never copied to pure space, > so their bindings, whether dynamic or not, can't cause this kind of > problem. I meant a kind of analysis to ensure that any literals inside a function are not modified. In dynamic scoping environment, objects exposed to another function are not limited to those are passed via arguments. >> On some systems including Mac OS X, the pure storage is not >> remapped to the text segment. But still one can set watchpoint to >> the array `pure' to do run-time check. > I don't follow. Run-time check of what? To detect the case that the contents of the pure storage are changed accidentally. It actually occurred when I tried preloading international/encoded-kb.elc. Maybe CHECK_IMPURE should be added to Fccl_execute_on_string? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: set-window-point
Yes, you're right. If I use the patch below it works. Shall I install it, or is it a bug in set-window-point? If it's not a bug, I think this behaviour should be documented. Please install it. I think the failure of set-window-point in this case is a bug, but I don't know whether we will be able to fix it. Can someone figure out why it fails to take effect in this case? ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No default value, but prompt says there is one: customize-variable
Does this fix give good results?
Index: cus-edit.el
===
RCS file: /cvsroot/emacs/emacs/lisp/cus-edit.el,v
retrieving revision 1.237
diff -c -c -r1.237 cus-edit.el
*** cus-edit.el 23 Oct 2005 17:40:38 - 1.237
--- cus-edit.el 15 Nov 2005 04:26:45 -
***
*** 497,503
(if (and (symbolp v) (custom-variable-p v))
(format "Customize option (default %s): " v)
"Customize option: ")
! obarray 'custom-variable-p t))
(list (if (equal val "")
(if (symbolp v) v nil)
(intern val)
--- 497,504
(if (and (symbolp v) (custom-variable-p v))
(format "Customize option (default %s): " v)
"Customize option: ")
! obarray 'custom-variable-p t nil nil
! (and (symbolp v) (symbol-name v
(list (if (equal val "")
(if (symbolp v) v nil)
(intern val)
***
*** 798,804
(interactive)
(let ((children custom-options))
(mapc (lambda (widget)
! (and (widget-apply widget :custom-standard-value)
(if (memq (widget-get widget :custom-state)
'(modified set changed saved rogue))
(widget-apply widget :custom-reset-standard
--- 799,806
(interactive)
(let ((children custom-options))
(mapc (lambda (widget)
! (and (widget-get widget :custom-standard-value)
!(widget-apply widget :custom-standard-value)
(if (memq (widget-get widget :custom-state)
'(modified set changed saved rogue))
(widget-apply widget :custom-reset-standard
***
*** 3397,3403
(define-widget 'face 'symbol
"A Lisp face name (with sample)."
! :format "%t: (%{sample%}) %v"
:tag "Face"
:value 'default
:sample-face-get 'widget-face-sample-face-get
--- 3399,3405
(define-widget 'face 'symbol
"A Lisp face name (with sample)."
! :format "%{%t%}: (%{sample%}) %v"
:tag "Face"
:value 'default
:sample-face-get 'widget-face-sample-face-get
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
Yeah, I only thought about the case that a pointer in the pure storage are changed so as to point to an impure object during the execution of a dumped one, but that may also occur in a dumping session. Pure objects should never be changed; that's why it is ok to make them pure. The access primitives to modify slost in types that can be pure are supposed to detect such an attempt and signal errors, with CHECK_IMPURE If any such primitive fails to use CHECK_IMPURE, let's just fix it. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
It seems to be possible to have a check_pure_storage function which would traverse pure storage and validate that it only refers to other pure object -- and also that pure storage only contains valid objects (e.g. I don't think storing a buffer or window object in pure storage makes any sense). If we conclude that this problem is real, we could solve it much more easily than that. When copying an object to pure space, any time it points to an object that isn't copied, we could verify that that object will be protected in some other way. If not, we could staticpro the pure slot. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
David (and others) are distributing precompiled GNU Emacs binaries with additional files preloaded. And they see a problem (so-called "commandp" one) which I don't see with the CVS version. I suspect this is due to the situation above, but there's no evidence yet. If the problem is reproducible, it should be fairly straightforward to debug. Is there clobbered data or not? > If so, can you see a general rule for how to prevent it from > happening? I think compile-time analysis would not become perfect because of dynamic bindings. Sorry, I don't understand. Symbols are never copied to pure space, so their bindings, whether dynamic or not, can't cause this kind of problem. On some systems including Mac OS X, the pure storage is not remapped to the text segment. But still one can set watchpoint to the array `pure' to do run-time check. I don't follow. Run-time check of what? ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon with -nw: kCGErrorRangeCheck / Abort trap
> On Mon, 14 Nov 2005 12:14:39 +, David Reitter <[EMAIL PROTECTED]> > said: > The Carbon port starts up in TTY mode when given the -nw parameter. > When logged in as non-console user, i.e. remotely, the process > crashes. > To reproduce: > ssh [EMAIL PROTECTED] (...) > lucy:/Volumes/Sista/Applications/Emacs.app/Contents/MacOS test$ ./Emacs -nw > kCGErrorRangeCheck : Window Server communications from outside of session > allowed for root and console user only > INIT_Processeses(), could not establish the default connection to the > WindowServer. > Fatal error (6)Abort trap Thanks for the report. I just installed a fix. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
weird defadvice bug with byte-compilation
This is a weird one. I've pared it down to the bare bones, I think -
if I comment out any part of this, the bug doesn't occur. This
obviously comes from a larger context - when it is pared down, the
code doesn't make much sense, of course.
If the stuff is in the same file, or the order is different, no bug
(error). It must be like this: two files, one of which is compiled and
required by the other. And the requiring file must have "compile" in
its defadvice.
Two files:
File 1: foo.el
--
(defvar mymap nil "")
(let ((map (make-sparse-keymap "II")))
(setq mymap (make-sparse-keymap))
(define-key menu-bar-search-menu [ise] '("" . ise))
(put 'ise 'menu-enable '(and my-mode))
(push (cons 'my-mode mymap) minor-mode-map-alist))
(defadvice next-history-element (after activate) "" my-mode)
(provide 'foo)
File 2: bar.el
--
(defconst special-display-regexps '("[ ]?[*][^*]+[*]"))
(defvar drews-lisp-dir "C:\\drews-lisp-20" "")
(setq load-path (append (list drews-lisp-dir) load-path))
(defadvice occur-mode-goto-occurrence
(around jj activate compile)
""
ad-do-it)
(require 'foo)
Instructions:
-
1. emacs -q
2. Byte-compile foo.el (it doesn't matter if it's compiled on Emacs 20
or 22). `C-x C-c'.
3. emacs -q(Emacs 22)
4. Visit bar.el - don't load it.
5. Select everything in bar.el except the (require 'foo), and do
`eval-region'.
6. Put the cursor just after the (require 'foo) and do `C-x C-e'. (Don't
select it and do eval-region - that doesn't produce the bug!)
You will get this error backtrace:
Debugger entered--Lisp error: (void-variable my-mode)
(and my-mode)
x-create-frame(((visibility) (height . 14) (width . 80) (unsplittable .
t)))
x-create-frame-with-faces(((height . 14) (width . 80) (unsplittable . t)))
make-frame(((height . 14) (width . 80) (unsplittable . t)))
special-display-popup-frame(#)
display-buffer(#)
display-warning(bytecomp "reference to free variable `my-mode'" :warning
"*Compile-Log*")
byte-compile-log-warning("reference to free variable `my-mode'" t
:warning)
byte-compile-warn("reference to free variable `%s'" my-mode)
byte-compile-variable-ref(byte-varref my-mode)
byte-compile-form(my-mode t)
byte-compile-body(((setq ad-return-value (ad-Orig-next-history-element n))
my-mode ad-return-value) nil)
byte-compile-let((let (ad-return-value) (setq ad-return-value
(ad-Orig-next-history-element n)) my-mode ad-return-value))
byte-compile-form((let (ad-return-value) (setq ad-return-value
(ad-Orig-next-history-element n)) my-mode ad-return-value) nil)
byte-compile-top-level((progn (let (ad-return-value) (setq ad-return-value
...) my-mode ad-return-value)) nil lambda)
byte-compile-lambda((lambda (n) "$ad-doc: next-history-element$"
(interactive "p") (let (ad-return-value) (setq ad-return-value ...) my-mode
ad-return-value)))
#[nil "???\n
\f
??
7. `C-x C-c'
You will get a pop-up message with Yes/No buttons that says this:
Emacs Abort Dialog
"A fatal error has occurred! Would you like to attach a debugger? Select YES
to debu, NO to abort Emacs"
If you select Yes, you get a Window program exception and an invitation to
send the details to Microsoft. The error report contents are these:
Exception Information
Code 0x8003 Flags: 0x
Record: 0x (didn't count 'em) Address: 0x77f75a58
System Information
Windows NT 5.1 Build: 2600
CPU Vendor Code etc. blah blah blah
Module 1
emacs.exe
blah blah
Module 2
ntdll.dll
blah blah
Module 3
kernel32.dll
blah blah
Module 4
msvcrt.dll
blah blah
etc. etc.
In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
of 2005-06-26 on NONIQPC
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc
(3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../.
./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl
ude'
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No i-search for € in iso-8859-16 coded buffer
>> Is there a lisp syntax for U+20AC?
>
> AFAIK, no. Perhaps #u20AC is a good syntax for this.
>
> Perl uses the "\x{...}" notation for Unicode characters. Doing the
> same in Emacs would produce #x{20AC}. Also Perl has the notation for
> Unicode character names: \N{EURO SIGN}. In Emacs this would be
> like #u{EURO SIGN}.
And Common Lisp uses the notation #\euro_sign, but IMO it is not quite
nice, because using official Unicode character names requires replacing
spaces with underscores.
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No i-search for € in iso-8859-16 coded buffer
Am 14.11.2005 um 21:50 schrieb Juri Linkov: I could live with this decision, but I would prefer a state in which the characters could be found. You can use `M-x unify-8859-on-decoding-mode' to toggle the charset of characters you want to search with isearch. This unify means here a divide? An indicator which characters are right now seekable would be nice ... The emacs-unicode-2 branch doesn't have this problem. I knew my preference for this one didn't come out of the blue ... -- Greetings Pete Either this man is dead or my watch has stopped. - Groucho Marx ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No i-search for € in iso-8859-16 coded buffer
>>character: € (01235114, 342604, 0x53a4c, U+20AC)
> ...
>> I think it was a good change to use lisp-readable syntax for `M-:',
>> so the same syntax should be used for `C-x =' as well.
>
> Yeah...
>
> Is there a lisp syntax for U+20AC?
AFAIK, no. Perhaps #u20AC is a good syntax for this.
Perl uses the "\x{...}" notation for Unicode characters. Doing the
same in Emacs would produce #x{20AC}. Also Perl has the notation for
Unicode character names: \N{EURO SIGN}. In Emacs this would be
like #u{EURO SIGN}.
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No i-search for € in iso-8859-16 coded buffer
> I could live with this decision, but I would prefer a state in which > the characters could be found. You can use `M-x unify-8859-on-decoding-mode' to toggle the charset of characters you want to search with isearch. The emacs-unicode-2 branch doesn't have this problem. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
customize-group completions
Almost half of all completions available from the completion list of `customize-group' are not group names, but option names. This is due to the completion predicate in `customize-group': (lambda (symbol) (or (get symbol 'custom-loads) (get symbol 'custom-group))) It assumes that a group symbol has either `custom-loads' or `custom-group' property. Whereas `custom-group' is a reliable way to identify symbols of customization groups, `custom-loads' is not, because non-groups symbols have it too, since `custom-autoload' in loaddefs.el puts this property on autoload options. But `custom-autoload' also puts another property `custom-autoload' on autoload options, and group symbols don't have this property. So how about filtering out symbols with `custom-autoload' property? This should leave only already loaded groups and also groups with `custom-loads' property from cus-load.el: (lambda (symbol) (or (and (get symbol 'custom-loads) (not (get symbol 'custom-autoload))) (get symbol 'custom-group))) However, it is possible that there is a group in cus-load.el with the same name as autoload option in loaddefs.el. In this case, this name won't get into the completion list. Maybe a better solution is to put `custom-group' property explicitly on every group symbol in cus-load.el? -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Two buglets in diary-list-entries
> (i) In my init-file default-major-mode is set to text-mode and as a > result, since diary-list-entries only checks for fundamental-mode, my > diary file isn't automatically visited in diary-mode. I've installed your patch for this, thank you. > (ii) In the diary display (I use fancy-diary-display) there are > unwanted blank lines between entries from the same day, which arise > when the last line of the diary file or of any included files is a > newline. I usually don't add a newline myself when making a diary > entry, so these seem to be coming from somewhere else. Your patch modifies the buffer which is very unclean in a function which is only supposed to extract data from it. Does the patch below work as well? Stefan --- orig/lisp/calendar/diary-lib.el +++ mod/lisp/calendar/diary-lib.el @@ -472,7 +472,8 @@ (forward-line 1) (while (looking-at "[ \t]") (forward-line 1)) - (unless (eobp) (backward-char 1)) + (unless (and (eobp) (not (bolp))) + (backward-char 1)) (unless list-only (remove-overlays date-start (point) 'invisible 'diary)) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No default value, but prompt says there is one: customize-variable
> Put cursor on this text in some buffer: Buffer-menu-mode-width. > > M-x customize-variable > > The prompt says that the default is Buffer-menu-mode-width, but > completing-read is called with a nil DEF value, and you cannot pull > Buffer-menu-mode-width into the minibuffer with M-n. Thanks. I fixed this. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: No default value, but prompt says there is one: customize-variable
> Put cursor on this text in some buffer: Buffer-menu-mode-width. > > M-x customize-variable > > The prompt says that the default is Buffer-menu-mode-width, but > completing-read is called with a nil DEF value, and you cannot pull > Buffer-menu-mode-width into the minibuffer with M-n. Thanks. I fixed this. Thanks. (That was quick!) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
No default value, but prompt says there is one: customize-variable
emacs -q Put cursor on this text in some buffer: Buffer-menu-mode-width. M-x customize-variable The prompt says that the default is Buffer-menu-mode-width, but completing-read is called with a nil DEF value, and you cannot pull Buffer-menu-mode-width into the minibuffer with M-n. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../. ./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl ude' ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Carbon with -nw: kCGErrorRangeCheck / Abort trap
The Carbon port starts up in TTY mode when given the -nw parameter. When logged in as non-console user, i.e. remotely, the process crashes. To reproduce: ssh [EMAIL PROTECTED] (...) lucy:/Volumes/Sista/Applications/Emacs.app/Contents/MacOS test$ ./ Emacs -nw kCGErrorRangeCheck : Window Server communications from outside of session allowed for root and console user only INIT_Processeses(), could not establish the default connection to the WindowServer. Fatal error (6)Abort trap One error occurs during bootstrapping (calls to temacs) when run as a user who is not root and isn't a locally logged in user, i.e. when building Emacs on a server. Here, kCGErrorRangeCheck appears (but not the INIT_Processes one, I believe) and it doesn't lead to an abort. This is a vanilla CVS build with ./make-package --self-contained -- build-in-place smime.p7s Description: S/MIME cryptographic signature ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
> On Mon, 14 Nov 2005 10:49:03 +0100, [EMAIL PROTECTED] (Kim F. Storm) said: > It seems to be possible to have a check_pure_storage function which > would traverse pure storage and validate that it only refers to > other pure object -- and also that pure storage only contains valid > objects (e.g. I don't think storing a buffer or window object in > pure storage makes any sense). > This function only needed to be run once during the build process, > e.g. just before undump. Yeah, I only thought about the case that a pointer in the pure storage are changed so as to point to an impure object during the execution of a dumped one, but that may also occur in a dumping session. The latter cannot be caught by the watchpoint. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No i-search for € in iso-8859-16 coded buffer
Am 14.11.2005 um 02:03 schrieb Juri Linkov: In a buffer starting with ';;; -*- mode: Text; coding: iso-8859-16; -*-' (-r: in the mode-line) and holding the characters in the range 160-255 i-search for € is not successful: € = 244 = 164 = A4 = U+20AC = E2 82 AC : EURO SIGN That's because ISO-8859-15 (Latin-9) is coded internally with latin-iso8859-15 charset, but ISO-8859-16 (Latin-10) is coded with mule-unicode-0100-24ff charset. I don't know a reason for this decision. Perhaps there are some ISO-8859-16 characters that exist only in mule-unicode-0100-24ff, and not in any of latin-iso8859-... charsets. I could live with this decision, but I would prefer a state in which the characters could be found. Besides the € there are these too: Ą = 241 = 161 = A1 = U+0104 =C4 84 : LATIN CAPITAL LETTER A WITH OGONEK ą = 242 = 162 = A2 = U+0105 =C4 85 : LATIN SMALL LETTER A WITH OGONEK Ł = 243 = 163 = A3 = U+0141 =C5 81 : LATIN CAPITAL LETTER L WITH STROKE „ = 245 = 165 = A5 = U+201E = E2 80 9E : DOUBLE LOW-9 QUOTATION MARK š = 250 = 168 = A8 = U+0160 =C5 A1 : LATIN SMALL LETTER S WITH CARON Ș = 252 = 170 = AA = U+0218 =C8 98 : LATIN CAPITAL LETTER S WITH COMMA BELOW Ź = 254 = 172 = AC = U+0179 =C5 B9 : LATIN CAPITAL LETTER Z WITH ACUTE ź = 256 = 174 = AE = U+017A =C5 BA : LATIN SMALL LETTER Z WITH ACUTE Ż = 257 = 175 = AF = U+017B =C5 BB : LATIN CAPITAL LETTER Z WITH DOT ABOVE Č = 262 = 178 = B2 = U+010C =C4 8C : LATIN CAPITAL LETTER C WITH CARON ł = 263 = 179 = B3 = U+0142 =C5 82 : LATIN SMALL LETTER L WITH STROKE Ž = 264 = 180 = B4 = U+017D =C5 BD : LATIN CAPITAL LETTER Z WITH CARON ” = 265 = 181 = B5 = U+201D = E2 80 9D : RIGHT DOUBLE QUOTATION MARK ž = 270 = 184 = B8 = U+017E =C5 BE : LATIN SMALL LETTER Z WITH CARON č = 271 = 185 = B9 = U+010D =C4 8D : LATIN SMALL LETTER C WITH CARON ș = 272 = 186 = BA = U+0219 =C8 99 : LATIN SMALL LETTER S WITH COMMA BELOW Œ = 274 = 188 = BC = U+0152 =C5 92 : LATIN CAPITAL LIGATURE OE œ = 275 = 189 = BD = U+0153 =C5 93 : LATIN SMALL LIGATURE OE Ÿ = 276 = 190 = BE = U+0178 =C5 B8 : LATIN CAPITAL LETTER Y WITH DIAERESIS ż = 277 = 191 = BF = U+017C =C5 BC : LATIN SMALL LETTER Z WITH DOT ABOVE Ă = 303 = 195 = C3 = U+0102 =C4 82 : LATIN CAPITAL LETTER A WITH BREVE Ć = 305 = 197 = C5 = U+0106 =C4 86 : LATIN CAPITAL LETTER C WITH ACUTE Ń = 321 = 209 = D1 = U+0143 =C5 83 : LATIN CAPITAL LETTER N WITH ACUTE Ő = 325 = 213 = D5 = U+0150 =C5 90 : LATIN CAPITAL LETTER O WITH DOUBLE ACUTE Ś = 327 = 215 = D7 = U+015A =C5 9A : LATIN CAPITAL LETTER S WITH ACUTE Ű = 330 = 216 = D8 = U+0170 =C5 B0 : LATIN CAPITAL LETTER U WITH DOUBLE ACUTE Ę = 335 = 221 = DD = U+0118 =C4 98 : LATIN CAPITAL LETTER E WITH OGONEK Ț = 336 = 222 = DE = U+021A =C8 9A : LATIN CAPITAL LETTER T WITH COMMA BELOW ă = 343 = 227 = E3 = U+0103 =C4 83 : LATIN SMALL LETTER A WITH BREVE ć = 345 = 229 = E5 = U+0107 =C4 87 : LATIN SMALL LETTER C WITH ACUTE ń = 361 = 241 = F1 = U+0144 =C5 84 : LATIN SMALL LETTER N WITH ACUTE ő = 365 = 245 = F5 = U+0151 =C5 91 : LATIN SMALL LETTER O WITH DOUBLE ACUTE ś = 367 = 247 = F7 = U+015B =C5 9B : LATIN SMALL LETTER S WITH ACUTE ű = 370 = 248 = F8 = U+0171 =C5 B1 : LATIN SMALL LETTER U WITH DOUBLE ACUTE ę = 375 = 253 = FD = U+0119 =C4 99 : LATIN SMALL LETTER E WITH OGONEK ț = 376 = 254 = FE = U+021B =C8 9B : LATIN SMALL LETTER T WITH COMMA BELOW -- Greetings Pete "I love deadlines. I love the whooshing noise they make as they go by" (Douglas Adams) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: >> On Sun, 13 Nov 2005 23:54:29 -0500, "Richard M. Stallman" <[EMAIL >> PROTECTED]> said: > >>> So, if there's a non-pure object that is only pointed to by pure >>> objects, which may happen if the assumption for the pure storage is >>> violated, then the object is reachable but get collected. > >> Is there evidence that this is in fact happening? > > David (and others) are distributing precompiled GNU Emacs binaries > with additional files preloaded. And they see a problem (so-called > "commandp" one) which I don't see with the CVS version. I suspect > this is due to the situation above, but there's no evidence yet. > >> If so, can you see a general rule for how to prevent it from >> happening? > > I think compile-time analysis would not become perfect because of > dynamic bindings. > > On some systems including Mac OS X, the pure storage is not remapped > to the text segment. But still one can set watchpoint to the array > `pure' to do run-time check. I think it is sufficient if additional > preloading is for developers/power-users rather than for ordinary > users. It seems to be possible to have a check_pure_storage function which would traverse pure storage and validate that it only refers to other pure object -- and also that pure storage only contains valid objects (e.g. I don't think storing a buffer or window object in pure storage makes any sense). This function only needed to be run once during the build process, e.g. just before undump. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
> On Sun, 13 Nov 2005 23:54:29 -0500, "Richard M. Stallman" <[EMAIL > PROTECTED]> said: >> So, if there's a non-pure object that is only pointed to by pure >> objects, which may happen if the assumption for the pure storage is >> violated, then the object is reachable but get collected. > Is there evidence that this is in fact happening? David (and others) are distributing precompiled GNU Emacs binaries with additional files preloaded. And they see a problem (so-called "commandp" one) which I don't see with the CVS version. I suspect this is due to the situation above, but there's no evidence yet. > If so, can you see a general rule for how to prevent it from > happening? I think compile-time analysis would not become perfect because of dynamic bindings. On some systems including Mac OS X, the pure storage is not remapped to the text segment. But still one can set watchpoint to the array `pure' to do run-time check. I think it is sufficient if additional preloading is for developers/power-users rather than for ordinary users. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
