bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Date: Thu, 02 Oct 2014 17:40:45 +0200
> Cc: 18610@debbugs.gnu.org
> 
> maden.ldm@gmail.com writes:
> 
> > 1. emacs -Q
> > 2. M-x find-file /home/ldionmarcil/Documents/bugreportemacs/_mixins.scssc 
> > RET
> > 3. Emacs segfault
> 
> Here's an actual backtrace, but I only get the crash if I do something
> else. e.g. end-of-buffer. Perhaps my screen is too small.

Thanks.  It is very easy to get a backtrace with a working
installation of GDB, just by using the OP's recipe.  Here's what I
get:

  Program received signal SIGTRAP, Trace/breakpoint trap.
  0x7c90120f in ntdll!DbgBreakPoint () from C:\WINDOWS\system32\ntdll.dll
  (gdb) bt
  #0  0x7c90120f in ntdll!DbgBreakPoint () from C:\WINDOWS\system32\ntdll.dll
  #1  0x0120161e in emacs_abort () at w32fns.c:8491
  #2  0x010d48f3 in bidi_get_type (ch=4195643, override=NEUTRAL_DIR)
      at bidi.c:289
  #3  0x010d8540 in bidi_resolve_weak (bidi_it=0x82d680) at bidi.c:2030
  #4  0x010d8742 in bidi_resolve_neutral (bidi_it=0x82d680) at bidi.c:2120
  #5  0x010d8b18 in bidi_type_of_next_char (bidi_it=0x82d680) at bidi.c:2291
  #6  0x010d8e4a in bidi_level_of_next_char (bidi_it=0x82d680) at bidi.c:2404
  #7  0x010d931f in bidi_move_to_visually_next (bidi_it=0x82d680) at bidi.c:2614
  #8  0x01036b7f in set_iterator_to_next (it=0x82d0cc, reseat_p=1)
      at xdisp.c:7417
  #9  0x0105eecd in display_line (it=0x82d0cc) at xdisp.c:20617
  #10 0x010517e4 in try_window (window=61647613, pos=..., flags=0)
      at xdisp.c:16972
  #11 0x0104e1d2 in redisplay_window (window=61647613, just_this_one_p=true)
      at xdisp.c:16223
  #12 0x01047eb1 in redisplay_window_1 (window=61647613) at xdisp.c:14356
  #13 0x01181fba in internal_condition_case_1 (
      bfun=0x1047e7b <redisplay_window_1>, arg=61647613, handlers=58275094,
      hfun=0x1047e1a <redisplay_window_error>) at eval.c:1372
  #14 0x01047281 in redisplay_internal () at xdisp.c:14002
  #15 0x01044eaf in redisplay () at xdisp.c:13207
  #16 0x010fad1c in read_char (commandflag=1, map=62245526,
      prev_event=58292258, used_mouse_menu=0x82f7c3, end_time=0x0)
      at keyboard.c:2570
  #17 0x011080d9 in read_key_sequence (keybuf=0x82f8e0, bufsize=30,
      prompt=58292258, dont_downcase_last=false, can_return_switch_frame=true,
      fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9088
  #18 0x010f884b in command_loop_1 () at keyboard.c:1452
  #19 0x01181ea7 in internal_condition_case (bfun=0x10f84ce <command_loop_1>,
      handlers=58343778, hfun=0x10f7d33 <cmd_error>) at eval.c:1348
  #20 0x010f8183 in command_loop_2 (ignore=58292258) at keyboard.c:1177
  #21 0x01181457 in internal_catch (tag=58339138,
      func=0x10f815f <command_loop_2>, arg=58292258) at eval.c:1112
  #22 0x010f8139 in command_loop () at keyboard.c:1156
  #23 0x010f78d0 in recursive_edit_1 () at keyboard.c:777
  #24 0x010f7a8c in Frecursive_edit () at keyboard.c:848
  #25 0x010f5ca7 in main (argc=2, argv=0xa427e8) at emacs.c:1646

  Lisp Backtrace:
  "redisplay_internal (C function)" (0x1542e9c)
  (gdb) up
  #1  0x0120161e in emacs_abort () at w32fns.c:8491
  8491          DebugBreak ();
  (gdb) up
  #2  0x010d48f3 in bidi_get_type (ch=4195643, override=NEUTRAL_DIR)
      at bidi.c:289
  289         emacs_abort ();
  (gdb) up
  #3  0x010d8540 in bidi_resolve_weak (bidi_it=0x82d680) at bidi.c:2030
  2030                  type_of_next = bidi_get_type (next_char, override);
  (gdb) p next_char
  $1 = 4195643
  (gdb) p/x next_char
  $2 = 0x40053b
  (gdb) p bidi_it->charpos
  $3 = 2672

As you see, at character position 2673 we get an invalid character
codepoint 0x40053b, which is greater than MAX_CHAR.  So bidi.c
rightfully refuses to play with such a codepoint.

Preliminary diagnostics indicates that under some as yet unclear
circumstances the raw byte \226 gets represented incorrectly in the
buffer: the leading \300 byte of the 2-byte sequence is missing.
Perhaps we have some subtle bug in the text-decoding functions, so I'm
adding Handa-san to the addressees.

This affects the emacs-24 branch as well, so is quite urgent.

I'll continue looking into this.