GNU bug report logs - #1179
Emacs on Windows hangs displaying unibyte strings

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 1179 in the body.
You can then email your comments to 1179 AT debbugs.gnu.org in the normal way.

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

Message #3 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: Emacs on Windows hangs displaying unibyte strings
Date: Thu, 16 Oct 2008 16:52:07 +0200

X-Debbugs-No-Ack: yes
Package: emacs,w32
Version: 23.0.60

This bug is perhaps a variant of #872, as it involves several common elements:

 - Seems a Windows-specific thing
 - (setq unibyte-display-via-language-environment t)
 - (set-buffer-multibyte nil)
 - Optimized vs. non-optimized builds do behave diferently

though the result is a bit different: Emacs hangs instead of crashing.

The initial bug I was looking at is that w32-list-locales, when run on
a Spanish edition of Windows XP, produces the following output:

1025	ARA	\301rabe (Arabia Saud\355)
1026	BGR	B\372lgaro
1027	CAT	Catal\341n
1028	CHT	Chino (Taiw\341n)
1029	CSY	Checo
1030	DAN	Dan\351s
1031	DEU	Alem\341n (Alemania)

etc., so obviously there's some kind of unibyte/multibyte problem: the
output of w32-get-locale-info is a unibyte "Windows ANSI" string,
while the resulting buffer is multibyte, iso-latin-1-dos.

That led me to try the following .emacs:

;;; .emacs ;;;

(setq unibyte-display-via-language-environment t)

(defun my-list-locales-bug ()
  ;;
  ;; this is w32-list-locales almost verbatim
  ;;
  (interactive)
  (if (null w32-valid-locales)
      (setq w32-valid-locales (w32-get-valid-locale-ids)))
  (switch-to-buffer-other-window (get-buffer-create "*Supported Locales*"))

  ;;;;;;;;;;;;;;;;;;;;;;;;;;
  (set-buffer-multibyte nil)
  ;;;;;;;;;;;;;;;;;;;;;;;;;;

  (erase-buffer)
  (insert "LCID\tAbbrev\tFull name\n\n")
  (insert (mapconcat
	   '(lambda (x)
	      (format "%d\t%s\t%s"
		      x
		      (w32-get-locale-info x)
		      (w32-get-locale-info x t)))
	   w32-valid-locales "\n"))
  (insert "\n")
  (goto-char (point-min)))

;;; .emacs ends here ;;;

Then, after M-x my-list-locales-bug, Emacs hangs.

 - With the default Courier New font, it hangs once the cursor moves
over a non-ASCII char or the buffer scrolls, prompting a redisplay. It
uses around 50% CPU. The bug does not show on non-optimized builds.

 - With DejaVu Sans Mono, it hangs immediately, and does not use CPU.
This happens with optimized and non-optimized builds.

This is a backtrace after C-c in the Courier New case:

Quit (expect signal SIGINT when the program is resumed)
(gdb) thread 1
[Switching to thread 1 (thread 860.0x370)]#0  0x7c91e4f4 in
ntdll!LdrAccessResource ()
   from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0  0x7c91e4f4 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll
#1  0x77ef597f in ?? () from C:\WINDOWS\system32\gdi32.dll
#2  0x77efd880 in UnrealizeObject () from C:\WINDOWS\system32\gdi32.dll
#3  0x011f765a in w32_fill_rect (f=0x2e42200, hdc=0x30010fd8,
pix=33554435, lprect=0x82e7dc) at w32term.c:393
#4  0x011f8127 in w32_draw_relief_rect (f=0x2e42200, left_x=136,
top_y=560, right_x=167, bottom_y=575,
    width=20810504, raised_p=0, top_p=1, bot_p=1, left_p=0, right_p=0,
clip_rect=0x82e86c) at w32term.c:1634
#5  0x011f841e in x_draw_glyph_string_box (s=0x82eac0) at w32term.c:1758
#6  0x011ff527 in x_draw_glyph_string (s=0x82eac0) at w32term.c:2266
#7  0x01056ccd in draw_glyphs (w=0x313da00, x=176, row=0x331f428,
area=TEXT_AREA, start=9, end=14,
    hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20504
