GNU bug report logs - #5984
Crash displaying composed characters

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5984 in the body.
You can then email your comments to 5984 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: Crash displaying composed characters
Date: Tue, 20 Apr 2010 15:42:16 +0200

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)

Message #8 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Tue, 20 Apr 2010 18:06:58 +0300

> From: Juanma Barranquero <lekktu <at> 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

Message #11 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: control <at> debbugs.gnu.org, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Tue, 20 Apr 2010 17:48:21 +0200

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

Message #16 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Tue, 20 Apr 2010 19:07:23 +0300

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

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

Message #19 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: lekktu <at> gmail.com, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Tue, 20 Apr 2010 20:29:29 +0300

> Date: Tue, 20 Apr 2010 18:06:58 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 5984 <at> debbugs.gnu.org
> 
> > From: Juanma Barranquero <lekktu <at> 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.

Message #22 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Tue, 20 Apr 2010 19:33:56 +0200

On Tue, Apr 20, 2010 at 19:29, Eli Zaretskii <eliz <at> 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

Message #25 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>, Kenichi Handa <handa <at> m17n.org>
Cc: 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Tue, 20 Apr 2010 20:52:27 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 20 Apr 2010 19:33:56 +0200
> Cc: 5984 <at> 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.

Message #28 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Tue, 20 Apr 2010 14:38:58 -0400

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.

Message #31 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 5984 <at> debbugs.gnu.org,
	Kenichi Handa <handa <at> m17n.org>
Subject: Re: bug#5984: Crash displaying composed characters
Date: Tue, 20 Apr 2010 20:43:48 +0200

On Tue, Apr 20, 2010 at 7:52 PM, Eli Zaretskii <eliz <at> 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?

Message #34 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Tue, 20 Apr 2010 22:18:40 +0300

> Date: Tue, 20 Apr 2010 20:29:29 +0300
> From: Eli Zaretskii <eliz <at> 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?

Message #37 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Tue, 20 Apr 2010 22:38:47 +0200

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 <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #42 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Wed, 21 Apr 2010 12:48:37 +0200

> Please try this patch.

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

  Wrong type argument: bufferp, 12846208

    Juanma

Message #45 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Wed, 21 Apr 2010 14:33:59 +0200

Juanma Barranquero <lekktu <at> 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 <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #48 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Wed, 21 Apr 2010 19:21:00 +0200

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

> Here's an updated patch.

Yes, it fixes the bug.

    Juanma

Message #51 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: lekktu <at> gmail.com, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Fri, 23 Apr 2010 12:17:57 +0300

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  5984 <at> debbugs.gnu.org
> Date: Wed, 21 Apr 2010 14:33:59 +0200
> 
> Juanma Barranquero <lekktu <at> 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.

Message #56 received at 5984-done <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5984-done <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: Bug 5984
Date: Fri, 30 Apr 2010 12:01:38 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

> Bug#5984 is still not closed.  Andreas suggested a fix that eliminates
> the crash, so I think it should be installed at least in the Emacs-23
> branch.  I don't think we should release Emacs 23.2 with such a bad
> crash.

I was hoping for a bit more discussion on that patch, but since none
seems forthcoming, I have checked it into the emacs-23 branch.  Thanks
for the reminder.

Message #59 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
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).


        Stefan

Message #62 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: lekktu <at> gmail.com, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Sat, 01 May 2010 09:09:01 +0300

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: lekktu <at> gmail.com, 5984 <at> 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.

Message #65 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: lekktu <at> gmail.com, eliz <at> gnu.org, 5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Sat, 01 May 2010 15:28:46 +0900

In article <jwvr5lw4qnn.fsf-monnier+gnus-read-ephemeral-bug <at> gnu.org>, Stefan Monnier <monnier <at> 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 <at> m17n.org

Message #70 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5984 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#5984: Crash displaying composed characters
Date: Wed, 6 Jul 2011 04:28:38 +0200

On Fri, Apr 23, 2010 at 11:17, Eli Zaretskii <eliz <at> 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

Message #73 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, Eli Zaretskii <eliz <at> gnu.org>,
	5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Sun, 07 Aug 2011 15:45:29 -0400

Juanma Barranquero <lekktu <at> 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))))

Message #76 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, Eli Zaretskii <eliz <at> gnu.org>,
	5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Wed, 23 Nov 2011 04:14:27 +0100

On Sun, Aug 7, 2011 at 21:45, Chong Yidong <cyd <at> 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

Message #79 received at 5984 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, Eli Zaretskii <eliz <at> gnu.org>,
	5984 <at> debbugs.gnu.org
Subject: Re: bug#5984: Crash displaying composed characters
Date: Wed, 23 Nov 2011 14:47:02 +0800

Juanma Barranquero <lekktu <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.