Redisplay crash

Redisplay crash

[Stefan Monnier]

>>> Current HEAD is rock-solid for normal use, and I don't think it will
>>> can be much better in that respect (but we should try!).

>> This may be a false warning for HEAD (I run my own branch which has a fair
>> number of redisplay changes), but just in case:

>> I've had several crashes recently related to i-search faces, and haven't been
>> able to track down the cause; it appears that the face cache ids are being
>> used even after the face cache has been cleared.

> In emacs-unicode, I also met the similar bug.  Emacs crashed
> at the end of get_glyph_face_and_encoding.  In this
> function, FACE_FROM_ID (f, glyph->face_id) returned NULL,
> thus, the macro call PREPARE_FACE_FOR_DISPLAY at the end led
> to the crash.  Though, this happens very very rarely.

I've had such problems in the past.
There was a discussion about it with Gerd which led to

2002-08-27  Gerd Moellmann  <gerd.moellmann@t-online.de>

	* xdisp.c (redisplay_updating_p): Variable removed.
	(inhibit_free_realized_faces, Qinhibit_free_realized_faces):
	New variables.
	(init_iterator): Don't free realized faces if
	inhibit_free_realized_faces is set.
	(redisplay_internal): Bind Qinhibit_free_realized_faces to nil.
	(syms_of_xdisp): DEFVAR_BOOL inhibit-free-realized-faces,
	initialize Qinhibit_free_realized_faces.

	* dispextern.h (PRODUCE_GLYPHS): Set inhibit_free_realized_faces
	when iterator is adding glyphs to a glyph matrix.

I can't find trace of this discussion, tho.
I've always had the impression that the above patch didn't really fix the
problem, tho it made it less frequent, so maybe it only hid the problem
more than fix it, I don't know.  In any case I figure maybe you'd like
to know.


        Stefan

Re: Redisplay crash

[Kenichi Handa]

In article <87r7uyfoz9.fsf-monnier+emacs@alfajor.local>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
> There was a discussion about it with Gerd which led to

> 2002-08-27  Gerd Moellmann  <gerd.moellmann@t-online.de>

> 	* xdisp.c (redisplay_updating_p): Variable removed.
> 	(inhibit_free_realized_faces, Qinhibit_free_realized_faces):
> 	New variables.
> 	(init_iterator): Don't free realized faces if
> 	inhibit_free_realized_faces is set.
> 	(redisplay_internal): Bind Qinhibit_free_realized_faces to nil.
> 	(syms_of_xdisp): DEFVAR_BOOL inhibit-free-realized-faces,
> 	initialize Qinhibit_free_realized_faces.

> 	* dispextern.h (PRODUCE_GLYPHS): Set inhibit_free_realized_faces
> 	when iterator is adding glyphs to a glyph matrix.

> I can't find trace of this discussion, tho.
> I've always had the impression that the above patch didn't really fix the
> problem, tho it made it less frequent, so maybe it only hid the problem
> more than fix it, I don't know.  In any case I figure maybe you'd like
> to know.

Thank you for the info.  I found at least one way to crash
Emacs constantly.

At first, evaluate this in *scratch* buffer.

(put-text-property 2 3 'display '(when (clear-face-cache t)))

Then, type C-h h C-x C-k (i.e. view HELLO file and kill that
buffer).

Then, Emacs crashes in get_next_display_element at:

      /* Adjust face id for a multibyte character.  There are no
         multibyte character in unibyte text.  */
      if (it->multibyte_p
	  && success_p
	  && FRAME_WINDOW_P (it->f))
	{
	  struct face *face = FACE_FROM_ID (it->f, it->face_id);
here->	  it->face_id = FACE_FOR_CHAR (it->f, face, it->c);
	}

because FACE_FROM_ID returns NULL.

But, it seems that this is a different bug.

---
Ken'ichi HANDA
handa@m17n.org

Re: Redisplay crash

[Richard Stallman]

    I've had such problems in the past.
    There was a discussion about it with Gerd which led to

    2002-08-27  Gerd Moellmann  <gerd.moellmann@t-online.de>

Perhaps we need to record history information about occurrences
within redisplay, so that after it crashes we can investigate
what happened without needing to find a reproducible test case.

Re: Redisplay crash

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I've had such problems in the past.
>     There was a discussion about it with Gerd which led to
> 
>     2002-08-27  Gerd Moellmann  <gerd.moellmann@t-online.de>
> 
> Perhaps we need to record history information about occurrences
> within redisplay, so that after it crashes we can investigate
> what happened without needing to find a reproducible test case.

