Crash using text property 'composite on w32

Crash using text property 'composite on w32

[Lennart Borgman (gmail)]

Evaluating the code below in the scratch buffer makes Emacs crash for 
me. There is no backtrace. I start with "emacs -Q":

(let ((s "text"))
   (put-text-property 0 2 'composition ?A s)
   (insert s))

If the crash comes in (insert s).


In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
  of 2007-06-04
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'

Re: Crash using text property 'composite on w32

[Jason Rumney]

Lennart Borgman (gmail) wrote:
>
> There is no backtrace.

Are you configuring with --no-debug again?

Re: Crash using text property 'composite on w32

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> There is no backtrace.
> 
> Are you configuring with --no-debug again?

No. I included the configure line in the message I sent:

In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
  of 2007-06-04
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'

Re: Crash using text property 'composite on w32

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Jason Rumney wrote:
>> Lennart Borgman (gmail) wrote:
>>> There is no backtrace.
>>
>> Are you configuring with --no-debug again?
>
> No. I included the configure line in the message I sent:
So why don't you get a backtrace when it crashes under gdb?

Aside: As you'd obviously removed the machine name from the second line,
I wasn't sure that you hadn't removed something else as well.

Re: Crash using text property 'composite on w32

[Juanma Barranquero]

Program received signal SIGSEGV, Segmentation fault.
0x010c798a in run_composition_function (from=267, to=269, prop=520)
    at composite.c:456
456       func = COMPOSITION_MODIFICATION_FUNC (prop);
(gdb) bt
#0  0x010c798a in run_composition_function (from=267, to=269, prop=520)
    at composite.c:456
#1  0x010c7d1c in update_compositions (from=269, to=271, check_mask=3)
    at composite.c:514
#2  0x01088a00 in general_insert_function (insert_func=0x10e8e95 <insert>,
    insert_from_string_func=0x10e8c24 <insert_from_string>, inherit=0,
    nargs=1, args=0x82f4d0) at editfns.c:2167
#3  0x01088a98 in Finsert (nargs=1, args=0x82f4d0) at editfns.c:2211
#4  0x0100b668 in Feval (form=26046389) at eval.c:2331
#5  0x0100b936 in Fprogn (args=26046397) at eval.c:447
#6  0x0100dbc9 in Flet (args=26033181) at eval.c:1064
#7  0x0100b72f in Feval (form=26033213) at eval.c:2275
#8  0x0100c13c in Ffuncall (nargs=2, args=0x82f7a0) at eval.c:2997
#9  0x0110c9a3 in Fbyte_code (bytestr=18775043, vector=18775060, maxdepth=64)
    at bytecode.c:679
#10 0x0100ba26 in funcall_lambda (fun=18775004, nargs=1, arg_vector=0x82f8f4)
    at eval.c:3184
#11 0x0100bf1b in Ffuncall (nargs=2, args=0x82f8f0) at eval.c:3054
#12 0x0110c9a3 in Fbyte_code (bytestr=18775539, vector=18775556, maxdepth=32)
    at bytecode.c:679
#13 0x0100ba26 in funcall_lambda (fun=18775500, nargs=1, arg_vector=0x82fa84)
    at eval.c:3184
#14 0x0100bf1b in Ffuncall (nargs=2, args=0x82fa80) at eval.c:3054
#15 0x0110b634 in Fcall_interactively (function=24232633,
    record_flag=23803905, keys=23867396) at callint.c:860
#16 0x01055a20 in Fcommand_execute (cmd=24232633, record_flag=23803905,
    keys=23803905, special=23803905) at keyboard.c:10119
#17 0x0105c7da in command_loop_1 () at keyboard.c:1873
#18 0x0100a347 in internal_condition_case (bfun=0x105c486 <command_loop_1>,
    handlers=23872137, hfun=0x105645e <cmd_error>) at eval.c:1481
#19 0x01050656 in command_loop_2 () at keyboard.c:1329
#20 0x0100a27c in internal_catch (tag=23862273,
    func=0x1050633 <command_loop_2>, arg=23803905) at eval.c:1222
