bug#5984: Crash displaying composed characters

bug#5984: Crash displaying composed characters

[Juanma Barranquero]

Package: emacs
Version: 24.0.50

Discussed in the thread of bug#5973

    Juanma




Breakpoint 1, w32_abort () at w32fns.c:7349
7349      button = MessageBox (NULL,
(gdb) bt
#0  w32_abort () at w32fns.c:7349
#1  0x012be7c9 in temp_set_point_both (buffer=0x34b6e00, charpos=32,
bytepos=33) at intervals.c:1944
#2  0x012772b4 in autocmp_chars (cft_element=50852182, charpos=29,
bytepos=29, limit=31, win=0x350b400, face=0x4e8c100, string=49838082)
   at composite.c:1002
#3  0x01278591 in composition_reseat_it (cmp_it=0x88db74, charpos=29,
bytepos=29, endpos=32, w=0x350b400, face=0x4e8c100, string=49838082)
   at composite.c:1147
#4  0x01069fcb in next_element_from_buffer (it=0x88d6f8) at xdisp.c:6834
#5  0x01066642 in get_next_display_element (it=0x88d6f8) at xdisp.c:5828
#6  0x0106a6ff in move_it_in_display_line_to (it=0x88d6f8,
to_charpos=32, to_x=-1, op=MOVE_TO_POS) at xdisp.c:7087
#7  0x0106bca3 in move_it_to (it=0x88d6f8, to_charpos=32, to_x=-1,
to_y=-1, to_vpos=-1, op=8) at xdisp.c:7588
#8  0x01071704 in resize_mini_window (w=0x350b400, exact_p=0) at xdisp.c:9083
#9  0x01070ec4 in display_echo_area_1 (a1=55620608, a2=49838082, a3=0,
a4=0) at xdisp.c:8946
#10 0x0106fa35 in with_echo_area_buffer (w=0x350b400, which=0,
fn=0x1070e9e <display_echo_area_1>, a1=55620608, a2=49838082, a3=0,
a4=0)
   at xdisp.c:8733
