[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening
From: |
Eli Zaretskii |
Subject: |
bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening |
Date: |
Fri, 03 Oct 2014 11:14:05 +0300 |
> 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.
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, maden . ldm, 2014/10/02
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Nicolas Richard, 2014/10/02
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening,
Eli Zaretskii <=
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Dmitry Antipov, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Eli Zaretskii, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Eli Zaretskii, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Andreas Schwab, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Eli Zaretskii, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Andreas Schwab, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Eli Zaretskii, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Andreas Schwab, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, Eli Zaretskii, 2014/10/03
- bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening, K. Handa, 2014/10/05