I don't think it will be worth the efforts.

There is just so much going on during redisplay, that it is almost
impossible to know what and how much information to put into the
history.  I have used various methods of collecting history during
redisplay to track down display errors, even when doing a targeted
information collection, it is very difficult to actually use that
history to find bugs.

It is always better to have a specific test case and debug the code to
find the cause of the error.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Redisplay crash

[Richard Stallman]

    > Perhaps we need to record history information about occurrences
    > within redisplay, so that after it crashes we can investigate
    > what happened without needing to find a reproducible test case.

    I don't think it will be worth the efforts.

    It is always better to have a specific test case and debug the code to
    find the cause of the error.

It is surely better to have a specific test case; the problem is
that sometimes we don't have one and nobody can find one.

Re: Redisplay crash

[Piet van Oostrum]

>>>>> Kenichi Handa <handa@m17n.org> (KH) wrote:

KH> Thank you for the info.  I found at least one way to crash
KH> Emacs constantly.

KH> At first, evaluate this in *scratch* buffer.

KH> (put-text-property 2 3 'display '(when (clear-face-cache t)))

KH> Then, type C-h h C-x C-k (i.e. view HELLO file and kill that
KH> buffer).

For me, on Mac OS X, the first step alone will already crash emacs.
This is the backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00021054 in get_next_display_element (it=0xbfffd430) at xdisp.c:4948
4948              it->face_id = FACE_FOR_CHAR (it->f, face, it->c);
(gdb) bt
#0  0x00021054 in get_next_display_element (it=0xbfffd430) at xdisp.c:4948
#1  0x00021970 in next_element_from_buffer (it=0xbfffd430) at xdisp.c:5436
#2  0x00020cc0 in get_next_display_element (it=0xbfffd430) at xdisp.c:4787
#3  0x00031520 in display_line (it=0xbfffd430) at xdisp.c:14411
#4  0x0002d6c4 in try_window (window=10719952, pos={charpos = 1, bytepos = 1}) at xdisp.c:12140
#5  0x0002c820 in redisplay_window (window=-2110188656, just_this_one_p=0) at xdisp.c:11783
#6  0x00029978 in redisplay_window_0 (window=10719952) at xdisp.c:10538
#7  0x000e0cc0 in internal_condition_case_1 (bfun=0x2993c <redisplay_window_0>, arg=-2110188656, handlers=-1604078312, hfun=0x29908 <redisplay_window_error>) at eval.c:1374
#8  0x000298e0 in redisplay_windows (window=0) at xdisp.c:10517
#9  0x000298c0 in redisplay_windows (window=0) at xdisp.c:10511
#10 0x00028f20 in redisplay_internal (preserve_echo_area=10719952) at xdisp.c:10102
#11 0x0007e24c in read_char (commandflag=1, nmaps=3, maps=0xbfffecc0, prev_event=595592192, used_mouse_menu=0xbfffedc4) at keyboard.c:2472
#12 0x0008686c in read_key_sequence (keybuf=0x34b6f4, bufsize=3505968, prompt=-2110188656, dont_downcase_last=-1821406164, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8770
#13 0x0007c01c in command_loop_1 () at keyboard.c:1476
#14 0x000e0b54 in internal_condition_case (bfun=0x7bb60 <command_loop_1>, handlers=595637240, hfun=0x7b560 <cmd_error>) at eval.c:1333
#15 0x0007b988 in command_loop_2 () at keyboard.c:1264
#16 0x000e05bc in internal_catch (tag=10719952, func=0x7b948 <command_loop_2>, arg=595592192) at eval.c:1094
#17 0x0007b8e0 in command_loop () at keyboard.c:1243
#18 0x0007b2fc in recursive_edit_1 () at keyboard.c:959
#19 0x0007b484 in Frecursive_edit () at keyboard.c:1015
#20 0x00079fac in main (argc=3510216, argv=0x3565ac) at emacs.c:1692
(gdb) quit

-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: Redisplay crash

[Richard Stallman]

    (put-text-property 2 3 'display '(when (clear-face-cache t)))

    Then, type C-h h C-x C-k (i.e. view HELLO file and kill that
    buffer).

    Then, Emacs crashes in get_next_display_element at:

Has anyone investigated this bug?

Redisplay crash

[Romain Francoise]

