Re: Crash during access_keymap
> On Thu, 29 Dec 2005 12:11:07 -0500, "Richard M. Stallman" <[EMAIL > PROTECTED]> said: > I think I fixed the problem of pure objects pointing to impure ones > that might get reclaimed. Do you think the problem is fixed? Yes. As for international/encoded-kb, preloading it now reports the "Attempt to modify read-only object" error. So I think it is no longer tried to be preloaded. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
I think I fixed the problem of pure objects pointing to impure ones that might get reclaimed. Do you think the problem is fixed? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
> Perhaps the proper thing to do would be to NEVER put defvar > and defconsts into pure space, i.e. only put byte-code and > defuns there. This will also make easier to keep the proper size of BASE_PURESIZE. After recent addition of rfn-eshadow, pure Lisp storage increased from 1165464 to 1170232. But I missed the compilation warning about pure storage overflow, and spent some time debugging before I understood why garbage collection was never completed. Wouldn't it be good to display a run-time warning about such GC failure due to pure storage overflow (at least, if garbage-collection-messages is non-nil)? -- 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: Crash during access_keymap
This correctly reports an error for the international/encoded-kb case, but I think at least the vector case in store_in_keymap still has a missing CHECK_IMPURE. I think you're right. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
We have just seen one incident [this thread in fact] where preloading a file with a keymap defined with a defconst would eventually lead to a GC error due to modifying pure objects. That was due to a combination of two bugs, and I think both of them are now fixed. Perhaps we should also change defconst not to purify the value. I asked someone to check how much space that would affect. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
> I don't know -- what is the point of pure space? That you don't have to GC it ... The original point was to share memory between Emacs jobs. I am not sure that is still very important, but it might be. Also in some older systems without copy-on-write, marking the corresponding section as read-only allowed it to be shared between instances of the Emacs process, but nowadays I can't think of any situation where that would be relevant. Segregating the data that will never be altered would increase sharing even on systems that have copy-on-write. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
Perhaps the proper thing to do would be to NEVER put defvar and defconsts into pure space, i.e. only put byte-code and defuns there. How about if you try turning off putting defconsts there and measure the change in size of pure space? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
> That is definitely a bug. Could you change that to a defvar? Why should it be a defvar? Is there a (setq encoded-kbd-mode-map ...) somewhere? If it is reasonable to change a value, it should be a defvar even if nobody actually changes it today. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
Can't we just gc the pure space too? At least with the mark-stack functionality, that would be fairly trivial. We could, but if people can figure out the bug, let's do so. BTW, wouldn't it be about time to drop the old GCPRO stuff -- IMHO it is just too time-consuming to maintain (and it is practically impossible to find those bugs). It would be nice to drop GCPRO if we don't need it. But first we must ask: why do some configurations continue using GCPRO? ___ 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 Wed, 16 Nov 2005 17:01:35 -0500, "Richard M. Stallman" <[EMAIL
> PROTECTED]> said:
> Meanwhile, how about this fix in keymap.c?
This correctly reports an error for the international/encoded-kb case,
but I think at least the vector case in store_in_keymap still has a
missing CHECK_IMPURE.
if (VECTORP (elt))
{
if (NATNUMP (idx) && XFASTINT (idx) < ASIZE (elt))
{
ASET (elt, XFASTINT (idx), def);
return def;
}
insertion_point = tail;
}
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
2005/11/17, Kim F. Storm <[EMAIL PROTECTED]>: > > [Has pure-space been a major contributor to GC bugs? It doesn't ring > > any bells, in particular.] > > How can we know? There are still quite some reported GC-related bugs > that nobody has managed to explain. Sure, but if we don't know, then proceeding based on a random presumption that pure-space is "the cause" doesn't seem like a very sound strategy. -miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
Miles Bader <[EMAIL PROTECTED]> writes: >> I have wasted too much time on GC related problems already. > > Nobody's forcing you. Thanks for reminding me. I'll stop worrying then, and find more interesting things to spend my time on. > > [Has pure-space been a major contributor to GC bugs? It doesn't ring > any bells, in particular.] How can we know? There are still quite some reported GC-related bugs that nobody has managed to explain. We have just seen one incident [this thread in fact] where preloading a file with a keymap defined with a defconst would eventually lead to a GC error due to modifying pure objects. -- 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
Miles Bader <[EMAIL PROTECTED]> writes: > 2005/11/17, Kim F. Storm <[EMAIL PROTECTED]>: >> > If the pure space gets GC'd, what's the point of the pure space? >> >> I don't know -- what is the point of pure space? > > That you don't have to GC it ... Ok, I see. So I will re-iterate my proposal to ONLY EVER put the following items into pure space: - defuns [assuming they are not self-modifyiable] - byte-code Anything else should go into normal GC space, so we can avoid the potential headaches of keeping track of this pure space in various primitives. I have wasted too much time on GC related problems already. -- 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
2005/11/17, Kim F. Storm <[EMAIL PROTECTED]>: > So I will re-iterate my proposal to ONLY EVER put the following items > into pure space: You forget "after the release". > - defuns [assuming they are not self-modifyiable] > > - byte-code > > Anything else should go into normal GC space, so we can avoid > the potential headaches of keeping track of this pure space in > various primitives. So do you have any reasoning behind the above suggestion? AFAICS, the most important thing to be in pure space is large twisty data structures (like normal lists) which take lots of time to traverse in the garbage collector. I'd be suspicious of any proposal that didn't have hard data (like benchmarking) behind it. > I have wasted too much time on GC related problems already. Nobody's forcing you. [Has pure-space been a major contributor to GC bugs? It doesn't ring any bells, in particular.] -miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
>> > If the pure space gets GC'd, what's the point of the pure space? >> I don't know -- what is the point of pure space? > That you don't have to GC it ... Yes, the point AFAIK is to reduce the size of the heap that we have to GC so as to reduce the time spent in the GC. Also in some older systems without copy-on-write, marking the corresponding section as read-only allowed it to be shared between instances of the Emacs process, but nowadays I can't think of any situation where that would be relevant. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
2005/11/17, Kim F. Storm <[EMAIL PROTECTED]>: > > If the pure space gets GC'd, what's the point of the pure space? > > I don't know -- what is the point of pure space? That you don't have to GC it ... -miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
Stefan Monnier <[EMAIL PROTECTED]> writes: >> Can't we just gc the pure space too? > > If the pure space gets GC'd, what's the point of the pure space? I don't know -- what is the point of pure space? Perhaps the proper thing to do would be to NEVER put defvar and defconsts into pure space, i.e. only put byte-code and defuns there. -- 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
> Can't we just gc the pure space too? If the pure space gets GC'd, what's the point of the pure space? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
> (defconst encoded-kbd-mode-map (make-sparse-keymap) > "Keymap for Encoded-kbd minor mode.") > The keymap is allocated in the pure storage if this file is preloaded, > because it is defined by `defconst' (should be `defvar'?). > That is definitely a bug. Could you change that to a defvar? Why should it be a defvar? Is there a (setq encoded-kbd-mode-map ...) somewhere? If someone turns the defconst into a defvar, please please please add a comment explaining that defvar is used because during preloading defconst presumes that the value can be put in pure space. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
"Richard M. Stallman" <[EMAIL PROTECTED]> writes: > > 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. > > Now I'm sure this is the real cause of "Wrong type argument: commandp" > error that is found in some Carbon Emacs distributions that preloads > international/encoded-kb.elc. > > Suppose that the pure structures here were not modified. > (That is, suppose we deleted the code that modifies them, > and put in the correct contents when those data structures > are first created.) Would we still have the problem of > pure pointing to impure which gets GC'd? > Can't we just gc the pure space too? At least with the mark-stack functionality, that would be fairly trivial. BTW, wouldn't it be about time to drop the old GCPRO stuff -- IMHO it is just too time-consuming to maintain (and it is practically impossible to find those bugs). What platforms cannot use mark-stack? Are they really worth supporting? [after all, emacs 21.4 _is_ still available on those platforms, so users on those systems are not completely lost]. -- 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
> 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. Now I'm sure this is the real cause of "Wrong type argument: commandp" error that is found in some Carbon Emacs distributions that preloads international/encoded-kb.elc. Suppose that the pure structures here were not modified. (That is, suppose we deleted the code that modifies them, and put in the correct contents when those data structures are first created.) Would we still have the problem of pure pointing to impure which gets GC'd? In other words, once we have fixed the specific bug we know about, which involves modification of pure objects, do we still have a problem? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
(defconst encoded-kbd-mode-map (make-sparse-keymap)
"Keymap for Encoded-kbd minor mode.")
The keymap is allocated in the pure storage if this file is preloaded,
because it is defined by `defconst' (should be `defvar'?).
That is definitely a bug. Could you change that to a defvar?
Meanwhile, how about this fix in keymap.c?
diff -c /home/rms/emacs/src/keymap.c.\~22\~ /home/rms/emacs/src/keymap.c
*** /home/rms/emacs/src/keymap.c.~22~ Wed Nov 9 18:11:57 2005
--- /home/rms/emacs/src/keymap.cWed Nov 16 08:16:54 2005
***
*** 389,394
--- 389,395
if (EQ (XCDR (prev), parent))
RETURN_UNGCPRO (parent);
+ CHECK_IMPURE (prev);
XSETCDR (prev, parent);
break;
}
***
*** 931,936
--- 932,938
{
if (EQ (idx, XCAR (elt)))
{
+ CHECK_IMPURE (elt);
XSETCDR (elt, def);
return def;
}
***
*** 948,953
--- 950,956
keymap_end:
/* We have scanned the entire keymap, and not found a binding for
IDX. Let's add one. */
+ CHECK_IMPURE (insertion_point);
XSETCDR (insertion_point,
Fcons (Fcons (idx, def), XCDR (insertion_point)));
}
Diff finished. Wed Nov 16 08:17:06 2005
___
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 Tue, 15 Nov 2005 18:21:59 -0500, "Richard M. Stallman" <[EMAIL > PROTECTED]> said: >> I meant a kind of analysis to ensure that any literals inside a >> function are not modified. > I don't quite follow. If they are pure, they cannot be modified; > the primitives that would do so will signal an error. Unless they > have bugs. I'm not suggesting anything. You say compile-time check is unnecessary. I say it is difficult. No problem. > On a system where "pure" space really is read-only, trying to modify > it would cause an immediate crash--good for debugging, but not an > elegant way to report the problem. I guess there are many places that don't do CHECK_IMPURE, and setting watchpoint is as useful for debugging as the read-only pure space. Actually, I found another problem related to international/encode-kb.el using it. This causes a real problem unlike the Fccl_execute_on_string case. (defconst encoded-kbd-mode-map (make-sparse-keymap) "Keymap for Encoded-kbd minor mode.") The keymap is allocated in the pure storage if this file is preloaded, because it is defined by `defconst' (should be `defvar'?). But it is modified in the following part. (defun encoded-kbd-setup-keymap (coding) ;; At first, reset the keymap. (define-key encoded-kbd-mode-map "\e" nil) ;; Then setup the keymap according to the keyboard coding system. `define-key' does not do CHECK_IMPURE for the given keymap, and the following situation really occurs. > On Sun, 13 Nov 2005 15:39:37 +0900, YAMAMOTO Mitsuharu <[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. Now I'm sure this is the real cause of "Wrong type argument: commandp" error that is found in some Carbon Emacs distributions that preloads international/encoded-kb.elc. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
The following doesn't CHECK_IMPURE: #define XSETCAR(c,n) (XCAR_AS_LVALUE(c) = (n)) #define XSETCDR(c,n) (XCDR_AS_LVALUE(c) = (n)) The function that uses those macros is responsible for doing CHECK_IMPURE when appropriate. If you see a specific function that needs to do this, would you please 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
I meant a kind of analysis to ensure that any literals inside a function are not modified. I don't quite follow. If they are pure, they cannot be modified; the primitives that would do so will signal an error. Unless they have bugs. 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? If that function can modify a string, it must call CHECK_IMPURE. On a system where "pure" space really is read-only, trying to modify it would cause an immediate crash--good for debugging, but not an elegant way to report the problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
"Richard M. Stallman" <[EMAIL PROTECTED]> writes: > 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. The following doesn't CHECK_IMPURE: #define XSETCAR(c,n) (XCAR_AS_LVALUE(c) = (n)) #define XSETCDR(c,n) (XCDR_AS_LVALUE(c) = (n)) -- 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 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: 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: 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: 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
Re: Crash during access_keymap
> On Sun, 13 Nov 2005 19:24:34 +, David Reitter <[EMAIL PROTECTED]> > said: > On 13 Nov 2005, at 06:39, YAMAMOTO Mitsuharu wrote: >> 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. > OK, that makes sense. Do you know if this is documented somewhere? I'm not sure if it is explicitly documented. I just read src/alloc.c. The function `mark_object' immediately returns if its argument is a pure object. > I've read the info nodes about pure storage etc., and it doesn't say > anything about what to look for in code, or if there is a way to > test for the effect while loading. Maybe on a port that implements > memory protection? Setting watchpoint to the variable `pure' will do run-time check. It is really feasible in GDB on Mac OS X thanks to hardware watchpoints. > I mostly just preload code, but define a setup function in each > package that is run at runtime. But from what you are saying, I am > getting that vectors are allocated when the file is loaded, and not > copied when a function is called. But if the code used (vector 0 0 0 > 0 0) instead of [0 0 0 0 0], the vector would be allocated at > runtime and we don't run into such trouble. Yes, but a vector is created on every call then. > Does this apply only to vectors? (Since vectors seem immutable to > me, this all would make sense...) Literal strings and conses, as well as several vector-like objects. I don't understand what "vectors seem immutable" means above. Vectors are mutable in the sense that one can alter their contents. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
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? If so, can you see a general rule for how to prevent it from happening? ___ 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 13 Nov 2005, at 06:39, YAMAMOTO Mitsuharu wrote: 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. OK, that makes sense. Do you know if this is documented somewhere? I've read the info nodes about pure storage etc., and it doesn't say anything about what to look for in code, or if there is a way to test for the effect while loading. Maybe on a port that implements memory protection? I mostly just preload code, but define a setup function in each package that is run at runtime. But from what you are saying, I am getting that vectors are allocated when the file is loaded, and not copied when a function is called. But if the code used (vector 0 0 0 0 0) instead of [0 0 0 0 0], the vector would be allocated at runtime and we don't run into such trouble. Does this apply only to vectors? (Since vectors seem immutable to me, this all would make sense...) Any pointers to documentation would be greatly appreciated - I'm happy to read whatever there is. Thanks - David ___ 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 13:15:01 +0900, YAMAMOTO Mitsuharu <[EMAIL > PROTECTED]> said: > Inappropriate preloading also affects the correctness of GC. Since > the pure storage is assumed to be read-only, GC does not mark or > follow the objects in this storage. So, if there's an object that > is only pointed to by pure storage objects, which may happen if the > assumption for the pure storage is violated, the object is reachable > but never get collected. The last sentence was not correct. It should have been: 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. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ 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 Sat, 12 Nov 2005 11:35:43 +, David Reitter <[EMAIL PROTECTED]> > said: > Looking at the C-level patches that Aquamacs and Carbon Emacs > Package have in common: > - transparency > - toolbar-button > Both patches don't do anything unless their respective functionality > is used, as far as I can tell. Either of them is not an essential feature, so you can try to test without them if needed. > I suspect it's rather due to the higher memory management > requirements - the distributions load more packages. I found both of the distributions have some entries for additional preloading in site-load.el, but some of them are not valid. For example, international/encoded-kb.el has the following code: (defun encoded-kbd-self-insert-ccl (ignore) (let ((str (char-to-string (encoded-kbd-last-key))) (ccl (car (aref (coding-system-spec (keyboard-coding-system)) 4))) (vec [nil nil nil nil nil nil nil nil nil]) result) (while (= (length (setq result (ccl-execute-on-string ccl vec str t))) 0) (dotimes (i 9) (aset vec i nil)) (setq str (format "%s%c" str (read-char-exclusive (vector (aref result 0 The vector [nil ...] is allocated in the pure storage if this file is preloaded, but its contents are altered in the function body and thus the read-only assumption of the pure storage is violated. So this file should not be preloaded as it is. Inappropriate preloading also affects the correctness of GC. Since the pure storage is assumed to be read-only, GC does not mark or follow the objects in this storage. So, if there's an object that is only pointed to by pure storage objects, which may happen if the assumption for the pure storage is violated, the object is reachable but never get collected. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ 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 12 Nov 2005, at 05:48, YAMAMOTO Mitsuharu wrote: Still I can't see the "commandp" problem with the CVS version. If it only occurs on some distributions of modified Carbon Emacs, it is difficult for me to help directly, sorry. One thing I can think of is heap corruption caused by missing BLOCK_INPUTs. If -DSYNC_INPUT suppresses the error, it might be due to this. (See the thread starting from http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00074.html) I've been using SYNC_INPUT for a couple of weeks, and I'm still getting the error. It's interesting that we don't have any other signs of memory corruption - always the global keymap, and it seems like mode keymaps are not affected. If the access_keymap crash is due to the same issue, it's another pointer to keymaps. I've had the bug occur reproducibly when loading a large .elc at some point - but I can't repeat this :-( Looking at the C-level patches that Aquamacs and Carbon Emacs Package have in common: - transparency - toolbar-button Both patches don't do anything unless their respective functionality is used, as far as I can tell. I suspect it's rather due to the higher memory management requirements - the distributions load more packages. I tried experimenting with garbage collection settings. While a forced GC makes the bug go away in situations where I can reproduce it for a while, neither a high gc-cons-threshold nor a GC call after initialization will reliably make the bug go away. Is the bug only in the Carbon port for sure, or is it just that it happens to surface there and that the CVS version Carbon port has a particularly wide circulation and high requirements given the distributions that people use? ___ 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 Tue, 8 Nov 2005 00:57:19 +, David Reitter <[EMAIL PROTECTED]> said: > If this is the same bug with corruption of keymaps that everybody is > complaining about: please please find&fix it. This occurs not only > in Aquamacs, but also in recent Carbon Emacs Package builds. I've > already spent hours on tracing this and finding a workaround, and I > haven't gotten far with this. Thanks. Still I can't see the "commandp" problem with the CVS version. If it only occurs on some distributions of modified Carbon Emacs, it is difficult for me to help directly, sorry. One thing I can think of is heap corruption caused by missing BLOCK_INPUTs. If -DSYNC_INPUT suppresses the error, it might be due to this. (See the thread starting from http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00074.html) YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Crash during access_keymap
I was trying to visit a file (emacs-lisp-mode) by doing C-x C-f and
entering a file name.
This usually happens right after "Loading vc-cvs" is displayed.
This is after starting up. This is with a recent Aquamacs build (on
Darwin / OS X), based on the current Emacs CVS. I can't reproduce it
with Emacs CVS or starting up Aquamacs with -Q, sorry.
This also occurs sporadically after loading the file.
I have set garbage-collection-messages to t, and gc-cons-threshold to
400 and I noticed that the error occurs usually after a garbage
collection has been completed ("...done"). I wonder why gcs happen
anyways with a gc-cons-threshold that high.
Manually running (garbage-collect) won't provoke the bug.
Unfortunately, this problem cannot be reliably reproduced.
Sorry if this isn't enough to reproduce (I realize it probably
isn't), but maybe the stack trace below gives some indication.
The always occurs during access_keymap.
If this is the same bug with corruption of keymaps that everybody is
complaining about: please please find&fix it. This occurs not only in
Aquamacs, but also in recent Carbon Emacs Package builds.
I've already spent hours on tracing this and finding a workaround,
and I haven't gotten far with this. Thanks.
---
Date/Time: 2005-11-08 00:20:02.616 +
OS Version: 10.4.3 (Build 8F46)
Report Version: 3
Command: Aquamacs Emacs
Path:/Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs
Parent: WindowServer [104]
Version: Aquamacs 0.9.7, GNU Emacs 22 (1.2a)
PID:18607
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x025ee7a8
Thread 0 Crashed:
0 org.gnu.AquamacsEmacs 0x0008d070 access_keymap + 428 (keymap.c:579)
1 org.gnu.AquamacsEmacs 0x00084954 menu_bar_items + 472
(keyboard.c:7019)
2 org.gnu.AquamacsEmacs 0x00028e94 update_menu_bar + 504 (xdisp.c:
9086)
3 org.gnu.AquamacsEmacs 0x00028bf8 prepare_menu_bars + 356
(xdisp.c:8974)
4 org.gnu.AquamacsEmacs 0x0002b718 redisplay_internal + 1000
(xdisp.c:10659)
5 org.gnu.AquamacsEmacs 0x0007ecdc read_char + 1112 (keyboard.c:2540)
6 org.gnu.AquamacsEmacs 0x00087654 read_key_sequence + 1932
(keyboard.c:8859)
7 org.gnu.AquamacsEmacs 0x0007ca10 command_loop_1 + 1056
(keyboard.c:1530)
8 org.gnu.AquamacsEmacs 0x000e5e70 internal_condition_case + 320
(eval.c:1466)
9 org.gnu.AquamacsEmacs 0x0007c3a8 command_loop_2 + 64 (keyboard.c:
1318)
10 org.gnu.AquamacsEmacs 0x000e584c internal_catch + 248 (eval.c:1211)
11 org.gnu.AquamacsEmacs 0x0007c300 command_loop + 144 (keyboard.c:
1301)
12 org.gnu.AquamacsEmacs 0x0007bce8 recursive_edit_1 + 168
(keyboard.c:991)
13 org.gnu.AquamacsEmacs 0x0007be80 Frecursive_edit + 220
(keyboard.c:1052)
14 org.gnu.AquamacsEmacs 0x0007a980 main + 3128 (emacs.c:1783)
15 org.gnu.AquamacsEmacs 0xa060 _start + 392 (crt.c:267)
16 dyld0x8fe01048 _dyld_start + 60
Thread 0 crashed with PPC Thread State 64:
srr0: 0x0008d070 srr1:
0x0200f930vrsave: 0x
cr: 0x44004242 xer: 0x0004 lr:
0x0008cf30 ctr: 0x
r0: 0x0005 r1: 0xbfffde30 r2:
0x005fced4 r3: 0x025ee7ad
r4: 0x04009f99 r5: 0x0002 r6:
0x r7: 0x0001
r8: 0x00da2758 r9: 0x0003 r10:
0x000efbe8 r11: 0x0001
r12: 0x00084b64 r13: 0x002bc265 r14:
0x008013d2 r15: 0x005f9580
r16: 0x008013d2 r17: 0x005fc6d4 r18:
0x0001 r19: 0x005f9270
r20: 0x005fc530 r21: 0x005fc6dc r22:
0x005fb33c r23: 0x005fc51c
r24: 0x00174784 r25: 0x0002 r26:
0x04009e91 r27: 0x005f936c
r28: 0x04000221 r29: 0xbfffdf58 r30:
0x025ee7a8 r31: 0x0008ced4
Binary Images Description:
0x1000 - 0x175fff org.gnu.AquamacsEmacs Aquamacs 0.9.7, GNU
Emacs 22 (1.2a) /Applications/Aquamacs Emacs.app/Contents/MacOS/
Aquamacs Emacs
0x908000 - 0x933fff libncurses.5.dylib /usr/lib/libncurses.5.dylib
0xc32000 - 0xc63fff liblame3.92.dylib /Library/Application
Support/DivXNetworks/liblame3.92.dylib
0xca - 0xca3fff libMPAEncode0.1.dylib /Library/Application
Support/DivXNetworks/libMPAEncode0.1.dylib
0xca7000 - 0xcb9fff libdpv10.dylib /Library/Application Support/
DivXNetworks/libdpv10.dylib
0xf05000 - 0xfcefff com.divxnetworks.DivXCodec 5.2 /Library/
QuickTime/DivX 5.component/Contents/MacOS/DivX 5
0x108d000 - 0x10edfff libdpus10.dylib /Library/Application Support/
DivXNetworks/libdpus10.dylib
0x2295000 - 0x229bfff com.apple.DictionaryServiceComponent 1.0.0 /
System/Library/Components/DictionaryService.component/Conten