#8  0x0105a309 in x_write_glyphs (start=0x3461120, len=5) at xdisp.c:21913
#9  0x0115f93a in update_window_line (w=0x313da00, vpos=7,
mouse_face_overwritten_p=0x82ef7c) at dispnew.c:4594
#10 0x0115fedc in update_window (w=0x313da00, force_p=0) at dispnew.c:4310
#11 0x01162596 in update_window_tree (w=0x313da00, force_p=0) at dispnew.c:4003
#12 0x011624fc in update_window_tree (w=0x313d800, force_p=0) at dispnew.c:4001
#13 0x01163d7c in update_frame (f=0x2e42200, force_p=0,
inhibit_hairy_id_p=0) at dispnew.c:3930
#14 0x01048abf in redisplay_internal (preserve_echo_area=<value
optimized out>) at xdisp.c:11906
#15 0x0108b8b9 in read_char (commandflag=1, nmaps=2, maps=0x82fb70,
prev_event=47896577, used_mouse_menu=0x82fc34,
    end_time=0x0) at keyboard.c:2649
#16 0x0108ff0a in read_key_sequence (keybuf=0x82fcd4, bufsize=30,
prompt=47896577, dont_downcase_last=0,
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9343
#17 0x01093061 in command_loop_1 () at keyboard.c:1621
#18 0x010191e6 in internal_condition_case (bfun=0x1092dd3
<command_loop_1>, handlers=47960329,
    hfun=0x108a056 <cmd_error>) at eval.c:1511
#19 0x010894fb in command_loop_2 () at keyboard.c:1338
#20 0x01019290 in internal_catch (tag=47956401, func=0x10894d8
<command_loop_2>, arg=47896577) at eval.c:1247
#21 0x01089e9b in command_loop () at keyboard.c:1317
#22 0x0108a1ef in recursive_edit_1 () at keyboard.c:942
#23 0x0108a35a in Frecursive_edit () at keyboard.c:1004
#24 0x01002cdc in main (argc=1, argv=0xa941c0) at emacs.c:1728

This is a backtrace after C-c in the DejaVu Sans Mono case:

Quit (expect signal SIGINT when the program is resumed)
(gdb) thread 1
[Switching to thread 1 (thread 2912.0x24c)]#0  0x7c91e4f4 in
ntdll!LdrAccessResource ()
   from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0  0x7c91e4f4 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll
#1  0x7c91df2c in ntdll!ZwWaitForMultipleObjects () from
C:\WINDOWS\system32\ntdll.dll
#2  0x7c809574 in KERNEL32!CreateFileMappingA () from
C:\WINDOWS\system32\kernel32.dll
#3  0x7e3995f9 in USER32!GetLastInputInfo () from C:\WINDOWS\system32\user32.dll
#4  0x7e3996a8 in USER32!MsgWaitForMultipleObjects () from
C:\WINDOWS\system32\user32.dll
#5  0x01099b18 in sys_select (nfds=1, rfds=0x82f970, wfds=0x0,
efds=0x0, timeout=0x82f968) at w32proc.c:1270
#6  0x0106861c in wait_reading_process_output (time_limit=30,
microsecs=0, read_kbd=-1, do_display=1,
    wait_for_cell=47896577, wait_proc=0x0, just_wait_proc=0) at process.c:4816
#7  0x0115966f in sit_for (timeout=240, reading=1, do_display=1) at
dispnew.c:6637
#8  0x0108c366 in read_char (commandflag=1, nmaps=2, maps=0x82fb70,
prev_event=47896577, used_mouse_menu=0x82fc34,
    end_time=0x0) at keyboard.c:2892
#9  0x0108ff0a in read_key_sequence (keybuf=0x82fcd4, bufsize=30,
prompt=47896577, dont_downcase_last=0,
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9343
#10 0x01093061 in command_loop_1 () at keyboard.c:1621
#11 0x010191e6 in internal_condition_case (bfun=0x1092dd3
<command_loop_1>, handlers=47960329,
    hfun=0x108a056 <cmd_error>) at eval.c:1511
#12 0x010894fb in command_loop_2 () at keyboard.c:1338
#13 0x01019290 in internal_catch (tag=47956401, func=0x10894d8
<command_loop_2>, arg=47896577) at eval.c:1247
#14 0x01089e9b in command_loop () at keyboard.c:1317
#15 0x0108a1ef in recursive_edit_1 () at keyboard.c:942
#16 0x0108a35a in Frecursive_edit () at keyboard.c:1004
#17 0x01002cdc in main (argc=1, argv=0xa941c0) at emacs.c:1728

Message #8 received at 1179 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: 1179 <at> debbugs.gnu.org
Subject: Re: bug#1179: Emacs on Windows hangs displaying unibyte strings
Date: Fri, 17 Oct 2008 13:48:06 +0200

merge 872 1179
quit

> This bug is perhaps a variant of #872, as it involves several common elements:

Yep, it is the same bug.

