bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Emacs bug Tracking System
Subject: bug#1179: marked as done (Emacs on Windows hangs displaying unibyte strings)
Date: Thu, 11 Dec 2008 07:45:03 -0800

Your message dated Thu, 11 Dec 2008 23:42:15 +0800
with message-id <address@hidden>
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 address@hidden
immediately.)


-- 
872: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=872
Emacs Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- 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




--- End Message ---
--- Begin Message --- Subject: Re: [Emacs-diffs] emacs/src ChangeLog Date: Thu, 11 Dec 2008 23:42:15 +0800 User-agent: Thunderbird 2.0.0.18 (Windows/20081105)
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  <address@hidden>

        * 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  <address@hidden>

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

2008-07-29  Jason Rumney  <address@hidden>

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





--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]