#21 0x010504a3 in command_loop () at keyboard.c:1308
#22 0x01050537 in recursive_edit_1 () at keyboard.c:1006
#23 0x0105061c in Frecursive_edit () at keyboard.c:1067
#24 0x01002a2b in main (argc=3, argv=0xf726e0) at emacs.c:1768
#25 0x01001247 in __mingw_CRTStartup ()
#26 0x01001298 in mainCRTStartup ()
#27 0x7c816fd7 in _end__ ()

Re: Crash using text property 'composite on w32

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x010c798a in run_composition_function (from=267, to=269, prop=520)
>    at composite.c:456
> 456       func = COMPOSITION_MODIFICATION_FUNC (prop);
> (gdb) bt
> #0  0x010c798a in run_composition_function (from=267, to=269, prop=520)
>    at composite.c:456

Ah, thanks. I am not familiar with gdb.

Re: Crash using text property 'composite on w32

[Eli Zaretskii]

> Date: Tue, 12 Jun 2007 02:30:23 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: bug-gnu-emacs@gnu.org
> 
> Juanma Barranquero wrote:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x010c798a in run_composition_function (from=267, to=269, prop=520)
> >    at composite.c:456
> > 456       func = COMPOSITION_MODIFICATION_FUNC (prop);
> > (gdb) bt
> > #0  0x010c798a in run_composition_function (from=267, to=269, prop=520)
> >    at composite.c:456
> 
> Ah, thanks. I am not familiar with gdb.

You could also configure drmingw.exe (from mingw-utils-0.3.tar.gz) as
your JIT debugger.  This is what I get from it if I try your recipe:

emacs.exe caused an Access Violation at location 010c76ca in module emacs.exe Reading from location 00000208.

Registers:
eax=00000208 ebx=00000050 ecx=00000208 edx=00000208 esi=0000004e edi=00000052
eip=010c76ca esp=0082f3c0 ebp=0082f408 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202

Call stack:
010C76CA  emacs.exe:010C76CA  run_composition_function  composite.c:456
static void run_composition_function(
	int from = ,
	int to = ,
	Lisp_Object prop = 520
)
	...
	  int start, end;
	
>	  func = COMPOSITION_MODIFICATION_FUNC (prop);
	  /* If an invalid composition precedes or follows, try to make them
	     valid too.  */
	...

010C7A5C  emacs.exe:010C7A5C  update_compositions  composite.c:517
void update_compositions(
	int from = 80,
	int to = 82,
	int check_mask = 3
)
	...
	    }
	