#11 0x01070e6c in display_echo_area (w=0x350b400) at xdisp.c:8914
#12 0x01072a21 in echo_area_display (update_frame_p=1) at xdisp.c:9512
#13 0x0106e656 in message3_nolog (m=85027169, nbytes=32, multibyte=1)
at xdisp.c:8409
#14 0x0106e135 in message3 (m=85027169, nbytes=32, multibyte=1) at xdisp.c:8344
#15 0x01224ccc in Fmessage (nargs=2, args=0x88e1c4) at editfns.c:3408
#16 0x0103c58e in Ffuncall (nargs=3, args=0x88e1c0) at eval.c:3005
#17 0x011ef7d8 in Fbyte_code (bytestr=82551569, vector=51162213,
maxdepth=12) at bytecode.c:680
#18 0x0103d67c in funcall_lambda (fun=51162085, nargs=0,
arg_vector=0x88e474) at eval.c:3211
#19 0x0103ce9c in Ffuncall (nargs=1, args=0x88e470) at eval.c:3070
#20 0x011ef7d8 in Fbyte_code (bytestr=81809201, vector=81013253,
maxdepth=88) at bytecode.c:680
#21 0x0103d67c in funcall_lambda (fun=50937029, nargs=0,
arg_vector=0x88e774) at eval.c:3211
#22 0x0103ce9c in Ffuncall (nargs=1, args=0x88e770) at eval.c:3070
#23 0x011ef7d8 in Fbyte_code (bytestr=81802801, vector=82790149,
maxdepth=20) at bytecode.c:680
#24 0x0103d67c in funcall_lambda (fun=50937349, nargs=3,
arg_vector=0x88ea34) at eval.c:3211
#25 0x0103ce9c in Ffuncall (nargs=4, args=0x88ea30) at eval.c:3070
#26 0x011ef7d8 in Fbyte_code (bytestr=81805217, vector=84959173,
maxdepth=16) at bytecode.c:680
#27 0x0103d67c in funcall_lambda (fun=50938597, nargs=3,
arg_vector=0x88ece4) at eval.c:3211
#28 0x0103ce9c in Ffuncall (nargs=4, args=0x88ece0) at eval.c:3070
#29 0x011ef7d8 in Fbyte_code (bytestr=81009409, vector=50466597,
maxdepth=16) at bytecode.c:680
#30 0x0103d67c in funcall_lambda (fun=50464837, nargs=0,
arg_vector=0x88ef94) at eval.c:3211
#31 0x0103ce9c in Ffuncall (nargs=1, args=0x88ef90) at eval.c:3070
#32 0x011ef7d8 in Fbyte_code (bytestr=81523921, vector=82526981,
maxdepth=64) at bytecode.c:680
#33 0x0103d67c in funcall_lambda (fun=50940261, nargs=3,
arg_vector=0x88f274) at eval.c:3211
#34 0x0103ce9c in Ffuncall (nargs=4, args=0x88f270) at eval.c:3070
#35 0x011ef7d8 in Fbyte_code (bytestr=81523921, vector=82526981,
maxdepth=64) at bytecode.c:680
#36 0x0103d67c in funcall_lambda (fun=50940261, nargs=3,
arg_vector=0x88f554) at eval.c:3211
#37 0x0103ce9c in Ffuncall (nargs=4, args=0x88f550) at eval.c:3070
#38 0x011ef7d8 in Fbyte_code (bytestr=81009361, vector=82654149,
maxdepth=20) at bytecode.c:680
#39 0x0103d67c in funcall_lambda (fun=50466757, nargs=2,
arg_vector=0x88f864) at eval.c:3211
#40 0x0103ce9c in Ffuncall (nargs=3, args=0x88f860) at eval.c:3070
#41 0x011f4c10 in Fcall_interactively (function=50004498,
record_flag=49838082, keys=49859333) at callint.c:869
#42 0x0103ca53 in Ffuncall (nargs=4, args=0x88fb30) at eval.c:3030
#43 0x0103bf25 in call3 (fn=49990114, arg1=50004498, arg2=49838082,
arg3=49838082) at eval.c:2850
#44 0x010222a9 in Fcommand_execute (cmd=50004498,
record_flag=49838082, keys=49838082, special=49838082) at
keyboard.c:10345
#45 0x01008862 in command_loop_1 () at keyboard.c:1756
#46 0x010389aa in internal_condition_case (bfun=0x10072be
<command_loop_1>, handlers=49894618, hfun=0x10069e5 <cmd_error>) at
eval.c:1490
#47 0x01006ebf in command_loop_2 () at keyboard.c:1356
#48 0x0103842c in internal_catch (tag=49893810, func=0x1006e9a
<command_loop_2>, arg=49838082) at eval.c:1226
#49 0x01006e78 in command_loop () at keyboard.c:1335
#50 0x010060f0 in recursive_edit_1 () at keyboard.c:950
#51 0x0100660b in Frecursive_edit () at keyboard.c:1012
#52 0x01002a95 in main (argc=1, argv=0xbe2b58) at emacs.c:1784

Lisp Backtrace:
"message" (0x88e1c4)
"edebug-previous-result" (0x88e474)
"edebug-display" (0x88e774)
"edebug-debugger" (0x88ea34)
"edebug-after" (0x88ece4)
0x3020845 PVEC_COMPILED
"edebug-enter" (0x88f274)
"edebug-enter" (0x88f554)
"narrow-to-region" (0x88f864)
"call-interactively" (0x88fb34)
(gdb)

bug#5984: Crash displaying composed characters

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 20 Apr 2010 15:42:16 +0200
> Cc: 
> 
> Package: emacs
> Version: 24.0.50
> 
> Discussed in the thread of bug#5973
> 
>     Juanma
> 
> 
> 
> 
> Breakpoint 1, w32_abort () at w32fns.c:7349
> 7349      button = MessageBox (NULL,
> (gdb) bt
> #0  w32_abort () at w32fns.c:7349
> #1  0x012be7c9 in temp_set_point_both (buffer=0x34b6e00, charpos=32,
> bytepos=33) at intervals.c:1944
> #2  0x012772b4 in autocmp_chars (cft_element=50852182, charpos=29,
> bytepos=29, limit=31, win=0x350b400, face=0x4e8c100, string=49838082)
>    at composite.c:1002
> #3  0x01278591 in composition_reseat_it (cmp_it=0x88db74, charpos=29,
> bytepos=29, endpos=32, w=0x350b400, face=0x4e8c100, string=49838082)
>    at composite.c:1147
> #4  0x01069fcb in next_element_from_buffer (it=0x88d6f8) at xdisp.c:6834
> #5  0x01066642 in get_next_display_element (it=0x88d6f8) at xdisp.c:5828

