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
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
