Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
In article <[EMAIL PROTECTED]>, Leo <[EMAIL PROTECTED]> writes: > It happens usually when there are many links in a buffer such as in ERC > or W3M. I can move around mouse in a w3m buffer with tons of links (such > as www.6park.com) to catch a crash, which usually happens within a few > minutes. I just catch one with 'emacs -Q'. Unfortunately I don't know > the exact recipe to trigger a crash. I've just installed w3m and emacs-w3m, visited www.6park.com, moved mouse-cursor and normal cursor onto various links, but couldn't trigger a crash. > The following can help you see the bug although it won't crash Emacs: > o emacs -Q --enable-font-backend -fn SOMEFONT > o C-u 3 2 M-x hanoi > You should see the frame flickering like TV disturbed by static. I can confirm the flickering with some fonts of some size. For instance, this cause flickering: emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=16' but these don't cause flickering: emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=24' emacs-unicode --enable-font-backend -fn 'lucidatypewriter:pixelsize=16' I think the reason is that font-height of "dejavu sans mono:pixelsize=16" is somehow shorter than the glyph '|' in that font. So, every time Emacs redraw '|', the upper and lower lines are also redrawn which leads to the whole buffer redrawing. For instance, when I replace all occurence of "?\|" in lisp/play/hanoi.el with "?i", even this: emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=16' stops flickering. Perhaps we must do something like this: o When we open a font for a frame, check the ascents and descents of ASCII characters (perhaps checking only "\|/" is ok), and set font's ascent and descent to the maximum of them if the font's data is shorter than glyphs' data. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
>> But isn't globalbind already a copy of the global map? Nope. >> I see no function assq-remove-all. Is this in Emacs 23? > My guess is, it's (another) one of Stefan's local changes... :) No. I don't have such a thing here either. But the name should make the intended behavior clear enough. Stefan ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
Nick Roberts wrote: > But isn't globalbind already a copy of the global map? > > (setq globalbind (cdr (global-key-binding keyseq))) By experiment, no, eg: (define-key lisp-interaction-mode-map [menu-bar edit] 'undefined) M-x tmm-menubar will delete the Edit menu from _all_ buffers. Adding a copy-sequence prevents that. > I see no function assq-remove-all. Is this in Emacs 23? My guess is, it's (another) one of Stefan's local changes... :) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
Stefan Monnier writes: > >> ! (setq globalbind (assq-delete-all (car-safe item) > >> globalbind > > If I read the code correctly, this is dangerous because it may modify the > global map. I.e. it should use assq-remove-all or copy-sequence. But isn't globalbind already a copy of the global map? (setq globalbind (cdr (global-key-binding keyseq))) I see no function assq-remove-all. Is this in Emacs 23? Despite the subject header this was an Emacs 22 problem too. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Richard Stallman <[EMAIL PROTECTED]> writes: > How can I be sure that the change "only takes action in the bug case" ? > > You could add code inside a conditional which tests for that case. > Then you know it won't affect any other cases. I don't have a clue to how to write the "conditional which tests for that case". Show what that conditional is ... then we can continue this talk. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
How can I be sure that the change "only takes action in the bug case" ? You could add code inside a conditional which tests for that case. Then you know it won't affect any other cases. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: keymap changes in run-with-timer
> I have a workaround there for this. I call top-level after such > changes (in this case after changing major mode in a timer). That is a very bad practice. If there is any case where no other method is available, we should consider that a serious problem and implement what is needed so that some other method can be used. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: Another little question: On w32 I failed to apply this patch with the patch program from gnuwin32 (version 2.5.9). I wonder if this is a problem with that patch program or something else. How do I continue when patch fails? Most of the patch where applied. The patch fails with the following reject (xdisp.c.rej): Sorry if I wasted someonce time. There were no problems applying the patch, I just applied it to the wrong tree. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote:
Richard Stallman <[EMAIL PROTECTED]> writes:
At this stage of the release cycle, a grave bug is one that makes Emacs
crash, or causes really bad redisplay behaviour.
I think redisplay bugs are serious bugs.
In this case, I know what the fix is (see attached patch). The
trouble is that it's a rather big change, and likely to cause
problems, whereas the problem it corrects is not commonly encountered
(cursor positioning in multi-line overlay before/after-strings).
So I'd like to delay this till after Emacs 22.1. WDYT?
Great. I will test this and I guess I do not have to say I want it now.
I can of course not say I understand the code, but I will try to look at
it anyway.
BTW when I made a brief try to understand the code I noticed the text
property Qcomposition. That is missing from (info "(elisp) Special
Properties"). Should it not be there? Or is it something internal only?
Another little question: On w32 I failed to apply this patch with the
patch program from gnuwin32 (version 2.5.9). I wonder if this is a
problem with that patch program or something else. How do I continue
when patch fails?
Most of the patch where applied. The patch fails with the following
reject (xdisp.c.rej):
***
*** 11933,11952
Lisp_Object string;
struct glyph *stop = glyph;
int pos;
limit = make_number (pt_old + 1);
glyph = string_start;
x = string_start_x;
string = glyph->object;
! pos = string_buffer_position (w, string, string_before_pos);
! /* If STRING is from overlay, LAST_POS == 0. We skip such glyphs
!because we always put cursor after overlay strings. */
! while (pos == 0 && glyph < stop)
{
string = glyph->object;
SKIP_GLYPHS (glyph, stop, x, EQ (glyph->object, string));
if (glyph < stop)
! pos = string_buffer_position (w, glyph->object, string_before_pos);
}
while (glyph < stop)
--- 11934,11955
Lisp_Object string;
struct glyph *stop = glyph;
int pos;
+ Lisp_Object overlay = Qnil;
limit = make_number (pt_old + 1);
glyph = string_start;
x = string_start_x;
string = glyph->object;
! pos = string_buffer_position (w, string, string_before_pos,
&overlay);
! /* If STRING is from overlay, skip its glyphs because we always
!put cursor after overlay strings. */
! while ((pos == 0 || !NILP (overlay)) && glyph < stop)
{
string = glyph->object;
SKIP_GLYPHS (glyph, stop, x, EQ (glyph->object, string));
if (glyph < stop)
! pos = string_buffer_position (w, glyph->object,
! string_before_pos, &overlay);
}
while (glyph < stop)
***
*** 15858,15869
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
!the cursor there, but we still want it at the start of the
!string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row->end.string_pos) >= 0)
! cursor_row_p = (row->continued_p
! || PT >= MATRIX_ROW_START_CHARPOS (row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15861,15870
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
!the cursor there.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row->end.string_pos) >= 0)
! cursor_row_p = row->continued_p;
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Richard Stallman <[EMAIL PROTECTED]> writes:
> At this stage of the release cycle, a grave bug is one that makes Emacs
> crash, or causes really bad redisplay behaviour.
>
> I think redisplay bugs are serious bugs.
In this case, I know what the fix is (see attached patch). The
trouble is that it's a rather big change, and likely to cause
problems, whereas the problem it corrects is not commonly encountered
(cursor positioning in multi-line overlay before/after-strings).
So I'd like to delay this till after Emacs 22.1. WDYT?
*** emacs/src/keyboard.c.~1.899.~ 2007-04-04 13:05:31.0 -0400
--- emacs/src/keyboard.c2007-04-13 14:04:15.0 -0400
***
*** 2010,2021
&& !NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, &overlay))
&& display_prop_intangible_p (val)
! && (!OVERLAYP (overlay)
! ? get_property_and_range (PT, Qdisplay, &val, &beg, &end, Qnil)
! : (beg = OVERLAY_POSITION (OVERLAY_START (overlay)),
!end = OVERLAY_POSITION (OVERLAY_END (overlay
! && (beg < PT /* && end > PT <- It's always the case. */
! || (beg <= PT && STRINGP (val) && SCHARS (val) == 0)))
{
xassert (end > PT);
SET_PT (PT < last_pt
--- 2010,2022
&& !NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, &overlay))
&& display_prop_intangible_p (val)
! && (OVERLAYP (overlay)
! ? (beg = OVERLAY_POSITION (OVERLAY_START (overlay)),
!end = OVERLAY_POSITION (OVERLAY_END (overlay)),
!beg <= PT)
! : (get_property_and_range (PT, Qdisplay, &val, &beg, &end, Qnil),
!(beg < PT
! || (beg <= PT && STRINGP (val) && SCHARS (val) == 0)
{
xassert (end > PT);
SET_PT (PT < last_pt
*** emacs/src/dispextern.h.~1.225.~ 2007-01-21 13:34:43.0 -0500
--- emacs/src/dispextern.h 2007-04-13 13:42:58.0 -0400
***
*** 2636,2642
struct glyph_row *row_containing_pos P_ ((struct window *, int,
struct glyph_row *,
struct glyph_row *, int));
! int string_buffer_position P_ ((struct window *, Lisp_Object, int));
int line_bottom_y P_ ((struct it *));
int display_prop_intangible_p P_ ((Lisp_Object));
void resize_echo_area_exactly P_ ((void));
--- 2636,2642
struct glyph_row *row_containing_pos P_ ((struct window *, int,
struct glyph_row *,
struct glyph_row *, int));
! int string_buffer_position P_ ((struct window *, Lisp_Object, int,
Lisp_Object *));
int line_bottom_y P_ ((struct it *));
int display_prop_intangible_p P_ ((Lisp_Object));
void resize_echo_area_exactly P_ ((void));
*** emacs/src/xdisp.c.~1.1146.~ 2007-04-12 16:23:44.0 -0400
--- emacs/src/xdisp.c 2007-04-13 14:09:22.0 -0400
***
*** 4425,4434
called asynchronously from note_mouse_highlight. */
int
! string_buffer_position (w, string, around_charpos)
struct window *w;
Lisp_Object string;
int around_charpos;
{
Lisp_Object limit, prop, pos;
const int MAX_DISTANCE = 1000;
--- 4425,4435
called asynchronously from note_mouse_highlight. */
int
! string_buffer_position (w, string, around_charpos, overlay)
struct window *w;
Lisp_Object string;
int around_charpos;
+ Lisp_Object *overlay;
{
Lisp_Object limit, prop, pos;
const int MAX_DISTANCE = 1000;
***
*** 4438,
limit = make_number (min (XINT (pos) + MAX_DISTANCE, ZV));
while (!found && !EQ (pos, limit))
{
! prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) && display_prop_string_p (prop, string))
found = 1;
else
--- 4439,4445
limit = make_number (min (XINT (pos) + MAX_DISTANCE, ZV));
while (!found && !EQ (pos, limit))
{
! prop = get_char_property_and_overlay (pos, Qdisplay, Qnil, overlay);
if (!NILP (prop) && display_prop_string_p (prop, string))
found = 1;
else
***
*** 4451,4457
limit = make_number (max (XINT (pos) - MAX_DISTANCE, BEGV));
while (!found && !EQ (pos, limit))
{
! prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) && display_prop_string_p (prop, string))
found = 1;
else
--- 4452,4458
limit = make_number (max (XINT (pos) - MAX_DISTANCE, BEGV));
while (!found && !EQ (pos, limit))
{
! prop = get_char_property_and_overlay (pos, Qdisplay, Qnil, overlay);
if (!NILP (prop) && display_prop_string_p (prop, string))
Emacs manual node Query Replace should link to node Regexp Replace
Where it says this, it would be good to add a cross reference to node Replace Regexp: "`C-M-%' performs regexp search and replace (`query-replace-regexp'). It works like `replace-regexp' except that it queries like `query-replace'." Otherwise, readers might not know where to find info about `replace-regexp'. In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: Recent messages: (C:\Emacs-22-2007-03-21\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: keymap changes in run-with-timer
Stefan Monnier writes: > > It would probably be good to delay it, but this is not very high priority. > I've added it to the TODO list. Thank you. Lennart Borgman writes: > If you think it is possible to do it now it would be good. I need this for > mumamo too. (Mumamo is here: http://www.emacswiki.org/cgi-bin/wiki/MuMaMo) > > I have a workaround there for this. I call top-level after such > changes (in this case after changing major mode in a timer). Thank you for pointing that out; it works well. It is unfortunate that it prints out "Back to top level" every time. My workaround so far has been to merge the keymap into the current map using define-key, one entry at a time. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: keymap changes in run-with-timer
Stefan Monnier wrote: selecting a keymap (e.g. when changing minor-mode, creating 'keymap overlays, setting overriding-local-map, use-local-map) in a run-with-timer or run-with-idle-timer event doesn't take immediate effect. Consider the following example: (run-with-timer 3 nil '(lambda () (let ((map (make-sparse-keymap))) (define-key map "x" "y") (use-local-map map)) (message "timer fired"))) After the message "timer fired", pressing the "x" key still inserts an "x". Only beginning with the second time it will insert a "y". Indeed it does: the list of active keymaps is computed right before calling `read', i.e. right when going idle at the end of the previous command. It would probably be good to delay it, but this is not very high priority. I've added it to the TODO list. If you think it is possible to do it now it would be good. I need this for mumamo too. (Mumamo is here: http://www.emacswiki.org/cgi-bin/wiki/MuMaMo) I have a workaround there for this. I call top-level after such changes (in this case after changing major mode in a timer). ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: keymap changes in run-with-timer
> selecting a keymap (e.g. when changing minor-mode, creating 'keymap > overlays, setting overriding-local-map, use-local-map) in a > run-with-timer or run-with-idle-timer event doesn't take immediate > effect. > Consider the following example: > (run-with-timer 3 nil '(lambda () > (let ((map (make-sparse-keymap))) >(define-key map "x" "y") >(use-local-map map)) > (message "timer fired"))) > After the message "timer fired", pressing the "x" key still inserts an > "x". Only beginning with the second time it will insert a "y". Indeed it does: the list of active keymaps is computed right before calling `read', i.e. right when going idle at the end of the previous command. It would probably be good to delay it, but this is not very high priority. I've added it to the TODO list. Stefan ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
>> ! (setq globalbind (assq-delete-all (car-safe item) >> globalbind If I read the code correctly, this is dangerous because it may modify the global map. I.e. it should use assq-remove-all or copy-sequence. Stefan ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
> Here is the code that does this: > (define-key org-mode-map [menu-bar headings] 'undefined) > (define-key org-mode-map [menu-bar hide] 'undefined) > (define-key org-mode-map [menu-bar show] 'undefined)) If org-mode-map inherits from outline-mode-map, then it should be OK, although binding them to nil rather than `undefined' should work as well (nil bindings hide other bindings in parent keymaps, but not in lower-level keymaps). Stefan ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
Dear Kenichi, - Kenichi Handa (2007-04-13) wrote:- >> Here is a backtrace of an Emacs crash. One can encounter this often >> by moving cursor over links etc. It only happens when using xft font. > >> Software: GNU Emacs 23.0.0.11 (i686-pc-linux-gnu, X toolkit) of >> 2007-04-11 > >> [2 xft_crash.log ] >> Program received signal SIGSEGV, Segmentation fault. > [...] >> (gdb) bt full >> #0 0x081b3df2 in xftfont_draw (s=0xbfb8f4f0, from=0, to=1, x=387, y=275, >> with_background=0) at xftfont.c:501 >> f = (FRAME_PTR) 0x8c75490 >> face = (struct face *) 0xa9a08c8 >> xftface_info = (struct xftface_info *) 0x0 > > The crash is because xftface_info is NULL, but I can't > reproduce it. My Emacs configuration is almost the same as > yours. > > GNU Emacs 23.0.0.30 (i686-pc-linux-gnu, X toolkit, Xaw3d > scroll bars) of 2007-04-13 on etlken > > I run configure with "--enable-font-backend", and start > emacs with "--enable-font-backend". As you said you are > using Xft font, I think you did the same. Can't you show me > the exact operation to produce that bug by starting Emacs > with "-Q --enable-font-backend -fn SOMEFONT"? > > --- > Kenichi Handa > [EMAIL PROTECTED] It happens usually when there are many links in a buffer such as in ERC or W3M. I can move around mouse in a w3m buffer with tons of links (such as www.6park.com) to catch a crash, which usually happens within a few minutes. I just catch one with 'emacs -Q'. Unfortunately I don't know the exact recipe to trigger a crash. The following can help you see the bug although it won't crash Emacs: o emacs -Q --enable-font-backend -fn SOMEFONT o C-u 3 2 M-x hanoi You should see the frame flickering like TV disturbed by static. Also you can see CPU usage by Xorg and Emacs increased as follows: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 28208 root 15 0 283m 82m 8140 S 69.6 8.4 21:22.20 Xorg 23199 leo 15 0 23284 15m 5964 R 6.5 1.6 0:00.64 emacs I tested this in latest source: GNU Emacs 23.0.0.12 (i686-pc-linux-gnu, X toolkit) of 2007-04-13 on Fedora 6. HTH -- Leo (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
In article <[EMAIL PROTECTED]>, Leo <[EMAIL PROTECTED]> writes: > Here is a backtrace of an Emacs crash. One can encounter this often by > moving cursor over links etc. It only happens when using xft font. > Software: GNU Emacs 23.0.0.11 (i686-pc-linux-gnu, X toolkit) of > 2007-04-11 > [2 xft_crash.log ] > Program received signal SIGSEGV, Segmentation fault. [...] > (gdb) bt full > #0 0x081b3df2 in xftfont_draw (s=0xbfb8f4f0, from=0, to=1, x=387, y=275, > with_background=0) at xftfont.c:501 > f = (FRAME_PTR) 0x8c75490 > face = (struct face *) 0xa9a08c8 > xftface_info = (struct xftface_info *) 0x0 The crash is because xftface_info is NULL, but I can't reproduce it. My Emacs configuration is almost the same as yours. GNU Emacs 23.0.0.30 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-04-13 on etlken I run configure with "--enable-font-backend", and start emacs with "--enable-font-backend". As you said you are using Xft font, I think you did the same. Can't you show me the exact operation to produce that bug by starting Emacs with "-Q --enable-font-backend -fn SOMEFONT"? --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: crash in Fgarbage_collect -> mem_find
Konrad, please see below - can you help? Begin forwarded message: From: [EMAIL PROTECTED] (Kim F. Storm) Date: 13 April 2007 12:25:48 BDT To: David Reitter <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: crash in Fgarbage_collect -> mem_find David Reitter <[EMAIL PROTECTED]> writes: I can't reproduce this. As you might know, this is a Mac/Carbon CVS build (April 4) with patches , none of which should affect garbage collection. I don't have more information, but maybe the stack trace provided is helpful enough. It is only useful in the sense that it tells us that it crashed during garbage collection (in mem_find). This also happened to me last week on GNU/Linux -- so it could be the same bug. Do you remember what you had been doing for the last 5-10 minutes before the crash? -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: crash in Fgarbage_collect -> mem_find
David Reitter <[EMAIL PROTECTED]> writes: > I can't reproduce this. As you might know, this is a Mac/Carbon CVS > build (April 4) with patches , none of which should affect garbage > collection. > I don't have more information, but maybe the stack trace provided is > helpful enough. It is only useful in the sense that it tells us that it crashed during garbage collection (in mem_find). This also happened to me last week on GNU/Linux -- so it could be the same bug. Do you remember what you had been doing for the last 5-10 minutes before the crash? -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
Glenn Morris <[EMAIL PROTECTED]> writes: > Kim F. Storm wrote: > >> Should we add quack.el to the list of packages which we recommend people >> to upgrade when using Emacs 22.1 ? (The list is in etc/NEWS). > > I don't think this was a quack + emacs 22 problem, it was just a > problem in older versions of quack, full stop. Ok. Thanks. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Richard Stallman <[EMAIL PROTECTED]> writes: > At this stage of the release cycle, a grave bug is one that makes Emacs > crash, or causes really bad redisplay behaviour. > > I think redisplay bugs are serious bugs. As you say yourself, what someone _think_ is not a useful argument. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Richard Stallman <[EMAIL PROTECTED]> writes: > > Can you track down the bug report(s) which lead up to the fix I > > installed, so you can confirm that your change also fixes the old > bug(s). > > It must be close to the date in the ChangeLog. > > IIRC, there were quite a lot of test cases - combining before and > after strings as well as compositions, so I really feel bad about > touching this now. > > If you make a change that only takes action in the bug case, > you can be sure you are not breaking any other case. Pardon me, but that's nonsense. How can I be sure that the change "only takes action in the bug case" ? How can I be sure that _any_ change in redisplay will not have unexpected side-effects ... in my experience, most "first attempt" redisplay changes aimed at fixing corner-case bugs have unexpected side-effects. Redisplay is just so damn complicated that I would never use the word "sure" in that context. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
crash in Fgarbage_collect -> mem_find
I can't reproduce this. As you might know, this is a Mac/Carbon CVS build (April 4) with patches , none of which should affect garbage collection. I don't have more information, but maybe the stack trace provided is helpful enough. Begin forwarded message: From: Konrad Podczeck <[EMAIL PROTECTED]> Date: 13 April 2007 10:28:19 BDT To: [EMAIL PROTECTED], Reitter David <[EMAIL PROTECTED]> Subject: Aquamacs crashed Hi David, I had a window splitted in two parts. Mouse-2 clicking on the border between the two subwindows gave a crash, with nigthly build from April 4. Below the crash report. Cheers Konrad Date/Time: 2007-04-13 11:02:17.749 +0200 OS Version: 10.4.9 (Build 8P2137) Report Version: 4 Command: Aquamacs Emacs Path:/Applications/TeX/Aquamacs Emacs.app/Contents/MacOS/ Aquamacs Emacs Parent: WindowServer [60] Version: Aquamacs 1.0rc2, GNU Emacs 22 (1.2a) PID:231 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xe30c Thread 0 Crashed: 0 org.gnu.AquamacsEmacs 0x000cc3f5 mem_find + 47 (alloc.c:3601) 1 org.gnu.AquamacsEmacs 0x000cca4e lisp_free + 44 (alloc.c:893) 2 org.gnu.AquamacsEmacs 0x000d0246 Fgarbage_collect + 1511 (alloc.c:2266) 3 org.gnu.AquamacsEmacs 0x00116fcc Fbyte_code + 7660 (bytecode.c: 714) 4 org.gnu.AquamacsEmacs 0x000e5c23 funcall_lambda + 200 (eval.c: 3189) 5 org.gnu.AquamacsEmacs 0x000e6106 Ffuncall + 452 (eval.c:3054) 6 org.gnu.AquamacsEmacs 0x00116dfe Fbyte_code + 7198 (bytecode.c: 679) 7 org.gnu.AquamacsEmacs 0x000e5c23 funcall_lambda + 200 (eval.c: 3189) 8 org.gnu.AquamacsEmacs 0x000e6106 Ffuncall + 452 (eval.c:3054) 9 org.gnu.AquamacsEmacs 0x00116dfe Fbyte_code + 7198 (bytecode.c: 679) 10 org.gnu.AquamacsEmacs 0x000e5c23 funcall_lambda + 200 (eval.c: 3189) 11 org.gnu.AquamacsEmacs 0x000e6106 Ffuncall + 452 (eval.c:3054) 12 org.gnu.AquamacsEmacs 0x00116dfe Fbyte_code + 7198 (bytecode.c: 679) 13 org.gnu.AquamacsEmacs 0x000e5c23 funcall_lambda + 200 (eval.c: 3189) 14 org.gnu.AquamacsEmacs 0x000e6106 Ffuncall + 452 (eval.c:3054) 15 org.gnu.AquamacsEmacs 0x000e7636 run_hook_with_args + 167 (eval.c:2656) 16 org.gnu.AquamacsEmacs 0x000e62ab Ffuncall + 873 (eval.c:2978) 17 org.gnu.AquamacsEmacs 0x00116dfe Fbyte_code + 7198 (bytecode.c: 679) 18 org.gnu.AquamacsEmacs 0x000e57ee Feval + 1039 (eval.c:2338) 19 org.gnu.AquamacsEmacs 0x000e7d7d internal_lisp_condition_case + 432 (eval.c:1426) 20 org.gnu.AquamacsEmacs 0x00115d34 Fbyte_code + 2900 (bytecode.c: 869) 21 org.gnu.AquamacsEmacs 0x000e5c23 funcall_lambda + 200 (eval.c: 3189) 22 org.gnu.AquamacsEmacs 0x000e6106 Ffuncall + 452 (eval.c:3054) 23 org.gnu.AquamacsEmacs 0x00116dfe Fbyte_code + 7198 (bytecode.c: 679) 24 org.gnu.AquamacsEmacs 0x000e5c23 funcall_lambda + 200 (eval.c: 3189) 25 org.gnu.AquamacsEmacs 0x000e6106 Ffuncall + 452 (eval.c:3054) 26 org.gnu.AquamacsEmacs 0x000e4644 internal_condition_case_2 + 258 (eval.c:1580) 27 org.gnu.AquamacsEmacs 0x000161df safe_call + 145 (xdisp.c:2344) 28 org.gnu.AquamacsEmacs 0x00016216 safe_call1 + 37 (xdisp.c:2362) 29 org.gnu.AquamacsEmacs 0x00016a0b handle_fontified_prop + 262 (xdisp.c:3273) 30 org.gnu.AquamacsEmacs 0x00019667 handle_stop + 116 (xdisp.c:3047) 31 org.gnu.AquamacsEmacs 0x0001c70a next_element_from_buffer + 309 (xdisp.c:6244) 32 org.gnu.AquamacsEmacs 0x0001a8e0 get_next_display_element + 38 (xdisp.c:5501) 33 org.gnu.AquamacsEmacs 0x00023213 display_line + 381 (xdisp.c: 15960) 34 org.gnu.AquamacsEmacs 0x00024505 try_window + 164 (xdisp.c:13563) 35 org.gnu.AquamacsEmacs 0x0002c7dd redisplay_window + 7780 (xdisp.c:13187) 36 org.gnu.AquamacsEmacs 0x0002e644 redisplay_window_0 + 44 (xdisp.c:11784) 37 org.gnu.AquamacsEmacs 0x000e41e7 internal_condition_case_1 + 251 (eval.c:1529) 38 org.gnu.AquamacsEmacs 0x0002212d redisplay_windows + 137 (xdisp.c:11763) 39 org.gnu.AquamacsEmacs 0x0003038c redisplay_internal + 3578 (xdisp.c:11323) 40 org.gnu.AquamacsEmacs 0x000309e7 redisplay_preserve_echo_area + 110 (xdisp.c:11574) 41 org.gnu.AquamacsEmacs 0x00082d1a read_char + 1799 (keyboard.c: 2675) 42 org.gnu.AquamacsEmacs 0x00084b65 read_key_sequence + 2118 (keyboard.c:9147) 43 org.gnu.AquamacsEmacs 0x000863d1 command_loop_1 + 475 (keyboard.c:1621) 44 org.gnu.AquamacsEmacs 0x000e4526 internal_condition_case + 245 (eval.c:1481) 45 org.gnu.AquamacsEmacs 0x00078b09 command_loop_2 + 68 (keyboard.c:1333) 46 org.gnu.AquamacsEmacs 0x000e4417 internal_catch + 171 (eval.c: 1222) 47 org.gnu.AquamacsEmacs 0x000788e3 command_loop + 170 (keyboard.c:1312) 48 org.gnu.AquamacsEmacs 0x00078997 recursive_edit_1 + 140 (keyboard.c:1009) 49 org.gnu.AquamacsEmacs 0x00078a86 Frecursive_edit + 139 (keyboard.c:1071) 50 org.gnu.AquamacsEmacs 0x00077c6b main + 2311 (emacs.c:1765) 51 org.g
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
- Jan Djärv (2007-04-13) wrote:- >> Software: GNU Emacs 23.0.0.11 (i686-pc-linux-gnu, X toolkit) of >> 2007-04-11 >> >> Here is a backtrace of an Emacs crash. One can encounter this often by >> moving cursor over links etc. It only happens when using xft font. >> > > If you are using the unicode2 branch, please put that in the subject. > If you are not using that, please try that branch instead, it has had > a lot more development. > > Jan D. I just changed the subject. The crash happens with a fresh checkout of emacs-unicode-2 branch the day before. Best, -- Leo (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: corrected report for Emacs crash on WIN32 with slime
If slime is up and running and M-x slime is called again you are asked if
you
want to start an addtional inferior lisp. If this question is answered with
n
Emacs will crash. The action that triggers the crash is (kill-buffer "
*cl-connection*")
Can you reproduce the bug with the attached (100% unreliable) patch?
*** buffer.h.~1.109.~ Tue Jan 23 06:41:24 2007
--- buffer.hFri Apr 13 10:00:56 2007
***
*** 518,523
--- 518,519
/* Set nonzero whenever the narrowing is changed in this buffer. */
int clip_changed;
+ /* Set nonzero when kill_buffer is in progress for this buffer. */
+ int kill_buffer_in_progress;
+
/* If the long line scan cache is enabled (i.e. the buffer-local
variable cache-long-line-scans is non-nil), newline_cache
points to the newline cache, and width_run_cache points to the
*** buffer.c.~1.525.~ Mon Apr 2 07:45:22 2007
--- buffer.cFri Apr 13 10:20:08 2007
***
*** 693,698
--- 693,699
b->last_window_start = 1;
/* It is more conservative to start out "changed" than "unchanged". */
b->clip_changed = 0;
+ b->kill_buffer_in_progress = 0;
b->prevent_redisplay_optimizations_p = 1;
b->backed_up = Qnil;
b->auto_save_modified = 0;
***
*** 1361,1369
b = XBUFFER (buf);
! /* Avoid trouble for buffer already dead. */
! if (NILP (b->name))
return Qnil;
/* Query if the buffer is still modified. */
if (INTERACTIVE && !NILP (b->filename)
--- 1362,1371
b = XBUFFER (buf);
! /* Avoid trouble for buffer already dead or about being killed. */
! if ((NILP (b->name)) || (b->kill_buffer_in_progress))
return Qnil;
+ b->kill_buffer_in_progress = 1;
/* Query if the buffer is still modified. */
if (INTERACTIVE && !NILP (b->filename)
***
*** 1374,1380
b->name, make_number (0)));
UNGCPRO;
if (NILP (tem))
! return Qnil;
}
/* Run hooks with the buffer to be killed the current buffer. */
--- 1376,1385
b->name, make_number (0)));
UNGCPRO;
if (NILP (tem))
! {
! b->kill_buffer_in_progress = 0;
! return Qnil;
! }
}
/* Run hooks with the buffer to be killed the current buffer. */
***
*** 1390,1396
arglist[0] = Qkill_buffer_query_functions;
tem = Frun_hook_with_args_until_failure (1, arglist);
if (NILP (tem))
! return unbind_to (count, Qnil);
/* Then run the hooks. */
Frun_hooks (1, &Qkill_buffer_hook);
--- 1395,1404
arglist[0] = Qkill_buffer_query_functions;
tem = Frun_hook_with_args_until_failure (1, arglist);
if (NILP (tem))
! {
! b->kill_buffer_in_progress = 0;
! return unbind_to (count, Qnil);
! }
/* Then run the hooks. */
Frun_hooks (1, &Qkill_buffer_hook);
***
*** 1403,1412
/* Don't kill the minibuffer now current. */
if (EQ (buf, XWINDOW (minibuf_window)->buffer))
! return Qnil;
if (NILP (b->name))
! return Qnil;
/* When we kill a base buffer, kill all its indirect buffers.
We do it at this stage so nothing terrible happens if they
--- 1411,1426
/* Don't kill the minibuffer now current. */
if (EQ (buf, XWINDOW (minibuf_window)->buffer))
! {
! b->kill_buffer_in_progress = 0;
! return Qnil;
! }
if (NILP (b->name))
! {
! b->kill_buffer_in_progress = 0;
! return Qnil;
! }
/* When we kill a base buffer, kill all its indirect buffers.
We do it at this stage so nothing terrible happens if they
***
*** 1438,1444
tem = Fother_buffer (buf, Qnil, Qnil);
Fset_buffer (tem);
if (b == current_buffer)
! return Qnil;
}
/* Notice if the buffer to kill is the sole visible buffer
--- 1452,1461
tem = Fother_buffer (buf, Qnil, Qnil);
Fset_buffer (tem);
if (b == current_buffer)
! {
! b->kill_buffer_in_progress = 0;
! return Qnil;
! }
}
/* Notice if the buffer to kill is the sole visible buffer
***
*** 1448,1454
{
tem = Fother_buffer (buf, Qnil, Qnil);
if (EQ (buf, tem))
! return Qnil;
}
/* Now there is no question: we can kill the buffer. */
--- 1465,1474
{
tem = Fother_buffer (buf, Qnil, Qnil);
if (EQ (buf, tem))
! {
! b->kill_buffer_in_progress = 0;
! return Qnil;
! }
}
/* Now there is no question: we can kill the buffer. */
***
*** 1520,1525
--- 1540,1546
reset_buffer_local_variables (b, 1);
b->name = Qnil;
+ b->kill_buffer_in_progress = 0;
BLOCK_INPUT;
if (! b->base_buffer)
___
emacs-pretest-bug maili
keymap changes in run-with-timer
Hello, selecting a keymap (e.g. when changing minor-mode, creating 'keymap overlays, setting overriding-local-map, use-local-map) in a run-with-timer or run-with-idle-timer event doesn't take immediate effect. Consider the following example: (run-with-timer 3 nil '(lambda () (let ((map (make-sparse-keymap))) (define-key map "x" "y") (use-local-map map)) (message "timer fired"))) After the message "timer fired", pressing the "x" key still inserts an "x". Only beginning with the second time it will insert a "y". Changing the /content/ of a keymap like this: (run-with-timer 3 nil '(lambda () (define-key (current-local-map) "x" "y") (message "timer fired"))) works immediately, though. regards, Nikolaj Schumacher In GNU Emacs 22.0.97.2 (i386-apple-darwin8.9.1, Carbon Version 1.6.0) of 2007-04-05 on wednesday Windowing system distributor `Apple Inc.', version 10.4.9 configured using `configure '--prefix=/Applications/Emacs.app/Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/Applications/Emacs.app/Contents/MacOS/libexec' 'CFLAGS=-arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -DUSE_ATSUI'' ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-xft] Segmentation fault 0x081b3df2 in xftfont_draw
Leo skrev: Hello, Software: GNU Emacs 23.0.0.11 (i686-pc-linux-gnu, X toolkit) of 2007-04-11 Here is a backtrace of an Emacs crash. One can encounter this often by moving cursor over links etc. It only happens when using xft font. If you are using the unicode2 branch, please put that in the subject. If you are not using that, please try that branch instead, it has had a lot more development. Jan D. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