I see the same crash in Emacs 23.1.96, which means two things:

  . It has nothing to do with bidi code (phew!)

  . It is much more urgent to fix

bug#5984: Crash displaying composed characters

[Juanma Barranquero]

severity 5984 serious
quit


> I see the same crash in Emacs 23.1.96, which means two things:

What's the command to add new version tags to a bug?

    Juanma

bug#5984: Crash displaying composed characters

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 20 Apr 2010 17:48:21 +0200
> Cc: 5984@debbugs.gnu.org, control@debbugs.gnu.org
> 
> What's the command to add new version tags to a bug?

I don't know.  Glenn, can you help, please?

bug#5984: Crash displaying composed characters

[Eli Zaretskii]

> Date: Tue, 20 Apr 2010 18:06:58 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 5984@debbugs.gnu.org
> 
> > From: Juanma Barranquero <lekktu@gmail.com>
> > Date: Tue, 20 Apr 2010 15:42:16 +0200
> > Cc: 
> > 
> > Package: emacs
> > Version: 24.0.50
> > 
> > Discussed in the thread of bug#5973
> > 
> >     Juanma
> > 
> > 
> > 
> > 
> > Breakpoint 1, w32_abort () at w32fns.c:7349
> > 7349      button = MessageBox (NULL,
> > (gdb) bt
> > #0  w32_abort () at w32fns.c:7349
> > #1  0x012be7c9 in temp_set_point_both (buffer=0x34b6e00, charpos=32,
> > bytepos=33) at intervals.c:1944
> > #2  0x012772b4 in autocmp_chars (cft_element=50852182, charpos=29,
> > bytepos=29, limit=31, win=0x350b400, face=0x4e8c100, string=49838082)
> >    at composite.c:1002
> > #3  0x01278591 in composition_reseat_it (cmp_it=0x88db74, charpos=29,
> > bytepos=29, endpos=32, w=0x350b400, face=0x4e8c100, string=49838082)
> >    at composite.c:1147
> > #4  0x01069fcb in next_element_from_buffer (it=0x88d6f8) at xdisp.c:6834
> > #5  0x01066642 in get_next_display_element (it=0x88d6f8) at xdisp.c:5828
> 
> I see the same crash in Emacs 23.1.96, which means two things:
> 
>   . It has nothing to do with bidi code (phew!)
> 
>   . It is much more urgent to fix