Running Emacs CVS from a few hours ago, I get a segmentation fault every
time I try to enter a group in Gnus (using emacs -nw, I didn't try in
X11).  It's very reproducible.  I last updated before that in October
2004 so the bug might not be recent.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1485880672 (LWP 8907)]
0xa7883051 in mallopt () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xa7883051 in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1  0xa7881d65 in realloc () from /lib/tls/i686/cmov/libc.so.6
#2  0x081685ab in emacs_blocked_realloc (ptr=0x958d590, size=388)
    at alloc.c:1279
#3  0xa7881c9c in realloc () from /lib/tls/i686/cmov/libc.so.6
#4  0x08168123 in xrealloc (block=0x6d353358, size=25) at alloc.c:758
#5  0x080e0e53 in encode_terminal_code (src=0xa76f0f08, src_len=156816800,
    coding=0x8323200) at term.c:904
#6  0x080e2c9c in write_glyphs (string=0xa76f0ea8, len=43) at term.c:970
#7  0x080888b8 in update_frame_line (f=0x8341060, vpos=1) at dispnew.c:5656
#8  0x08088c88 in update_frame (f=0x8341060, force_p=0, inhibit_hairy_id_p=0)
    at dispnew.c:5154
#9  0x080aa922 in redisplay_internal (preserve_echo_area=1832203096)
    at xdisp.c:10288
#10 0x08124535 in read_char (commandflag=1, nmaps=4, maps=0xafffed70,
    prev_event=137568273, used_mouse_menu=0xafffedb8) at keyboard.c:2537
#11 0x081271c5 in read_key_sequence (keybuf=0xafffeed0, bufsize=30,
    prompt=137568273, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:8818
#12 0x08128bb7 in command_loop_1 () at keyboard.c:1531
#13 0x0817e2ba in internal_condition_case (bfun=0x8128a10 <command_loop_1>,
    handlers=137629265, hfun=0x8122590 <cmd_error>) at eval.c:1385
#14 0x0811caa6 in command_loop_2 () at keyboard.c:1312
#15 0x0817e1ba in internal_catch (tag=1832203096,
    func=0x811ca80 <command_loop_2>, arg=137568273) at eval.c:1144
#16 0x0811c887 in command_loop () at keyboard.c:1291
#17 0x0811c920 in recursive_edit_1 () at keyboard.c:984
#18 0x0811ca3a in Frecursive_edit () at keyboard.c:1045
#19 0x0811bd03 in main (argc=2, argv=0xaffff4d4) at emacs.c:1763
(gdb)

-- 
Romain Francoise <romain@orebokech.com> | I'm going out for a little
it's a miracle -- http://orebokech.com/ | drive, and it may be the last
                                        | time you see me alive.

Re: Redisplay crash

[Kenichi Handa]

In article <87llbal35x.fsf@orebokech.com>, Romain Francoise <romain@orebokech.com> writes:

> Running Emacs CVS from a few hours ago, I get a segmentation fault every
> time I try to enter a group in Gnus (using emacs -nw, I didn't try in
> X11).  It's very reproducible.  I last updated before that in October
> 2004 so the bug might not be recent.

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1485880672 (LWP 8907)]
> 0xa7883051 in mallopt () from /lib/tls/i686/cmov/libc.so.6
> (gdb) bt
> #0  0xa7883051 in mallopt () from /lib/tls/i686/cmov/libc.so.6
> #1  0xa7881d65 in realloc () from /lib/tls/i686/cmov/libc.so.6
> #2  0x081685ab in emacs_blocked_realloc (ptr=0x958d590, size=388)
>     at alloc.c:1279
> #3  0xa7881c9c in realloc () from /lib/tls/i686/cmov/libc.so.6
> #4  0x08168123 in xrealloc (block=0x6d353358, size=25) at alloc.c:758
> #5  0x080e0e53 in encode_terminal_code (src=0xa76f0f08, src_len=156816800,
>     coding=0x8323200) at term.c:904
> #6  0x080e2c9c in write_glyphs (string=0xa76f0ea8, len=43) at term.c:970

I can't reproduce this bug, but I seems that my change to
encode_terminal_code on 2004-11-30 is the cause.  At least
the argument `src_len' of encode_terminal_code has strange
value in your backtrace.  Could you try to find out why it
has that value by debugger?

---
Ken'ichi HANDA
handa@m17n.org

Re: Redisplay crash

[Romain Francoise]

Kenichi Handa <handa@m17n.org> writes:

> I can't reproduce this bug, but I seems that my change to
> encode_terminal_code on 2004-11-30 is the cause.

Indeed if I revert term.c to revision 1.156, the problem goes away.

> At least the argument `src_len' of encode_terminal_code has strange
> value in your backtrace.  Could you try to find out why it has that
> value by debugger?