>	  if (check_mask & CHECK_INSIDE)
	    {
	      /* In this case, we are sure that (check & CHECK_TAIL) is also
	...

0108871A  emacs.exe:0108871A  general_insert_function  editfns.c:2178
static void general_insert_function(
	void ()(void) * insert_func = &insert,
	void ()(void) * insert_from_string_func = &insert_from_string,
	int inherit = 0,
	int nargs = 1,
	Lisp_Object * args = &30034243
)
	...
	      else if (STRINGP (val))
	{
>	  (*insert_from_string_func) (val, 0, 0,
	      SCHARS (val),
	      SBYTES (val),
	...

010887B2  emacs.exe:010887B2  Finsert  editfns.c:2223
Lisp_Object Finsert(
	int nargs = 1,
	Lisp_Object * args = &30034243
)
	...
	{
	  general_insert_function (insert, insert_from_string, 0, nargs, args);
>	  return Qnil;
	}
	
	...

0100B5D9  emacs.exe:0100B5D9  Feval  eval.c:2331
Lisp_Object Feval(
	Lisp_Object form = 30228989
)
	...
	  goto done;
	case 2:
>	  val = (*XSUBR (fun)->function) (argvals[0], argvals[1]);
	  goto done;
	case 3:
	...

0100B8A7  emacs.exe:0100B8A7  Fprogn  eval.c:448
Lisp_Object Fprogn(
	Lisp_Object args = 30228981
)
	...
	    {
	      val = Feval (XCAR (args));
>	      args = XCDR (args);
	    }
	
	...

0100DB3A  emacs.exe:0100DB3A  Flet  eval.c:1065
Lisp_Object Flet(
	Lisp_Object args = 30228909
)
	...
	
	  elt = Fprogn (Fcdr (args));
>	  return unbind_to (count, elt);
	}
	
	...

0100B6A0  emacs.exe:0100B6A0  Feval  eval.c:2275
Lisp_Object Feval(
	Lisp_Object form = 30228877
)
	...
	{
	  backtrace.evalargs = 0;
>	  val = (*XSUBR (fun)->function) (args_left);
	  goto done;
	}
	...

0100C0AD  emacs.exe:0100C0AD  Ffuncall  eval.c:2997
Lisp_Object Ffuncall(
	int nargs = 2,
	Lisp_Object * args = &23873065
)
	...
	  goto done;
	case 1:
>	  val = (*XSUBR (fun)->function) (internal_args[0]);
	  goto done;
	case 2:
	...

0110C683  emacs.exe:0110C683  Fbyte_code  bytecode.c:679
Lisp_Object Fbyte_code(
	Lisp_Object bytestr = 18775699,
	Lisp_Object vector = 18775716,
	Lisp_Object maxdepth = 64
)
	...
	      }
	#endif
>	    TOP = Ffuncall (op + 1, &TOP);
	    AFTER_POTENTIAL_GC ();
	    break;
	...

0100B997  emacs.exe:0100B997  funcall_lambda  eval.c:3189
static Lisp_Object funcall_lambda(
	Lisp_Object fun = ,
	int nargs = 1,
	Lisp_Object * arg_vector = &23779329
)
	...
	    }
	
>	  return unbind_to (count, val);
	}
	
	...

0100BE8C  emacs.exe:0100BE8C  Ffuncall  eval.c:3066
Lisp_Object Ffuncall(
	int nargs = 2,
	Lisp_Object * args = &26681993
)
	...
	 done:
	  CHECK_CONS_LIST ();
>	  lisp_eval_depth--;
	  if (backtrace.debug_on_exit)
	    val = call_debugger (Fcons (Qexit, Fcons (val, Qnil)));
	...

0110C683  emacs.exe:0110C683  Fbyte_code  bytecode.c:679
Lisp_Object Fbyte_code(
	Lisp_Object bytestr = 18776195,
	Lisp_Object vector = 18776212,
	Lisp_Object maxdepth = 32
)
	...
	      }
	#endif
>	    TOP = Ffuncall (op + 1, &TOP);
	    AFTER_POTENTIAL_GC ();
	    break;
	...

0100B997  emacs.exe:0100B997  funcall_lambda  eval.c:3189
static Lisp_Object funcall_lambda(
	Lisp_Object fun = ,
	int nargs = 1,
	Lisp_Object * arg_vector = &23779329
)
	...
	    }
	
>	  return unbind_to (count, val);
	}
	
	...

0100BE8C  emacs.exe:0100BE8C  Ffuncall  eval.c:3066
Lisp_Object Ffuncall(
	int nargs = 2,
	Lisp_Object * args = &24273945
)
	...
	 done:
	  CHECK_CONS_LIST ();
>	  lisp_eval_depth--;
	  if (backtrace.debug_on_exit)
	    val = call_debugger (Fcons (Qexit, Fcons (val, Qnil)));
	...

0110B31E  emacs.exe:0110B31E  Fcall_interactively  callint.c:862
Lisp_Object Fcall_interactively(
	Lisp_Object function = 24273945,
	Lisp_Object record_flag = 23779329,
	Lisp_Object keys = 23842820
)
	...
	    val = Ffuncall (count + 1, args);
	    UNGCPRO;
>	    return unbind_to (speccount, val);
	  }
	}
	...

0105591A  emacs.exe:0105591A  Fcommand_execute  keyboard.c:10116
Lisp_Object Fcommand_execute(
	Lisp_Object cmd = 24273945,
	Lisp_Object record_flag = 23779329,
	Lisp_Object keys = 23779329,
	Lisp_Object special = 23779329
)
	...
	      backtrace.debug_on_exit = 0;
	
>	      tem = Fcall_interactively (cmd, record_flag, keys);
	
	      backtrace_list = backtrace.next;
	...

0105C6CA  emacs.exe:0105C6CA  command_loop_1  keyboard.c:1873
Lisp_Object command_loop_1(
	
)
	...
	            if (NILP (current_kboard->Vprefix_arg))
	              Fundo_boundary ();
>	            Fcommand_execute (Vthis_command, Qnil, Qnil, Qnil);
	
	#ifdef HAVE_X_WINDOWS
	...

0100A2B7  emacs.exe:0100A2B7  internal_condition_case  eval.c:1482
Lisp_Object internal_condition_case(
	Lisp_Object ()(void) * bfun = &command_loop_1,
	Lisp_Object handlers = 23847561,
	Lisp_Object ()(void) * hfun = &cmd_error
)
	...
	
	  val = (*bfun) ();
>	  catchlist = c.next;
	  handlerlist = h.next;
	  return val;
	...

01050556  emacs.exe:01050556  command_loop_2  keyboard.c:1329
Lisp_Object command_loop_2(
	
)
	...
	
	  do
>	    val = internal_condition_case (command_loop_1, Qerror, cmd_error);
	  while (!NILP (val));
	
	...

0100A1EC  emacs.exe:0100A1EC  internal_catch  eval.c:1222
Lisp_Object internal_catch(
	Lisp_Object tag = 23837697,
	Lisp_Object ()(void) * func = &command_loop_2,
	Lisp_Object arg = 23779329
)
	...
	  /* Call FUNC.  */
	  if (! _setjmp (c.jmp))
>	    c.val = (*func) (arg);
	
	  /* Throw works by a longjmp that comes right here.  */
	...

010503A3  emacs.exe:010503A3  command_loop  keyboard.c:1312
Lisp_Object command_loop(
	
)
	...
	
	/* End of file in -batch run causes exit here.  */
>	if (noninteractive)
	  Fkill_emacs (Qt);
	      }
	...