Here's the analysis of what causes this crash:

  . The defadvice displays the value of END, the second argument to
    narrow-to-region.  When the defadvice is evaluated, Edebug
    displays the result, and attempts to interpret it as a character.

  . As the result, the following text is inserted into the " *Echo
    Area 0*" buffer, with the purpose of displaying it in the echo
    area:

           Result: 784 (#o1420, #x310, 0̐)

    The funny character before the right parenthesis is composed from
    u+0310 (COMBINING CANDRABINDU), and ASCII `0' (the digit zero).  I
    presume that some composition rule causes us to display a bare
    u+0310 composed like that.

  . Emacs then enters redisplay to display the echo area.  As part of
    redisplay, autocmp_chars is called, and it records the values of
    point in character and byte units:

         EMACS_INT pt = PT, pt_byte = PT_BYTE;

    At this point, pt is 32 and pt_byte is 33, which is consistent
    with the multibyte text we have in the buffer, as shown above.

  . Further down, autocmp_chars calls the value of
    auto-composition-function:

	  if (NILP (LGSTRING_ID (gstring)))
	    {
	      Lisp_Object args[6];

	      args[0] = Vauto_composition_function;
	      args[1] = AREF (elt, 2);
	      args[2] = pos;
	      args[3] = make_number (to);
	      args[4] = font_object;
	      args[5] = string;
	      gstring = safe_call (6, args);
	    }

  . The call to auto-composition-function loads uni-combining.el.  And
    because force-load-messages is non-nil, that displays the 2
    messages

      Loading lisp/international/uni-combining.el (source)...
      Loading lisp/international/uni-combining.el (source)...done

  . Now the " *Echo Area0*" buffer holds a totally different text,
    unbeknownst to autocmp_chars, which still passes the old values 32
    and 33 to TEMP_SET_PT_BOTH:

	  if (NILP (string))
	    TEMP_SET_PT_BOTH (pt, pt_byte);
	  return unbind_to (count, gstring);

  . temp_set_pt_both uses BUF_ZV and BUF_ZV_BYTE to validate its
    argument, but now BUF_ZV and BUF_ZV_BYTE correspond to the text
    "Loading ...", which has an entirely different length and
    contents, and the validation fails.  Therefore, temp_set_pt_both
    aborts.

One kludgy way of fixing this would be to bind force-load-messages to
nil around the call to auto-composition-function.  But that sounds too
harsh: after all, whoever sets that variable, actually wants to see
all these messages.

Another way is to force the "Loading..." messages use the second echo
area buffer.  Do we have ways to do something like that?

Ideas are welcome.

bug#5984: Crash displaying composed characters

[Juanma Barranquero]

On Tue, Apr 20, 2010 at 19:29, Eli Zaretskii <eliz@gnu.org> wrote:

> Here's the analysis of what causes this crash:

Nice work.

> But that sounds too
> harsh: after all, whoever sets that variable, actually wants to see
> all these messages.

Yes.

> Ideas are welcome.

You said:

> . Further down, autocmp_chars calls the value of
>  auto-composition-function:
[...]
> . Now the " *Echo Area0*" buffer holds a totally different text,
>   unbeknownst to autocmp_chars, which still passes the old values 32
>  and 33 to TEMP_SET_PT_BOTH:

So autocmp_chars should be made to know that after calling
auto-composition-function, " *Echo Area0" could have been modified.
(Yeah, easier said than done, I suppose...)

    Juanma

bug#5984: Crash displaying composed characters

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 20 Apr 2010 19:33:56 +0200
> Cc: 5984@debbugs.gnu.org
> 
> > . Now the " *Echo Area0*" buffer holds a totally different text,
> >   unbeknownst to autocmp_chars, which still passes the old values 32
> >  and 33 to TEMP_SET_PT_BOTH:
> 
> So autocmp_chars should be made to know that after calling
> auto-composition-function, " *Echo Area0" could have been modified.

I don't know how to do that, in the middle of composing characters.
Perhaps Handa-san (cc'ed) could help.

bug#5984: Crash displaying composed characters

[Glenn Morris]

Eli Zaretskii wrote:

>> What's the command to add new version tags to a bug?
>
> I don't know.  Glenn, can you help, please?

There is a "found" command:

http://debbugs.gnu.org/server-control.html

  found bugnumber [ version ]
    Record that #bugnumber has been encountered in the given version
    of the package to which it is assigned.

Please note that there is a new mailing list, help-debbugs, for these
kinds of questions.

bug#5984: Crash displaying composed characters

[Lennart Borgman]

On Tue, Apr 20, 2010 at 7:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> So autocmp_chars should be made to know that after calling
>> auto-composition-function, " *Echo Area0" could have been modified.
>
> I don't know how to do that, in the middle of composing characters.
> Perhaps Handa-san (cc'ed) could help.


Could perhaps autocmp_chars set a flag indicating that it knows Echo
Area0 that could be cleared by anything writing there?

bug#5984: Crash displaying composed characters

[Eli Zaretskii]

> Date: Tue, 20 Apr 2010 20:29:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 
> 
>   . The call to auto-composition-function loads uni-combining.el.  And
>     because force-load-messages is non-nil, that displays the 2
>     messages
> 
>       Loading lisp/international/uni-combining.el (source)...
>       Loading lisp/international/uni-combining.el (source)...done
> 
>   . Now the " *Echo Area0*" buffer holds a totally different text,
>     unbeknownst to autocmp_chars, which still passes the old values 32
>     and 33 to TEMP_SET_PT_BOTH:
> 
> 	  if (NILP (string))
> 	    TEMP_SET_PT_BOTH (pt, pt_byte);
> 	  return unbind_to (count, gstring);
> 
>   . temp_set_pt_both uses BUF_ZV and BUF_ZV_BYTE to validate its
>     argument, but now BUF_ZV and BUF_ZV_BYTE correspond to the text
>     "Loading ...", which has an entirely different length and
>     contents, and the validation fails.  Therefore, temp_set_pt_both
>     aborts.
> 
> One kludgy way of fixing this would be to bind force-load-messages to
> nil around the call to auto-composition-function.  But that sounds too
> harsh: after all, whoever sets that variable, actually wants to see
> all these messages.
> 
> Another way is to force the "Loading..." messages use the second echo
> area buffer.  Do we have ways to do something like that?
> 
> Ideas are welcome.

Here's one idea: use push_message and restore_message to save and
restore the current echo area message around the call to
auto-composition-function.  WDYT?

bug#5984: Crash displaying composed characters

[Andreas Schwab]

Please try this patch.

Andreas.

=== modified file 'src/composite.c'
--- src/composite.c	2010-01-14 03:54:04 +0000
+++ src/composite.c	2010-04-20 20:27:46 +0000
@@ -986,6 +986,14 @@ autocmp_chars (cft_element, charpos, byt
 	    font_object = win->frame;
 	  gstring = Fcomposition_get_gstring (pos, make_number (to),
 					      font_object, string);
+	  /* Calling auto-composition-function may modify the current
+	     buffer, save point as marker.  */
+	  if (NILP (string))
+	    {
+	      Lisp_Object m = Fmake_marker ();
+	      set_marker_both (m, current_buffer, pt, pt_byte);
+	      record_unwind_protect (restore_point_unwind, m);
+	    }
 	  if (NILP (LGSTRING_ID (gstring)))
 	    {
 	      Lisp_Object args[6];
@@ -998,8 +1006,6 @@ autocmp_chars (cft_element, charpos, byt
 	      args[5] = string;
 	      gstring = safe_call (6, args);
 	    }
-	  if (NILP (string))
-	    TEMP_SET_PT_BOTH (pt, pt_byte);
 	  return unbind_to (count, gstring);
 	}
     }

=== modified file 'src/fileio.c'
--- src/fileio.c	2010-02-18 09:02:04 +0000
+++ src/fileio.c	2010-04-20 20:27:46 +0000
@@ -302,7 +302,7 @@ close_file_unwind (fd)
 
 /* Restore point, having saved it as a marker.  */
 
-static Lisp_Object
+Lisp_Object
 restore_point_unwind (location)
      Lisp_Object location;
 {

=== modified file 'src/lisp.h'
--- src/lisp.h	2010-03-05 23:08:18 +0000
+++ src/lisp.h	2010-04-20 20:27:46 +0000
@@ -3018,6 +3018,7 @@ EXFUN (Ffile_readable_p, 1);
 EXFUN (Ffile_executable_p, 1);
 EXFUN (Fread_file_name, 6);
 extern Lisp_Object close_file_unwind P_ ((Lisp_Object));
+extern Lisp_Object restore_point_unwind P_ ((Lisp_Object));
 extern void report_file_error P_ ((const char *, Lisp_Object)) NO_RETURN;
 extern int internal_delete_file P_ ((Lisp_Object));
 extern void syms_of_fileio P_ ((void));


-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#5984: Crash displaying composed characters

[Juanma Barranquero]

> Please try this patch.

With it, I don't get a crash, but an error:

  Wrong type argument: bufferp, 12846208

    Juanma

bug#5984: Crash displaying composed characters

[Andreas Schwab]

Juanma Barranquero <lekktu@gmail.com> writes:

>> Please try this patch.
>
> With it, I don't get a crash, but an error:
>
>   Wrong type argument: bufferp, 12846208

Here's an updated patch.

Andreas.

=== modified file 'src/composite.c'
--- src/composite.c	2010-01-14 03:54:04 +0000
+++ src/composite.c	2010-04-21 12:10:13 +0000
@@ -986,20 +986,31 @@ autocmp_chars (cft_element, charpos, byt
 	    font_object = win->frame;
 	  gstring = Fcomposition_get_gstring (pos, make_number (to),
 					      font_object, string);
-	  if (NILP (LGSTRING_ID (gstring)))
+	  if (!NILP (LGSTRING_ID (gstring)))
 	    {
-	      Lisp_Object args[6];
-
-	      args[0] = Vauto_composition_function;
-	      args[1] = AREF (elt, 2);
-	      args[2] = pos;
-	      args[3] = make_number (to);
-	      args[4] = font_object;
-	      args[5] = string;
-	      gstring = safe_call (6, args);
+	      if (NILP (string))
+		TEMP_SET_PT_BOTH (pt, pt_byte);
+	      return unbind_to (count, gstring);
 	    }
+
+	  /* Save point as marker before calling out to lisp.  */
 	  if (NILP (string))
-	    TEMP_SET_PT_BOTH (pt, pt_byte);
+	    {
+	      Lisp_Object m = Fmake_marker ();
+	      set_marker_both (m, Qnil, pt, pt_byte);
+	      record_unwind_protect (restore_point_unwind, m);
+	    }
+	  {
+	    Lisp_Object args[6];
+
+	    args[0] = Vauto_composition_function;
+	    args[1] = AREF (elt, 2);
+	    args[2] = pos;
+	    args[3] = make_number (to);
+	    args[4] = font_object;
+	    args[5] = string;
+	    gstring = safe_call (6, args);
+	  }
 	  return unbind_to (count, gstring);
 	}
     }

=== modified file 'src/fileio.c'
--- src/fileio.c	2010-04-21 03:02:58 +0000
+++ src/fileio.c	2010-04-21 09:22:01 +0000
@@ -299,7 +299,7 @@ close_file_unwind (fd)
 
 /* Restore point, having saved it as a marker.  */
 
-static Lisp_Object
+Lisp_Object
 restore_point_unwind (location)
      Lisp_Object location;
 {

=== modified file 'src/lisp.h'
--- src/lisp.h	2010-04-21 03:02:58 +0000
+++ src/lisp.h	2010-04-21 09:22:01 +0000
@@ -3061,6 +3061,7 @@ EXFUN (Ffile_readable_p, 1);
 EXFUN (Ffile_executable_p, 1);
 EXFUN (Fread_file_name, 6);
 extern Lisp_Object close_file_unwind P_ ((Lisp_Object));
+extern Lisp_Object restore_point_unwind P_ ((Lisp_Object));
 extern void report_file_error P_ ((const char *, Lisp_Object)) NO_RETURN;
 extern int internal_delete_file P_ ((Lisp_Object));
 extern void syms_of_fileio P_ ((void));



-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#5984: Crash displaying composed characters

[Juanma Barranquero]

On Wed, Apr 21, 2010 at 14:33, Andreas Schwab <schwab@linux-m68k.org> wrote:

> Here's an updated patch.

Yes, it fixes the bug.

    Juanma

bug#5984: Crash displaying composed characters

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  5984@debbugs.gnu.org
> Date: Wed, 21 Apr 2010 14:33:59 +0200
> 
> Juanma Barranquero <lekktu@gmail.com> writes:
> 
> >> Please try this patch.
> >
> > With it, I don't get a crash, but an error:
> >
> >   Wrong type argument: bufferp, 12846208
> 
> Here's an updated patch.

Thanks.  This prevents the crash, but the message shown in the echo
area is "Loading lisp/international/uni-combining.el (source)...done",
whereas I would expect to see the message from Edebug saying
"Result: ...", as if uni-combining.el was never loaded.

If this is hard to do, then perhaps we should install this patch on
the Emacs 23 branch, and enhance it later on the trunk to show the
Edebug message.

bug#5984: Crash displaying composed characters

[Stefan Monnier]

>   . Emacs then enters redisplay to display the echo area.  As part of
[...]
>   . Further down, autocmp_chars calls the value of
>     auto-composition-function:
[...]
>   . Now the " *Echo Area0*" buffer holds a totally different text,
>     unbeknownst to autocmp_chars, which still passes the old values 32
>     and 33 to TEMP_SET_PT_BOTH:

More generally, this Lisp code could modify any buffer, so preventing
the load-messages is not a sufficiently reliable solution (tho it might
be desirable in any case).


        Stefan

bug#5984: Crash displaying composed characters

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: lekktu@gmail.com, 5984@debbugs.gnu.org
> Date: Fri, 30 Apr 2010 16:47:43 -0400
> 
> >   . Emacs then enters redisplay to display the echo area.  As part of
> [...]
> >   . Further down, autocmp_chars calls the value of
> >     auto-composition-function:
> [...]
> >   . Now the " *Echo Area0*" buffer holds a totally different text,
> >     unbeknownst to autocmp_chars, which still passes the old values 32
> >     and 33 to TEMP_SET_PT_BOTH:
> 
> More generally, this Lisp code could modify any buffer, so preventing
> the load-messages is not a sufficiently reliable solution (tho it might
> be desirable in any case).

I think the patch suggested by Andreas (now installed on the release
branch) does what's necessary.  It's unfortunate minor side-effect is
that the original message from Edebug gets lost; it would be good to
fix that on the trunk.

bug#5984: Crash displaying composed characters

[Kenichi Handa]

In article <jwvr5lw4qnn.fsf-monnier+gnus-read-ephemeral-bug@gnu.org>, Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> >   . Emacs then enters redisplay to display the echo area.  As part of
> [...]
> >   . Further down, autocmp_chars calls the value of
> >     auto-composition-function:
> [...]
> >   . Now the " *Echo Area0*" buffer holds a totally different text,
> >     unbeknownst to autocmp_chars, which still passes the old values 32
> >     and 33 to TEMP_SET_PT_BOTH:

> More generally, this Lisp code could modify any buffer, so preventing
> the load-messages is not a sufficiently reliable solution (tho it might
> be desirable in any case).

Yes, and this problem is not only in auto-composition.  For
instance, evaluating this crashes Emacs.

(put-text-property 1 10 'display '(height (progn (delete-region 1 10))))

How about having a special mode in which any modifications
to buffers are silently ignored, and we run Lisp in that
mode in redisplay?

Another way is to check MODIFF before and after calling
Lisp, and if the current buffer is modified, restart the
redisplay... somehow.

---
Kenichi Handa
handa@m17n.org

bug#5984: Crash displaying composed characters

[Juanma Barranquero]

On Fri, Apr 23, 2010 at 11:17, Eli Zaretskii <eliz@gnu.org> wrote:

> Thanks.  This prevents the crash, but the message shown in the echo
> area is "Loading lisp/international/uni-combining.el (source)...done",
> whereas I would expect to see the message from Edebug saying
> "Result: ...", as if uni-combining.el was never loaded.
>
> If this is hard to do, then perhaps we should install this patch on
> the Emacs 23 branch, and enhance it later on the trunk to show the
> Edebug message.

(Just pinging; the workaround was installed in 23.X, I think, but the
crash still happens in 24.0.50.)

    Juanma

bug#5984: Crash displaying composed characters

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> (Just pinging; the workaround was installed in 23.X, I think, but the
> crash still happens in 24.0.50.)

A change to autocmp_chars in the trunk undid the workaround.  I've fixed
that.

As to the larger question of how to handle composition or redisplay
functions that modify the buffer, I still don't see any good solution.
Forbidding them from modifying buffers entirely is no good, because
fontification functions need to be able to change text properties.

I will, however, install a few additional ad-hoc fixes on the trunk to
inhibit crashes like

  (put-text-property 1 10 'display '(height (progn (delete-region 1 10))))

bug#5984: Crash displaying composed characters

[Juanma Barranquero]

On Sun, Aug 7, 2011 at 21:45, Chong Yidong <cyd@stupidchicken.com> wrote:

> A change to autocmp_chars in the trunk undid the workaround.  I've fixed
> that.
>
> As to the larger question of how to handle composition or redisplay
> functions that modify the buffer, I still don't see any good solution.
> Forbidding them from modifying buffers entirely is no good, because
> fontification functions need to be able to change text properties.
>
> I will, however, install a few additional ad-hoc fixes on the trunk to
> inhibit crashes like
>
>  (put-text-property 1 10 'display '(height (progn (delete-region 1 10))))

Ping.


    Juanma

bug#5984: Crash displaying composed characters

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

>> I will, however, install a few additional ad-hoc fixes on the trunk to
>> inhibit crashes like
>>
>>  (put-text-property 1 10 'display '(height (progn (delete-region 1 10))))
>
> Ping.

Oh, right.  Committed, thanks.