So far, the easiest way to reproduce it I've found is:

emacs -q

and then, on *scratch*, evaluate the following:

(progn
  (set-buffer-multibyte nil)
  (setq unibyte-display-via-language-environment t)
  (insert (encode-coding-string "á" 'cp1252)))

When running under gdb, the result is:

 - On non-optimized builds, it hangs.
 - On optimized builds, it crashes with the attached backtrace.

Is anyone able to reproduce it, or am I the only one seeing it?

   Juanma


Program received signal SIGSEGV, Segmentation fault.
0x011f804c in x_draw_glyph_string_background (s=0x82eae0, force_p=1)
at w32term.c:1279
1279            if (FONT_HEIGHT (s->font) < s->height - 2 * box_line_width
(gdb) bt
#0  0x011f804c in x_draw_glyph_string_background (s=0x82eae0,
force_p=1) at w32term.c:1279
#1  0x011ff540 in x_draw_glyph_string (s=0x82eae0) at w32term.c:2265
#2  0x01056ccd in draw_glyphs (w=0x3bb4c00, x=400, row=0x312c428,
area=TEXT_AREA, start=47, end=49,
    hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20504
#3  0x0105a309 in x_write_glyphs (start=0x300b5e0, len=2) at xdisp.c:21913
#4  0x0115f6fc in update_window_line (w=0x3bb4c00, vpos=7,
mouse_face_overwritten_p=0x82ef9c) at dispnew.c:4603
#5  0x0115fedc in update_window (w=0x3bb4c00, force_p=0) at dispnew.c:4310
#6  0x01162596 in update_window_tree (w=0x3bb4c00, force_p=0) at dispnew.c:4003
#7  0x01163d7c in update_frame (f=0x2e43200, force_p=0,
inhibit_hairy_id_p=0) at dispnew.c:3930
#8  0x01047a85 in redisplay_internal (preserve_echo_area=<value
optimized out>) at xdisp.c:11843
#9  0x0108b8b9 in read_char (commandflag=1, nmaps=2, maps=0x82fb70,
prev_event=47900673, used_mouse_menu=0x82fc34,
    end_time=0x0) at keyboard.c:2649
#10 0x0108ff0a in read_key_sequence (keybuf=0x82fcd4, bufsize=30,
prompt=47900673, dont_downcase_last=0,
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9343
#11 0x01093061 in command_loop_1 () at keyboard.c:1621
#12 0x010191e6 in internal_condition_case (bfun=0x1092dd3
<command_loop_1>, handlers=47964425,
    hfun=0x108a056 <cmd_error>) at eval.c:1511
#13 0x010894fb in command_loop_2 () at keyboard.c:1338
#14 0x01019290 in internal_catch (tag=47960497, func=0x10894d8
<command_loop_2>, arg=47900673) at eval.c:1247
#15 0x01089e9b in command_loop () at keyboard.c:1317
#16 0x0108a1ef in recursive_edit_1 () at keyboard.c:942
#17 0x0108a35a in Frecursive_edit () at keyboard.c:1004
#18 0x01002cdc in main (argc=2, argv=0xa941e0) at emacs.c:1728

Message #15 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>, 1179 <at> debbugs.gnu.org
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1179: Emacs on Windows hangs displaying unibyte strings
Date: Fri, 17 Oct 2008 15:01:14 +0200

