bug#1179: marked as done (Emacs on Windows hangs displaying unibyte strings)

[don@donarmstrong.com (Emacs bug Tracking System)]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]


Your message dated Thu, 11 Dec 2008 23:42:15 +0800
with message-id <494134D7.9000502@f2s.com>
and subject line Re: [Emacs-diffs] emacs/src ChangeLog
has caused the Emacs bug report #872,
regarding Emacs on Windows hangs displaying unibyte strings
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
872: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=872
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 9654 bytes --]

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

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




[-- Attachment #3: Type: message/rfc822, Size: 4054 bytes --]

From: Jason Rumney <jasonr@f2s.com>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: 872-done@emacsbugs.donarmstrong.com
Subject: Re: [Emacs-diffs] emacs/src ChangeLog
Date: Thu, 11 Dec 2008 23:42:15 +0800
Message-ID: <494134D7.9000502@f2s.com>

Juanma Barranquero wrote:
> It is likely Jason has really fixed the problem, because it started
> happening a few days after this change:
>
> 2008-07-30  Jason Rumney  <jasonr@gnu.org>
>
>         * w32font.h (struct w32font_info): Use unicode version of textmetrics.
>
>         * w32font.c (w32font_encode_char): Leave as unicode if in range.
>         (w32font_open_internal): Get unicode version of textmetrics.
>         Don't enable or disable glyph indices here.
>         (w32font_open): Disable use of glyph indices.
>
>         * w32uniscribe.c (uniscribe_open): Enable use of glyph indices.
>
>   Juanma
>   

More likely one of these earlier changes:

2008-07-30  Jason Rumney  <jasonr@gnu.org>

    * w32uniscribe.c (uniscribe_encode_char): Fix glyph buffer size.

2008-07-29  Jason Rumney  <jasonr@gnu.org>

    * w32uniscribe.c (uniscribe_shape): Avoid using context if cache
    is populated.
    (uniscribe_encode_char): Always use uniscribe.
    Avoid using context if cache is populated.