01050437  emacs.exe:01050437  recursive_edit_1  keyboard.c:1007
Lisp_Object recursive_edit_1(
	
)
	...
	
	  val = command_loop ();
>	  if (EQ (val, Qt))
	    Fsignal (Qquit, Qnil);
	  /* Handle throw from read_minibuf when using minibuffer
	...

0105051C  emacs.exe:0105051C  Frecursive_edit  keyboard.c:1068
Lisp_Object Frecursive_edit(
	
)
	...
	
	  recursive_edit_1 ();
>	  return unbind_to (count, Qnil);
	}
	
	...

010029E8  emacs.exe:010029E8  main  emacs.c:1765
int main(
	int argc = 2,
	char * * argv = &0x012be1b8
)
	...
	  /* NOTREACHED */
	  return 0;
>	}
	
	/* Sort the args so we can find the most important ones
	...

010011E7  emacs.exe:010011E7
01001238  emacs.exe:01001238
7C816D4F  kernel32.dll:7C816D4F  RegisterWaitForInputIdle

Re: Crash using text property 'composite on w32

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Tue, 12 Jun 2007 02:30:23 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> Cc: bug-gnu-emacs@gnu.org
>>
>> Juanma Barranquero wrote:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x010c798a in run_composition_function (from=267, to=269, prop=520)
>>>    at composite.c:456
>>> 456       func = COMPOSITION_MODIFICATION_FUNC (prop);
>>> (gdb) bt
>>> #0  0x010c798a in run_composition_function (from=267, to=269, prop=520)
>>>    at composite.c:456
>> Ah, thanks. I am not familiar with gdb.
> 
> You could also configure drmingw.exe (from mingw-utils-0.3.tar.gz) as
> your JIT debugger.  This is what I get from it if I try your recipe:

Thanks Eli. I have not noticed there is such a thing as drmingw before.

For those interested in downloading: This file is on the MinGW download 
page. Many of the other files should be downloaded from SourceForge. It 
seems like no one has had the time and interest to clean up the MinGW 
download page yet.

Re: Crash using text property 'composite on w32

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> Program received signal SIGSEGV, Segmentation fault.
> 0x010c798a in run_composition_function (from=267, to=269, prop=520)
>    at composite.c:456
> 456       func = COMPOSITION_MODIFICATION_FUNC (prop);
> (gdb) bt
> #0  0x010c798a in run_composition_function (from=267, to=269, prop=520)
>    at composite.c:456
> #1  0x010c7d1c in update_compositions (from=269, to=271, check_mask=3)
>    at composite.c:514

The trouble here is that the code expects the property `prop' obtained
from find_composition to be a valid composition, which is a cons.  So
probably the way to fix this is to stick in a couple of
COMPOSITION_VALID_P checks into update_compositions, around
composite.c:514.

The strange thing, though, is that the elisp manual describes the
composition property as follows (documented by Handa on 2007-04-19):

  `composition'
     This text property is used to display a sequence of characters as a
     single glyph composed from components.  For instance, in Thai a
     base consonant is composed with the following combining vowel as a
     single glyph.  The value should be a character or a sequence
     (vector, list, or string) of integers.

        * If it is a character, it means to display that character
          instead of the text in the region.

        * If it is a string, it means to display that string's contents
          instead of the text in the region.

        * If it is a vector or list, the elements are characters
          interleaved with internal codes specifying how to compose the
          following character with the previous one.

Is this a mistake?  The assumption made in the Emacs code is that the
only valid form for a `composition' property is a cons cell.  For
example, the definition of COMPOSITION_VALID_P in composite.h:96 is

#define COMPOSITION_VALID_P(start, end, prop)  \
  (CONSP (prop)                                \
   && .....

So it looks like the documentation needs to be fixed too.

Re: Crash using text property 'composite on w32

[Kenichi Handa]

In article <87bqfl5g90.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:

> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.bugs as well.

> "Juanma Barranquero" <lekktu@gmail.com> writes:

> > Program received signal SIGSEGV, Segmentation fault.
> > 0x010c798a in run_composition_function (from=267, to=269, prop=520)
> >    at composite.c:456
> > 456       func = COMPOSITION_MODIFICATION_FUNC (prop);
> > (gdb) bt
> > #0  0x010c798a in run_composition_function (from=267, to=269, prop=520)
> >    at composite.c:456
> > #1  0x010c7d1c in update_compositions (from=269, to=271, check_mask=3)
> >    at composite.c:514

> The trouble here is that the code expects the property `prop' obtained
> from find_composition to be a valid composition, which is a cons.  So
> probably the way to fix this is to stick in a couple of
> COMPOSITION_VALID_P checks into update_compositions, around
> composite.c:514.

Thank you for finding this bug.  You are right.  I installed
a fix in the trunk.  Anyway, composition property should not
be attached manually as this:

(let ((s "text"))
   (put-text-property 0 2 'composition ?A s)
   (insert s))

Instead, people should use compose-region or compose-string
as this:

(insert (compose-string "text" 0 2 ?A))

> The strange thing, though, is that the elisp manual describes the
> composition property as follows (documented by Handa on 2007-04-19):

>   `composition'
>      This text property is used to display a sequence of characters as a
>      single glyph composed from components.  For instance, in Thai a
>      base consonant is composed with the following combining vowel as a
>      single glyph.  The value should be a character or a sequence
>      (vector, list, or string) of integers.

>         * If it is a character, it means to display that character
>           instead of the text in the region.

>         * If it is a string, it means to display that string's contents
>           instead of the text in the region.

>         * If it is a vector or list, the elements are characters
>           interleaved with internal codes specifying how to compose the
>           following character with the previous one.

> Is this a mistake?

Yes.  The above description is for the argument COMPONENTS
of the function `compose-region', or for just a part of the
property value.  The value has this form:

   The property value has this form when the composition is made:
	((LENGTH . COMPONENTS) . MODIFICATION-FUNC)
   then turns to this form:
	(COMPOSITION-ID . (LENGTH COMPONENTS-VEC . MODIFICATION-FUNC))
   when the composition is registered in composition_hash_table and
   composition_table.  These rather peculiar structures were designed
   to make it easy to distinguish them quickly (we can do that by
   checking only the first element) and to extract LENGTH (from the
   former form) and COMPOSITION-ID (from the latter form).
   [...]

The detail is described in the header comment of
src/composite.c.  How much detail, do you think, we should
describe in Info?

Isn't it enough to say just as below?

The value should be a cons of special structure.  It should
be manipulated only by the functions `compose-region',
`compose-string' and `find-composition'.

---
Kenichi Handa
handa@m17n.org

Re: Crash using text property 'composite on w32

[Lennart Borgman (gmail)]

Kenichi Handa wrote:
> The value should be a cons of special structure.  It should
> be manipulated only by the functions `compose-region',
> `compose-string' and `find-composition'.


If that is the case then I think the elisp manual should say that and 
nothing else.