> Date: Fri, 17 Oct 2008 13:48:06 +0200
> From: "Juanma Barranquero" <lekktu <at> gmail.com>
> Cc: 
> 
> emacs -q
> 
> and then, on *scratch*, evaluate the following:
> 
> (progn
>   (set-buffer-multibyte nil)
>   (setq unibyte-display-via-language-environment t)
>   (insert (encode-coding-string "á" 'cp1252)))
> 
> When running under gdb, the result is:
> 
>  - On non-optimized builds, it hangs.
>  - On optimized builds, it crashes with the attached backtrace.
> 
> Is anyone able to reproduce it, or am I the only one seeing it?

It doesn't crash for me, with today's CVS.  But the result is strange
nonetheless, I think: the single á character in the last line above
are replaced with _two_ empty boxes about which "C-u C-x =" says:

	    character:   (195, #o303, #xc3)
    preferred charset: unicode (Unicode (ISO10646))
	   code point: 0xC3
	       syntax: w 	which means: word
	     category: j:Japanese l:Latin v:Vietnamese
	  buffer code: #xC3 #x83
	    file code: #xC3 (encoded by coding system iso-latin-1-dos)
	      display: by this font (glyph code)
	uniscribe:-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso10646-1 (#xAD)

	    character:   (161, #o241, #xa1)
    preferred charset: unicode (Unicode (ISO10646))
	   code point: 0xA1
	       syntax: . 	which means: punctuation
	     category: h:Korean j:Japanese l:Latin
	  buffer code: #xC2 #xA1
	    file code: #xA1 (encoded by coding system iso-latin-1-dos)
	      display: by this font (glyph code)
	uniscribe:-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso10646-1 (#xA3)

And the character that gets inserted (also displayed as an empty box)
is reported as

	    character:   (225, #o341, #xe1)
    preferred charset: unicode (Unicode (ISO10646))
	   code point: 0xE1
	       syntax: w 	which means: word
	     category: c:Chinese j:Japanese l:Latin v:Vietnamese
	  buffer code: #xC3 #xA1
	    file code: #xE1 (encoded by coding system iso-latin-1-dos)
	      display: by this font (glyph code)
	uniscribe:-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso10646-1 (#x69)

> Program received signal SIGSEGV, Segmentation fault.
> 0x011f804c in x_draw_glyph_string_background (s=0x82eae0, force_p=1)
> at w32term.c:1279
> 1279            if (FONT_HEIGHT (s->font) < s->height - 2 * box_line_width

So what's the reason of the crash?  Is `s' an invalid pointer?  Or
maybe GDB is confused by optimizations, and shows in correct source
line?  In the latter case, perhaps disassemblying around the address
of the crash (0x011f804c according to the above) would give an idea of
what went wrong.

Message #25 received at 1179 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 1179 <1179 <at> debbugs.gnu.org>
Subject: Re: bug#1179: Emacs on Windows hangs displaying unibyte strings
Date: Fri, 17 Oct 2008 15:32:47 +0200

On Fri, Oct 17, 2008 at 15:01, Eli Zaretskii <eliz <at> gnu.org> wrote:

> It doesn't crash for me, with today's CVS.  But the result is strange
> nonetheless, I think: the single á character in the last line above
> are replaced with _two_ empty boxes about which "C-u C-x =" says:

Could you please try with DejaVu Sans Mono?

I see these four different outputs:

 - Non-optimized build, Courier New: same as you.
 - Non-optimized build, DejaVu Sans Mono: the á character is replaced
by two spaces (not empty boxes) and Emacs hangs.
 - Optimized build, Courier New: á is replaced by two empty boxes, Emacs hangs.
 - Optimized build, DejaVu Sans Mono: Emacs crashes at w32term.c:1279.

>> Program received signal SIGSEGV, Segmentation fault.
>> 0x011f804c in x_draw_glyph_string_background (s=0x82eae0, force_p=1)
>> at w32term.c:1279
>> 1279            if (FONT_HEIGHT (s->font) < s->height - 2 * box_line_width
>
> So what's the reason of the crash?  Is `s' an invalid pointer?

No. s is valid, and so is s->face, for example. s->font is not, however

(gdb) p s
$1 = (struct glyph_string *) 0x82eae0
(gdb) p *s
$2 = {
  x = 384,
  y = 150,
  ...
}
(gdb) p *s->face
$3 = {
  id = 906494016,
  gc = 0x1803,
  ...
}
(gdb) p *s->font
Cannot access memory at address 0xdae80101

> Or
> maybe GDB is confused by optimizations, and shows in correct source
> line?  In the latter case, perhaps disassemblying around the address
> of the crash (0x011f804c according to the above) would give an idea of
> what went wrong.

(gdb) disassemble 0x011f804c
Dump of assembler code for function x_draw_glyph_string_background:
0x011f801c <x_draw_glyph_string_background+0>:  push   %ebp
0x011f801d <x_draw_glyph_string_background+1>:  mov    %esp,%ebp
0x011f801f <x_draw_glyph_string_background+3>:  push   %edi
0x011f8020 <x_draw_glyph_string_background+4>:  push   %esi
0x011f8021 <x_draw_glyph_string_background+5>:  push   %ebx
0x011f8022 <x_draw_glyph_string_background+6>:  sub    $0x2c,%esp
0x011f8025 <x_draw_glyph_string_background+9>:  mov    %eax,%ebx
0x011f8027 <x_draw_glyph_string_background+11>: mov    %edx,%edi
0x011f8029 <x_draw_glyph_string_background+13>: movzbl 0x5c(%eax),%ecx
0x011f802d <x_draw_glyph_string_background+17>: test   $0x2,%cl
0x011f8030 <x_draw_glyph_string_background+20>: jne    0x11f8096
<x_draw_glyph_string_background+122>
0x011f8032 <x_draw_glyph_string_background+22>: mov    0x44(%eax),%eax
0x011f8035 <x_draw_glyph_string_background+25>: mov    0x34(%eax),%edx
0x011f8038 <x_draw_glyph_string_background+28>: mov    %edx,%eax
0x011f803a <x_draw_glyph_string_background+30>: not    %eax
0x011f803c <x_draw_glyph_string_background+32>: sar    $0x1f,%eax
0x011f803f <x_draw_glyph_string_background+35>: and    %eax,%edx
0x011f8041 <x_draw_glyph_string_background+37>: lea    (%edx,%edx,1),%esi
0x011f8044 <x_draw_glyph_string_background+40>: neg    %esi
0x011f8046 <x_draw_glyph_string_background+42>: add    0x14(%ebx),%esi
0x011f8049 <x_draw_glyph_string_background+45>: mov    0x48(%ebx),%eax
0x011f804c <x_draw_glyph_string_background+48>: cmp    %esi,0x58(%eax)
0x011f804f <x_draw_glyph_string_background+51>: jl     0x11f8056
<x_draw_glyph_string_background+58>
0x011f8051 <x_draw_glyph_string_background+53>: and    $0x9,%cl
0x011f8054 <x_draw_glyph_string_background+56>: je     0x11f809e
<x_draw_glyph_string_background+130>
0x011f8056 <x_draw_glyph_string_background+58>: mov    0x10(%ebx),%ecx
0x011f8059 <x_draw_glyph_string_background+61>: add    0x4(%ebx),%edx
0x011f805c <x_draw_glyph_string_background+64>: mov    (%ebx),%eax
0x011f805e <x_draw_glyph_string_background+66>: mov    %eax,-0x1c(%ebp)
0x011f8061 <x_draw_glyph_string_background+69>: mov    %edx,-0x18(%ebp)
0x011f8064 <x_draw_glyph_string_background+72>: add    %ecx,%eax
0x011f8066 <x_draw_glyph_string_background+74>: mov    %eax,-0x14(%ebp)
0x011f8069 <x_draw_glyph_string_background+77>: lea    (%esi,%edx,1),%edx
0x011f806c <x_draw_glyph_string_background+80>: mov    %edx,-0x10(%ebp)
0x011f806f <x_draw_glyph_string_background+83>: lea    -0x1c(%ebp),%eax
0x011f8072 <x_draw_glyph_string_background+86>: mov    %eax,0xc(%esp)
0x011f8076 <x_draw_glyph_string_background+90>: mov    0x60(%ebx),%eax
0x011f8079 <x_draw_glyph_string_background+93>: mov    0x4(%eax),%eax
0x011f807c <x_draw_glyph_string_background+96>: mov    %eax,0x8(%esp)
0x011f8080 <x_draw_glyph_string_background+100>:        mov    0x64(%ebx),%eax
0x011f8083 <x_draw_glyph_string_background+103>:        mov    %eax,0x4(%esp)
0x011f8087 <x_draw_glyph_string_background+107>:        mov    0x20(%ebx),%eax
0x011f808a <x_draw_glyph_string_background+110>:        mov    %eax,(%esp)
0x011f808d <x_draw_glyph_string_background+113>:        call
0x11f7642 <w32_fill_rect>
0x011f8092 <x_draw_glyph_string_background+118>:        orb    $0x2,0x5c(%ebx)
0x011f8096 <x_draw_glyph_string_background+122>:        add    $0x2c,%esp
0x011f8099 <x_draw_glyph_string_background+125>:        pop    %ebx
0x011f809a <x_draw_glyph_string_background+126>:        pop    %esi
0x011f809b <x_draw_glyph_string_background+127>:        pop    %edi
0x011f809c <x_draw_glyph_string_background+128>:        pop    %ebp
0x011f809d <x_draw_glyph_string_background+129>:        ret
0x011f809e <x_draw_glyph_string_background+130>:        test   %edi,%edi
0x011f80a0 <x_draw_glyph_string_background+132>:        je
0x11f8096 <x_draw_glyph_string_background+122>
0x011f80a2 <x_draw_glyph_string_background+134>:        jmp
0x11f8056 <x_draw_glyph_string_background+58>
End of assembler dump.

   Juanma

Message #30 received at 1179 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 1179 <at> debbugs.gnu.org
Subject: Re: bug#1179: Emacs on Windows hangs displaying unibyte strings
Date: Fri, 17 Oct 2008 16:01:22 +0200

> Date: Fri, 17 Oct 2008 15:32:47 +0200
> From: "Juanma Barranquero" <lekktu <at> gmail.com>
> Cc: 1179 <1179 <at> emacsbugs.donarmstrong.com>
> 
> On Fri, Oct 17, 2008 at 15:01, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > It doesn't crash for me, with today's CVS.  But the result is strange
> > nonetheless, I think: the single á character in the last line above
> > are replaced with _two_ empty boxes about which "C-u C-x =" says:
> 
> Could you please try with DejaVu Sans Mono?

Tried it, the results are identical to what I reported for the default
font.  Btw, I selected DejaVu Sans Mono via S-mouse-1, in case it
matters.

> I see these four different outputs:
> 
>  - Non-optimized build, Courier New: same as you.
>  - Non-optimized build, DejaVu Sans Mono: the á character is replaced
> by two spaces (not empty boxes) and Emacs hangs.
>  - Optimized build, Courier New: á is replaced by two empty boxes, Emacs hangs.
>  - Optimized build, DejaVu Sans Mono: Emacs crashes at w32term.c:1279.

I use an older GCC (3.4.2), perhaps that's the reason for the
difference.

> (gdb) disassemble 0x011f804c
> Dump of assembler code for function x_draw_glyph_string_background:
> [...]
> 0x011f804c <x_draw_glyph_string_background+48>: cmp    %esi,0x58(%eax)

What's the value of the EAX register ("p/x $eax") at this point?

Message #35 received at 1179 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 1179 <at> debbugs.gnu.org
Subject: Re: bug#1179: Emacs on Windows hangs displaying unibyte strings
Date: Fri, 17 Oct 2008 16:14:55 +0200

On Fri, Oct 17, 2008 at 16:01, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Tried it, the results are identical to what I reported for the default
> font.  Btw, I selected DejaVu Sans Mono via S-mouse-1, in case it
> matters.

I was using

  run -q -fn "DejaVu Sans Mono-10"

from inside gdb. If I start the optimized build with just "run -q" and
use S-mouse-1, I get the second case: two empty boxes, Emacs hangs.

> What's the value of the EAX register ("p/x $eax") at this point?

(gdb) p/x $eax
$1 = 0xe4579102

  Juanma

Message #44 received at 1179 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: 1179 <1179 <at> debbugs.gnu.org>
Subject: Fwd: Reproducible crash with Gnus on Windows.
Date: Tue, 9 Dec 2008 21:12:53 +0100

---------- Forwarded message ----------
From: Óscar Fuentes <ofv <at> wanadoo.es>
Date: Tue, Dec 9, 2008 at 20:18
Subject: Reproducible crash with Gnus on Windows.
To: emacs-devel <at> gnu.org


When I open certain message with Gnus, emacs crashes.

Right now it is impossible for me to track down the error, so I post
some indications here hoping that someone can obtain the needed info for
a real bug report.

Today on

nntp+news.gmane.org:gmane.comp.freedesktop.xorg

there is a message from XuHunt with subject

"RE: compile xorg1.5.2 then startx, mouse and keyboard can not work"

When I open this message, emacs uses 100% cpu usage for several seconds
as it uses to do when finds an "exotic" character and has to look for a
suitable font. Then it shows the message and crashes.

The crash happened on a build from Sep 27. So I updated and built a
fresh emacs and the crash is still there.

--
Oscar

Message #49 received at 1179 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: 1179 <1179 <at> debbugs.gnu.org>
Subject: Fwd: Reproducible crash with Gnus on Windows.
Date: Tue, 9 Dec 2008 21:13:21 +0100

---------- Forwarded message ----------
From: Óscar Fuentes <ofv <at> wanadoo.es>
Date: Tue, Dec 9, 2008 at 20:43
Subject: Re: Reproducible crash with Gnus on Windows.
To: emacs-devel <at> gnu.org


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

> On Tue, Dec 9, 2008 at 20:18, Óscar Fuentes <ofv <at> wanadoo.es> wrote:
>
>> When I open this message, emacs uses 100% cpu usage for several seconds
>> as it uses to do when finds an "exotic" character and has to look for a
>> suitable font. Then it shows the message and crashes.
>>
>> The crash happened on a build from Sep 27. So I updated and built a
>> fresh emacs and the crash is still there.
>
> Could you please run Emacs under GDB and post a backtrace of the crash?

Really, really, really I don't have time for that, but anyways...

Program received signal SIGSEGV, Segmentation fault.
0x0115c9e1 in x_draw_glyph_string (s=0x82e990) at w32term.c:1106
1106      PREPARE_FACE_FOR_DISPLAY (s->f, s->face);
(gdb) bt full
#0  0x0115c9e1 in x_draw_glyph_string (s=0x82e990) at w32term.c:1106
       relief_drawn_p = <value optimized out>
#1  0x0104079a in draw_glyphs (w=0x10890000, x=170, row=0x108925f0,
   area=TEXT_AREA, start=0, end=98, hl=DRAW_NORMAL_TEXT, overlaps=0)
   at xdisp.c:20487
       head = (struct glyph_string *) 0x82eb40
       tail = (struct glyph_string *) 0x82e990
       s = (struct glyph_string *) 0x82e990
       clip_head = (struct glyph_string *) 0x0
       clip_tail = (struct glyph_string *) 0x0
       i = 0
       j = -284161863
       x_reached = 170
       last_x = 990
       area_left = 10
       f = (struct frame *) 0x2d23e00
       hdc = (HDC) 0xae01073d
#2  0x01044ff4 in x_write_glyphs (start=0x108a0000, len=98) at xdisp.c:21896
       x = <value optimized out>
#3  0x010ed0f8 in update_window_line (w=0x10890000, vpos=10,
   mouse_face_overwritten_p=0x82f008) at dispnew.c:4454
       current_row = (struct glyph_row *) 0x108d65f0
       desired_row = (struct glyph_row *) 0x108925f0
       rif = (struct redisplay_interface *) 0x12bd610
       changed_p = 0
#4  0x010ee8f7 in update_window (w=0x10890000, force_p=0) at dispnew.c:4310
       vpos = 2147345108
       i = <value optimized out>
       end = (struct glyph_row *) 0x108934c8
       header_line_row = (struct glyph_row *) 0x0
       changed_p = 1
       mouse_face_overwritten_p = 0
       row = (struct glyph_row *) 0x108925f0
       yb = 504
       desired_matrix = (struct glyph_matrix *) 0x10883400
       paused_p = 0
       rif = (struct redisplay_interface *) 0x12bd610
#5  0x010f09f5 in update_window_tree (w=0x10890000, force_p=0)
   at dispnew.c:4003
       paused_p = <value optimized out>
#6  0x010f09df in update_window_tree (w=0x10861200, force_p=0)
   at dispnew.c:4001
       paused_p = <value optimized out>
#7  0x010f0fd3 in update_frame (f=0x2d23e00, force_p=0, inhibit_hairy_id_p=0)
   at dispnew.c:3930
       paused_p = <value optimized out>
       root_window = (struct window *) 0x10861200
#8  0x01036daa in redisplay_internal (
   preserve_echo_area=<value optimized out>) at xdisp.c:11828
       f = (struct frame *) 0x2d23e00
       tail = <value optimized out>
       frame = <value optimized out>
       w = (struct window *) 0x2d23c00
       pause = 0
       must_finish = 1
       tlbufpos = {charpos = 0, bytepos = 0}
       number_of_visible_frames = 1
       polling_stopped_here = 0
       old_frame = 47332868
       consider_all_windows_p = 1
#9  0x0106b4a7 in read_char (commandflag=1, nmaps=4, maps=0x82fbb0,
   prev_event=45602817, used_mouse_menu=0x82fc44, end_time=0x0)
   at keyboard.c:2649
       c = 45602817
       local_getcjmp = {1542, 1543, 8583944, 18036826, 3696837, 1,
 273930244, 45855249, 273930244, 12352, 8584024, 17925560, 273930240,
 276350269, 8584000, 0}
       save_jump = {271815594, 45654569, 8583896, 16813216, 272132288,
 45602817, 8583912, 18033967, 45778641, 276350269, 8584012, 1457, 619,
 272132293, 2942, 277125932}
       key_already_recorded = 0
       tem = 0
       save = <value optimized out>
       previous_echo_area_message = 45602817
       also_record = 45602817
       reread = 0
       polling_stopped_here = <value optimized out>
       orig_kboard = (struct kboard *) 0x2ff1980
#10 0x0106e0bf in read_key_sequence (keybuf=0x82fce4, bufsize=30,
   prompt=45602817, dont_downcase_last=0, can_return_switch_frame=1,
   fix_current_buffer=1) at keyboard.c:9343
       interrupted_kboard = (KBOARD *) 0x2ff1980
       key = 8584256
       used_mouse_menu = 0
       echo_local_start = 0
       last_real_key_start = 0
       keys_local_start = 0
       local_first_binding = 0
       from_string = 45602817
       count = 2
       t = 0
       echo_start = 0
       keys_start = 0
       nmaps = 4
       nmaps_allocated = 4
       defs = (Lisp_Object * volatile) 0x82fb90
       submaps = (Lisp_Object * volatile) 0x82fbb0
       orig_local_map = 272390749
       orig_keymap = 45602817
       localized_local_map = 0
       first_binding = 0
       first_unbound = 31
       mock_input = 0
       fkey = {parent = 50080373, map = 50080373, start = 0, end = 0}
       keytran = {parent = 45592445, map = 45592445, start = 0, end = 0}
       indec = {parent = 50080381, map = 50080381, start = 0, end = 0}
       shift_translated = 0
       delayed_switch_frame = 45602817
       original_uppercase = 8584332
       original_uppercase_position = -1
       starting_buffer = (struct buffer *) 0x1053d800
       fake_prefixed_keys = 45602817
#11 0x0106ff68 in command_loop_1 () at keyboard.c:1621
       cmd = <value optimized out>
       lose = <value optimized out>
       nonundocount = 0
       keybuf = {104, 1, 8610992, 1, 3082, 0 <repeats 12 times>, 45743104,
 0, 0, 8584520, 8584368, 0, 0, 45602817, 46671281, 46247936, 46247952,
 46247936, 8584552}
       i = <value optimized out>
       prev_modiff = 1144
       prev_buffer = (struct buffer *) 0x1053d800
       already_adjusted = 0
#12 0x01013b98 in internal_condition_case (bfun=0x106fdc4 <command_loop_1>,
   handlers=45666569, hfun=0x106a3fa <cmd_error>) at eval.c:1511
       val = <value optimized out>
       c = {tag = 45602817, val = 45602817, next = 0x82fe2c, gcpro = 0x0,
 jmp = {8584696, 46247936, 46247936, 46247952, 8584556, 16857936, 8585184,
   0, 8584752, 2, 2, 10, 8584664, 16884143, 1520, 0}, backlist = 0x0,
 handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2,
 poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0}
       h = {handler = 45666569, var = 45602817, chosen_clause = 8610992,
 tag = 0x82fd78, next = 0x0}
#13 0x010699c6 in command_loop_2 () at keyboard.c:1338
       val = 0
#14 0x01013c33 in internal_catch (tag=45662641,
   func=0x10699a3 <command_loop_2>, arg=45602817) at eval.c:1247
       c = {tag = 45662641, val = 45602817, next = 0x0, gcpro = 0x0, jmp = {
   8584856, 46247936, 46247936, 46247952, 8584732, 16858150, 8585184, 0,
   16812203, 45883657, 45879706, 45602817, 45641728, 8599512, 0, 45602841},
 backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2,
 poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0}
#15 0x0106a269 in command_loop () at keyboard.c:1317
No locals.
#16 0x0106a585 in recursive_edit_1 () at keyboard.c:942
       val = <value optimized out>
#17 0x0106a6a1 in Frecursive_edit () at keyboard.c:1004
       buffer = 45602817
#18 0x01002d37 in main (argc=1, argv=0xe42cf0) at emacs.c:1781
       dummy = 8585080
       stack_bottom_variable = 120 'x'
       do_initial_setlocale = <value optimized out>
       skip_args = 0
       no_loadup = 0
       junk = 0x0
       dname_arg = 0x0
(gdb)

Please don't ask for the same on a Emacs built on debug mode :-)

--
Oscar

Message #54 received at 1179 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: 1179 <1179 <at> debbugs.gnu.org>
Subject: Fwd: Reproducible crash with Gnus on Windows.
Date: Tue, 9 Dec 2008 21:13:42 +0100

---------- Forwarded message ----------
From: Óscar Fuentes <ofv <at> wanadoo.es>
Date: Tue, Dec 9, 2008 at 21:00
Subject: Re: Reproducible crash with Gnus on Windows.
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: emacs-devel <at> gnu.org


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

> On Tue, Dec 9, 2008 at 20:43, Óscar Fuentes <ofv <at> wanadoo.es> wrote:
>
>> Really, really, really I don't have time for that, but anyways...
>
> I hope you understand that the likelihood of fixing a bug is directly
> related to quality&quantity of information available...

Yes. I reckon you can't reproduce the crash.

[snip]

> Could you at least say how was Emacs compiled (compiler and version)?
> I'd bet 1€ it is a 4.X MinGW GCC.

gcc version 4.2.1-dw2 (mingw32-2)

--
Oscar

Previous Next

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