I tried but that value must come from stack corruption or some other
strangeness since in my tests, it always has reasonable values.. and
when the segfault occurs, it has the value 3 (in the one case I used to
reproduce the bug: entering gnu.emacs.gnus).

I will investigate further, any clues are welcome.

Also, I may be wrong, but it looks like the memory allocated in
encode_terminal_code is never freed.  Or is it GC'ed?

-- 
Romain Francoise <romain@orebokech.com> | There's no stronger wind than
it's a miracle -- http://orebokech.com/ | the one that blows down a
                                        | lonesome railroad line.

Re: Redisplay crash

[Romain Francoise]

Romain Francoise <romain@orebokech.com> writes:

> I will investigate further, any clues are welcome.

After further investigation... the problem lies on line 872 of term.c, I
think the size computation is backwards.  In my tests, this code makes
the buffer shrink to something like 16 bytes.  The following bcopy call
then writes way more than that, overflowing the buffer and overwriting
the libc memory block pointers and thus making the next call to xrealloc
(needed because the size was set to something too small for what we have
to decode) fail.

That test is probably meant to check if we have to grow the buffer, not
shrink it, so reversing it appears to be what was intended.  At least it
fixes the crash for me, I've been running with that patch for some time
with success so far.  What do you think?

2005-01-05  Romain Francoise  <romain@orebokech.com>

	* term.c (encode_terminal_code): Fix buffer size computation.

Index: term.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/term.c,v
retrieving revision 1.159
diff -c -r1.159 term.c
*** term.c	12 Dec 2004 03:31:00 -0000	1.159
--- term.c	5 Jan 2005 20:38:47 -0000
***************
*** 1,5 ****
  /* Terminal control module for terminals described by TERMCAP
!    Copyright (C) 1985, 86, 87, 93, 94, 95, 98, 2000, 2001, 2002
     Free Software Foundation, Inc.
  
  This file is part of GNU Emacs.
--- 1,5 ----
  /* Terminal control module for terminals described by TERMCAP
!    Copyright (C) 1985, 86, 87, 93, 94, 95, 98, 2000, 2001, 2002, 2005
     Free Software Foundation, Inc.
  
  This file is part of GNU Emacs.
***************
*** 869,875 ****
  		  if (! STRING_MULTIBYTE (string))
  		    string = string_to_multibyte (string);
  		  nbytes = buf - encode_terminal_buf;
! 		  if (nbytes + SBYTES (string) < encode_terminal_bufsize)
  		    {
  		      encode_terminal_bufsize = nbytes + SBYTES (string);
  		      encode_terminal_buf = xrealloc (encode_terminal_buf,
--- 869,875 ----
  		  if (! STRING_MULTIBYTE (string))
  		    string = string_to_multibyte (string);
  		  nbytes = buf - encode_terminal_buf;
! 		  if (encode_terminal_bufsize < nbytes + SBYTES (string))
  		    {
  		      encode_terminal_bufsize = nbytes + SBYTES (string);
  		      encode_terminal_buf = xrealloc (encode_terminal_buf,

-- 
Romain Francoise <romain@orebokech.com> | I just thought I'd go out
it's a miracle -- http://orebokech.com/ | with a little bit more style.

Re: Redisplay crash

[Romain Francoise]

Romain Francoise <romain@orebokech.com> writes:

> The following bcopy call then writes way more than that, overflowing
> the buffer and overwriting the libc memory block pointers and thus
> making the next call to xrealloc (needed because the size was set to
> something too small for what we have to decode) fail.

Forget that, it's probably not the bcopy call that's doing it since it
doesn't write more than SBYTES (string) bytes.  But the pointers *do*
get hosed one way or another...

-- 
Romain Francoise <romain@orebokech.com> | Why did you kill that poor
it's a miracle -- http://orebokech.com/ | old man, melody? She said,
                                        | "He was never good to me"

Re: Redisplay crash

[Kenichi Handa]

In article <878y77mwif.fsf@orebokech.com>, Romain Francoise <romain@orebokech.com> writes:
> After further investigation... the problem lies on line 872 of term.c, I
> think the size computation is backwards.

Ahhhh!  Right.  Thank you for finding that silly bug.

> 2005-01-05  Romain Francoise  <romain@orebokech.com>

> 	* term.c (encode_terminal_code): Fix buffer size computation.

I've just installed your fix.

---
Ken'ichi HANDA
handa@m17n.org