bug#872: Crash displaying byte-code

bug#872: Crash displaying byte-code

[Juanma Barranquero]

emacs -Q
M-x ielm <RET>

then typing

(let ((standard-output (current-buffer)))
  (setq unibyte-display-via-language-environment t)
  (set-buffer-multibyte nil)
  (backtrace))

makes Emacs crash on Windows.

Notes:
 - If Emacs is run from inside GDB, it "hangs" for a while and finally
crashes.
 - If run from the command-line, after doing the above it crashes
immediately; the DrMingw backtrace is a bit different.
 - It only happens with an optimized build.
 - All the above steps are required, including executing the `let'
from inside IELM. In fact, the crash happens while IELM is trying to
display byte-code("...")

It apparently started happening after this change:

2008-04-09  Jason Rumney  <address@hidden>

        * w32term.c (w32_compute_glyph_string_overhangs): Compute overhangs
        for new font backend and composite cases.

emacs-devel discussion:

http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00236.html

bug#872: marked as done (Crash displaying byte-code)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 816 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 Crash displaying byte-code
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: 3122 bytes --]

From: "Juanma Barranquero" <lekktu@gmail.com>
To: "Emacs Bug Tracker" <submit@emacsbugs.donarmstrong.com>
Subject: Crash displaying byte-code
Date: Wed, 3 Sep 2008 18:06:12 +0200
Message-ID: <f7ccd24b0809030906y723345abj2a9db4a914f7345b@mail.gmail.com>

emacs -Q
M-x ielm <RET>

then typing

(let ((standard-output (current-buffer)))
  (setq unibyte-display-via-language-environment t)
  (set-buffer-multibyte nil)
  (backtrace))

makes Emacs crash on Windows.

Notes:
 - If Emacs is run from inside GDB, it "hangs" for a while and finally
crashes.
 - If run from the command-line, after doing the above it crashes
immediately; the DrMingw backtrace is a bit different.
 - It only happens with an optimized build.
 - All the above steps are required, including executing the `let'
from inside IELM. In fact, the crash happens while IELM is trying to
display byte-code("...")

It apparently started happening after this change:

2008-04-09  Jason Rumney  <address@hidden>

        * w32term.c (w32_compute_glyph_string_overhangs): Compute overhangs
        for new font backend and composite cases.

emacs-devel discussion:

http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00236.html



[-- 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.

bug#1179: Emacs on Windows hangs displaying unibyte strings

[Juanma Barranquero]

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

bug#1179: Emacs on Windows hangs displaying unibyte strings

[Juanma Barranquero]

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

Processed: Re: bug#1179: Emacs on Windows hangs displaying unibyte strings

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> merge 872 1179
bug#872: Crash displaying byte-code
bug#1179: Emacs on Windows hangs displaying unibyte strings
Warning: Unknown package 'w32'
Warning: Unknown package 'w32'
Merged 872 1179.

> quit
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#1179: Emacs on Windows hangs displaying unibyte strings

[Eli Zaretskii]

> Date: Fri, 17 Oct 2008 13:48:06 +0200
> From: "Juanma Barranquero" <lekktu@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.

bug#1179: Emacs on Windows hangs displaying unibyte strings

[Juanma Barranquero]

On Fri, Oct 17, 2008 at 15:01, Eli Zaretskii <eliz@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

bug#1179: Emacs on Windows hangs displaying unibyte strings

[Eli Zaretskii]

> Date: Fri, 17 Oct 2008 15:32:47 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: 1179 <1179@emacsbugs.donarmstrong.com>
> 
> On Fri, Oct 17, 2008 at 15:01, Eli Zaretskii <eliz@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?

bug#1179: Emacs on Windows hangs displaying unibyte strings

[Juanma Barranquero]

On Fri, Oct 17, 2008 at 16:01, Eli Zaretskii <eliz@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

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

[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.

bug#1446: 23.0.60; GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-11-28 crash on "C-h b"

[Feng li]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Start a new clean emacs instance by invoking "emacs -q". Press "C-x C-f
RET" to open a dired buffer. In the dired buffer, press "C-h b", emacs
crashes immediatelly. I'm running today's CVS HEAD on windows xp.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-11-28 on SCUMBAG
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.2) --cflags -I../../emacs_libs/inc'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  shell-dirtrack-mode: t
  recentf-mode: t
  cua-mode: t
  which-function-mode: t
  show-paren-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
w i t h - g c c SPC - 0 <backspace> 0 c <backspace> 
<backspace> - c f l a g s SPC - I . . / . . / e m a 
c s _ l i b s / i n c <return> <wheel-up> <double-wheel-up> 
<triple-wheel-up> <wheel-up> <C-end> <C-up> <home> 
c m d SPC <return> q <backspace> e x i t <return> <C-up> 
<home> <C-right> <right> - c SPC <return> e x i t <return> 
<C-up> <home> <S-end> <S-delete> c m d SPC - - <backspace> 
<backspace> / ? <return> <prior> <prior> <prior> <prior> 
<prior> <prior> <C-end> <C-up> <C-up> <home> <right> 
<right> <right> <right> <delete> / <end> <return> <wheel-up> 
<double-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-down> 
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down> 
<wheel-up> <double-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<down-mouse-1> <mouse-1> <C-end> <prior> <prior> <C-end> 
<C-up> <C-left> <C-left> <C-left> <C-left> <C-left> 
<C-left> <end> <C-left> <C-left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> - - n o - d e b u g SPC 
<return> <prior> <C-end> <M-up> <M-down> c d SPC . 
. <return> c v s SPC - z 9 SPC - - l f SPC u p <return> 
<prior> <prior> <prior> <next> <next> <C-end> l s <return> 
m a k <backspace> <S-home> <delete> <help-echo> <help-echo> 
<help-echo> <help-echo> C-x 1 <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <menu-bar> <help-menu> <send-emacs-bug-report> 
E m a c s <home> C V S SPC <end> SPC c r a s h SPC 
o n SPC C-g M-x v e r s <tab> <return> C-x b m e s 
<return> <up> <S-end> <C-insert> <C-left> <C-left> 
<C-left> <right> <right> <S-home> <C-insert> C-x b 
m e s <return> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> 
<send-emacs-bug-report>

Recent messages:
Mark set
History item: 128
History item: 127
byte-code: End of buffer
Mark set [2 times]
History item: 128
Mark set [3 times]
Quit
GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-11-28 on SCUMBAG
Mark set

-- 
# Feng Li

# Blackmagic Design
# fengli@blackmagic-design.com
# www.blackmagic-design.com

bug#1446: marked as done (23.0.60; GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-11-28 crash on "C-h b")

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 873 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 23.0.60; GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-11-28 crash on "C-h b"
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: 6111 bytes --]

From: Feng li <fengli@blackmagic-design.com>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-11-28 crash on "C-h b"
Date: Fri, 28 Nov 2008 15:15:32 +1100
Message-ID: <81k5aoscyj.fsf@blackmagic-design.com>


Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Start a new clean emacs instance by invoking "emacs -q". Press "C-x C-f
RET" to open a dired buffer. In the dired buffer, press "C-h b", emacs
crashes immediatelly. I'm running today's CVS HEAD on windows xp.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-11-28 on SCUMBAG
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.2) --cflags -I../../emacs_libs/inc'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  shell-dirtrack-mode: t
  recentf-mode: t
  cua-mode: t
  which-function-mode: t
  show-paren-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
w i t h - g c c SPC - 0 <backspace> 0 c <backspace> 
<backspace> - c f l a g s SPC - I . . / . . / e m a 
c s _ l i b s / i n c <return> <wheel-up> <double-wheel-up> 
<triple-wheel-up> <wheel-up> <C-end> <C-up> <home> 
c m d SPC <return> q <backspace> e x i t <return> <C-up> 
<home> <C-right> <right> - c SPC <return> e x i t <return> 
<C-up> <home> <S-end> <S-delete> c m d SPC - - <backspace> 
<backspace> / ? <return> <prior> <prior> <prior> <prior> 
<prior> <prior> <C-end> <C-up> <C-up> <home> <right> 
<right> <right> <right> <delete> / <end> <return> <wheel-up> 
<double-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-down> 
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down> 
<wheel-up> <double-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<down-mouse-1> <mouse-1> <C-end> <prior> <prior> <C-end> 
<C-up> <C-left> <C-left> <C-left> <C-left> <C-left> 
<C-left> <end> <C-left> <C-left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> - - n o - d e b u g SPC 
<return> <prior> <C-end> <M-up> <M-down> c d SPC . 
. <return> c v s SPC - z 9 SPC - - l f SPC u p <return> 
<prior> <prior> <prior> <next> <next> <C-end> l s <return> 
m a k <backspace> <S-home> <delete> <help-echo> <help-echo> 
<help-echo> <help-echo> C-x 1 <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <menu-bar> <help-menu> <send-emacs-bug-report> 
E m a c s <home> C V S SPC <end> SPC c r a s h SPC 
o n SPC C-g M-x v e r s <tab> <return> C-x b m e s 
<return> <up> <S-end> <C-insert> <C-left> <C-left> 
<C-left> <right> <right> <S-home> <C-insert> C-x b 
m e s <return> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> 
<send-emacs-bug-report>

Recent messages:
Mark set
History item: 128
History item: 127
byte-code: End of buffer
Mark set [2 times]
History item: 128
Mark set [3 times]
Quit
GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-11-28 on SCUMBAG
Mark set

-- 
# Feng Li

# Blackmagic Design
# fengli@blackmagic-design.com
# www.blackmagic-design.com



[-- 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.

bug#1447: 23.0.60; emacs crash

[Feng li]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Start emacs by running "emacs -q". Press "C-h b" to show the
key-binding list. Switch to the help window, press PgDn a few times
and Emacs will crash.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-11-28 on SCUMBAG
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.2) --cflags -I../../emacs_libs/inc'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  recentf-mode: t
  cua-mode: t
  which-function-mode: t
  show-paren-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <menu-bar> <help-menu> <send-emacs-bug
-report>

Recent messages:
Setting up ede...done
Setting up speedbar...done
Setting up cogre...done
Setting up cedet-contrib...done
Loading cua-base...done
Loading ido...done
Loading recentf...done
Loading c:/Documents and Settings/fengli/.recentf...done
Ido mode enabled
For information about GNU Emacs and the GNU system, type C-h C-a.

-- 
# Feng Li

# Blackmagic Design
# fengli@blackmagic-design.com
# www.blackmagic-design.com

bug#1447: marked as done (23.0.60; emacs crash)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 810 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 23.0.60; emacs crash
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: 4245 bytes --]

From: Feng li <fengli@blackmagic-design.com>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; emacs crash
Date: Fri, 28 Nov 2008 15:33:25 +1100
Message-ID: <81zljkbhbe.fsf@blackmagic-design.com>


Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Start emacs by running "emacs -q". Press "C-h b" to show the
key-binding list. Switch to the help window, press PgDn a few times
and Emacs will crash.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-11-28 on SCUMBAG
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.2) --cflags -I../../emacs_libs/inc'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  recentf-mode: t
  cua-mode: t
  which-function-mode: t
  show-paren-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <menu-bar> <help-menu> <send-emacs-bug
-report>

Recent messages:
Setting up ede...done
Setting up speedbar...done
Setting up cogre...done
Setting up cedet-contrib...done
Loading cua-base...done
Loading ido...done
Loading recentf...done
Loading c:/Documents and Settings/fengli/.recentf...done
Ido mode enabled
For information about GNU Emacs and the GNU system, type C-h C-a.

-- 
# Feng Li

# Blackmagic Design
# fengli@blackmagic-design.com
# www.blackmagic-design.com



[-- 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.

bug#1448: 23.0.60; update to cvs emacs crash report

[Feng li]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Start emacs with "-q". Press "C-h b" to bring up the keybinding
help. Switch to the keybinding help window and press "PgDn" a few times
will cause emacs to crash.

I have rebuilt a new emacs binary with debug info and attached the back
trace of the crash location at below.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/emacs/etc/DEBUG for instructions.

Current directory is c:/emacs/bin/
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) set args "-q"
(gdb) r
Starting program: c:\emacs\bin/emacs.exe "-q"
Loaded symbols for C:\WINDOWS\system32\ntdll.dll
Loaded symbols for C:\WINDOWS\system32\kernel32.dll
Loaded symbols for C:\WINDOWS\system32\advapi32.dll
Loaded symbols for C:\WINDOWS\system32\rpcrt4.dll
Loaded symbols for C:\WINDOWS\system32\secur32.dll
Loaded symbols for C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll
Loaded symbols for C:\WINDOWS\system32\msvcrt.dll
Loaded symbols for C:\WINDOWS\system32\gdi32.dll
Loaded symbols for C:\WINDOWS\system32\user32.dll
Loaded symbols for C:\WINDOWS\system32\shlwapi.dll
Loaded symbols for C:\WINDOWS\system32\comdlg32.dll
Loaded symbols for C:\WINDOWS\system32\shell32.dll
Loaded symbols for C:\WINDOWS\system32\mpr.dll
Loaded symbols for C:\WINDOWS\system32\ole32.dll
Loaded symbols for C:\WINDOWS\system32\usp10.dll
Loaded symbols for C:\WINDOWS\system32\winmm.dll
Loaded symbols for C:\WINDOWS\system32\winspool.drv

Program received signal SIGSEGV, Segmentation fault.
0x0101fdd5 in fill_glyph_string (s=0x820000, face_id=27, start=<value optimized out>, end=<value optimized out>, overlaps=<value optimized out>) at xdisp.c:19740
(gdb) bt full
#0  0x0101fdd5 in fill_glyph_string (s=0x820000, face_id=27, start=<value optimized out>, end=<value optimized out>, overlaps=<value optimized out>) at xdisp.c:19740
	glyph = (struct glyph *) 0x334f120
	last = (struct glyph *) 0x334f3c0
	voffset = 0
	glyph_not_available_p = 0
#1  0x01040a0c in draw_glyphs (w=0x3439800, x=72, row=0x3345260, area=TEXT_AREA, start=0, end=30, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20332
	base_face = (struct face *) 0xf00021
	char2b = <value optimized out>
	cmp = <value optimized out>
	first_s = (struct glyph_string *) 0x100000
	n = <value optimized out>
	first_glyph = <value optimized out>
	head = (struct glyph_string *) 0x82eb40
	tail = (struct glyph_string *) 0x82ea20
	s = (struct glyph_string *) 0x0
	clip_head = <value optimized out>
	clip_tail = <value optimized out>
	i = 8
	j = <value optimized out>
	x_reached = <value optimized out>
	last_x = 648
	area_left = 8
	f = (struct frame *) 0x2d26600
	hdc = (HDC) 0x500110bc
#2  0x01044f61 in x_write_glyphs (start=0x334f000, len=30) at xdisp.c:21896
	x = <value optimized out>
#3  0x010ed18d in update_window_line (w=0x3439800, vpos=4, mouse_face_overwritten_p=0x82f008) at dispnew.c:4603
	current_row = (struct glyph_row *) 0x3397260
	desired_row = (struct glyph_row *) 0x3345260
	rif = (struct redisplay_interface *) 0x12bd710
	changed_p = 0
#4  0x010ee614 in update_window (w=0x3439800, force_p=0) at dispnew.c:4310
	tm = {
  tv_sec = 1227849103, 
  tv_usec = 187000
}
	vpos = 0
	i = <value optimized out>
	end = (struct glyph_row *) 0x3346398
	header_line_row = (struct glyph_row *) 0x0
	changed_p = 1
	mouse_face_overwritten_p = 0
	row = (struct glyph_row *) 0x3345260
	yb = 304
	desired_matrix = (struct glyph_matrix *) 0x333e400
	paused_p = 8580796
	rif = (struct redisplay_interface *) 0x12bd710
#5  0x010f0714 in update_window_tree (w=0x3439800, force_p=0) at dispnew.c:4003
	paused_p = <value optimized out>
#6  0x010f06fe in update_window_tree (w=0x3439400, force_p=0) at dispnew.c:4001
	paused_p = <value optimized out>
#7  0x010f0cf3 in update_frame (f=0x2d26600, force_p=0, inhibit_hairy_id_p=0) at dispnew.c:3930
	tm = {
  tv_sec = 1227849103, 
  tv_usec = 187000
}
	p = -nan(0x8000000000000)
	sec = 51984384
	usec = <value optimized out>
	paused_p = <value optimized out>
	root_window = (struct window *) 0x3439400
#8  0x010378b4 in redisplay_internal (preserve_echo_area=<value optimized out>) at xdisp.c:11891
	mini_window = <value optimized out>
	mini_frame = <value optimized out>
	w = (struct window *) 0x3439800
	pause = <value optimized out>
	must_finish = 1
	tlbufpos = {
  charpos = 0, 
  bytepos = 0
}
	number_of_visible_frames = 1
	polling_stopped_here = 0
	old_frame = 47343108
	consider_all_windows_p = 0
#9  0x0106b456 in read_char (commandflag=1, nmaps=3, maps=0x82fbb0, prev_event=45590529, used_mouse_menu=0x82fc44, end_time=0x0) at keyboard.c:2649
	keys = 45590529
	key_count = <value optimized out>
	key_count_reset = 45590529
	saved_ok_to_echo = (struct kboard *) 0x82faa0
	saved_echo_string = 51982336
	c = 45590529
	local_getcjmp =   {524,
  525,
  8583944,
  18038426,
  2,
  1,
  51982340,
  45842961,
  51982340,
  4208,
  8584024,
  17924685,
  51982336,
  49875565,
  8584000,
  0}
	save_jump =   {0,
  -1,
  0,
  8583936,
  8583937,
  45624064,
  8583912,
  17296387,
  54484181,
  54484205,
  8584012,
  11000,
  3667,
  54484189,
  19635,
  51773440}
	key_already_recorded = 0
	tem = 51982336
	save = <value optimized out>
	previous_echo_area_message = 45590529
	also_record = 45590529
	reread = 0
	polling_stopped_here = <value optimized out>
	orig_kboard = (struct kboard *) 0x3000d80
#10 0x0106e08f in read_key_sequence (keybuf=0x82fce4, bufsize=30, prompt=45590529, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9344
	interrupted_kboard = (KBOARD *) 0x3000d80
	key = 54993268
	used_mouse_menu = 0
	echo_local_start = 0
	last_real_key_start = 0
	keys_local_start = 0
	local_first_binding = 0
	from_string = 45590529
	count = 2
	t = 0
	echo_start = 0
	keys_start = 0
	nmaps = 3
	nmaps_allocated = 3
	defs = (Lisp_Object * volatile) 0x82fb90
	submaps = (Lisp_Object * volatile) 0x82fbb0
	orig_local_map = 49879613
	orig_keymap = 45590529
	localized_local_map = 0
	first_binding = 0
	first_unbound = 31
	mock_input = 0
	fkey = {
  parent = 46299045, 
  map = 46299045, 
  start = 0, 
  end = 0
}
	keytran = {
  parent = 45580157, 
  map = 45580157, 
  start = 0, 
  end = 0
}
	indec = {
  parent = 46299221, 
  map = 46299221, 
  start = 0, 
  end = 0
}
	shift_translated = 0
	delayed_switch_frame = 45590529
	original_uppercase = 8584332
	original_uppercase_position = -1
	starting_buffer = (struct buffer *) 0x3193000
	fake_prefixed_keys = 45590529
#11 0x0106ff38 in command_loop_1 () at keyboard.c:1621
	cmd = <value optimized out>
	lose = 4356
	nonundocount = 0
	keybuf =   {45968033,
  888,
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  84,
  0,
  234881024,
  84,
  33689241,
  0,
  13,
  33689241,
  0,
  -402653185,
  0,
  8584520,
  8584368,
  0,
  33685504,
  45590529,
  46654801,
  46227456,
  46227472,
  46227456,
  8584552}
	i = 4356
	prev_modiff = 4356
	prev_buffer = (struct buffer *) 0x3193000
	already_adjusted = 0
#12 0x01013b58 in internal_condition_case (bfun=0x106fd94 <command_loop_1>, handlers=45654281, hfun=0x106a3ac <cmd_error>) at eval.c:1511
	val = <value optimized out>
	c = {
  tag = 45590529, 
  val = 45590529, 
  next = 0x82fe2c, 
  gcpro = 0x0, 
  jmp =     {8584696,
    46227456,
    46227456,
    46227472,
    8584556,
    16857872,
    8585184,
    0,
    8584632,
    16873592,
    0,
    10,
    0,
    16884063,
    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 = 45654281, 
  var = 45590529, 
  chosen_clause = 2, 
  tag = 0x82fd78, 
  next = 0x0
}
#13 0x01069976 in command_loop_2 () at keyboard.c:1338
	val = 0
#14 0x01013bf3 in internal_catch (tag=45650353, func=0x1069953 <command_loop_2>, arg=45590529) at eval.c:1247
	c = {
  tag = 45650353, 
  val = 45590529, 
  next = 0x0, 
  gcpro = 0x0, 
  jmp =     {8584856,
    46227456,
    46227456,
    46227472,
    8584732,
    16858086,
    8585184,
    0,
    16812203,
    45871369,
    45870490,
    45590529,
    45629440,
    8726632,
    2009473784,
    45590553}, 
  backlist = 0x0, 
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 0, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
#15 0x0106a21b in command_loop () at keyboard.c:1317
No locals.
#16 0x0106a537 in recursive_edit_1 () at keyboard.c:942
	val = <value optimized out>
#17 0x0106a653 in Frecursive_edit () at keyboard.c:1004
	buffer = 45590529
#18 0x01002d37 in main (argc=2, argv=0xa44e68) at emacs.c:1777
	old_log_max = <value optimized out>
	symbol = <value optimized out>
	tail = <value optimized out>
	inhibit_unibyte = <value optimized out>
	dummy = 2009288258
	stack_bottom_variable = 1 '\001'
	do_initial_setlocale = <value optimized out>
	skip_args = 0
	no_loadup = 0
	junk = 0x0
	dname_arg = 0x0
(gdb) xbacktrace
(gdb) 

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-11-28 on SCUMBAG
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.2) --cflags -I../../emacs_libs/inc'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
  shell-dirtrack-mode: t
  recentf-mode: t
  cua-mode: t
  which-function-mode: t
  show-paren-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x C-f <C-S-left> <C-S-left> <C-S-left> <C-S-left> 
d e v <tab> <C-S-left> e m a c s / b i n <tab> <return> 
<C-end> M-x g d b <return> <return> s e t SPC a r g 
s SPC " " <left> - q <return> r <return> b t SPC f 
u l l <return> x b a c k t r a c e <return> <prior> 
<prior> <prior> <prior> <prior> <prior> <prior> <prior> 
<prior> <prior> <prior> <prior> <prior> <prior> <prior> 
<prior> <prior> <prior> <C-end> <C-end> <C-home> <next> 
<C-end> C-x h <C-insert> <down-mouse-1> <mouse-1> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <send-emacs-bug-report>

Recent messages:
Loading c:/Documents and Settings/fengli/.recentf...done
Ido mode enabled
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
Truncate long lines enabled
Loading semanticdb-file...done
Loading vc-cvs...done
Mark set [23 times]
cua-scroll-down: Beginning of buffer [5 times]
Mark set [6 times]

-- 
# Feng Li

# Blackmagic Design
# fengli@blackmagic-design.com
# www.blackmagic-design.com

bug#1448: 23.0.60; update to cvs emacs crash report

[Juanma Barranquero]

merge 872 1446 1447 1448
quit

On Fri, Nov 28, 2008 at 06:15, Feng li <fengli@blackmagic-design.com> wrote:

> Start emacs with "-q". Press "C-h b" to bring up the keybinding
> help. Switch to the keybinding help window and press "PgDn" a few times
> will cause emacs to crash.
>
> I have rebuilt a new emacs binary with debug info and attached the back
> trace of the crash location at below.

What you're seeing is bug#872 (also #1179).

I originally thought it depended on
`display-unibyte-via-language-environment', but it is not so; I've
seen it (and suffered it) through several different incarnations.

What they all have in common:

 - Using a "recent" MinGW GCC (4.2.1, 4.3.0-alpha, etc.)
 - Compiling with optimization
 - Trying to display unibyte (or, perhaps, some composed characters,
I'm not sure)
 - It *always* happens when draw_glyphs is running
 - It mostly happens in fill_glyph_string

I can reproduce it at will in a lot of ways, for example:

  M-x ucs-insert AEGEAN CHECK MARK <RET>

or

  (let ((my-map (make-keymap)))
    (suppress-keymap my-map)
    (substitute-command-keys "\\{my-map}"))

or having `display-unibyte-via-language-environment' set to t and
`debug' being called for whatever reason, etc. etc.

I've been trying to debug it, without success (it doesn't help that I
know very little about the glyph handling code). I'm not even sure
whether it is a compiler bug, or a bug in Emacs (it happens in code
that was undergoing changes quite recently).

  Juanma

bug#1448: 23.0.60; update to cvs emacs crash report

[Eli Zaretskii]

> Date: Fri, 28 Nov 2008 10:25:09 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: 1448@emacsbugs.donarmstrong.com
> 
> What you're seeing is bug#872 (also #1179).
> 
> I originally thought it depended on
> `display-unibyte-via-language-environment', but it is not so; I've
> seen it (and suffered it) through several different incarnations.
> 
> What they all have in common:
> 
>  - Using a "recent" MinGW GCC (4.2.1, 4.3.0-alpha, etc.)
>  - Compiling with optimization

Now I understand why I cannot reproduce this: I never bothered to
upgrade to GCC 4.x.

>  - Trying to display unibyte (or, perhaps, some composed characters,
> I'm not sure)

How does "C-h b" get to display unibyte or composed characters?

> I've been trying to debug it, without success (it doesn't help that I
> know very little about the glyph handling code). I'm not even sure
> whether it is a compiler bug, or a bug in Emacs (it happens in code
> that was undergoing changes quite recently).

Is it a Heisenbug? i.e., does it disappear if you add printf's around
the code that crashes or in its callers?

If the bug stays put when code around it is modified, you could try
debugging it by adding "if (something) abort ();" lines testing
various conditions that are suspect of causing the crash.

Some observations based on the traceback posted by Feng Li:

> Program received signal SIGSEGV, Segmentation fault.
> 0x0101fdd5 in fill_glyph_string (s=0x820000, face_id=27, start=<value optimized out>, end=<value optimized out>, overlaps=<value optimized out>) at xdisp.c:19740

Line 19740 in xdisp.c is this:

  s->ybase += voffset;

And "bt full" says this about `s':

> 	s = (struct glyph_string *) 0x0

However, `s' is dereferenced many times in `fill_glyph_string' before
it gets to line 19740, so I think GDB lies about the place where it
crashed (because GCC optimizes code to the degree that any relation
between the code and the source lines is lost).

Therefore, the first thing to do is disassembly the vicinity of the
crash locus (0x0101fdd5) and see which code, exactly, crashes, and
why.  Disassembly should establish (1) the source line that crashes,
and (2) which C-level variable causes the crash.

Note that `s' is allocated via `alloca' in BUILD_CHAR_GLYPH_STRINGS,
which is called by BUILD_GLYPH_STRINGS, which in turn is called by
`draw_glyphs' at line 20332 in frame #1:

> #1  0x01040a0c in draw_glyphs (w=0x3439800, x=72, row=0x3345260, area=TEXT_AREA, start=0, end=30, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20332

The original source line 20332 in xdisp.c looks like this:

  BUILD_GLYPH_STRINGS (i, end, head, tail, hl, x, last_x);

bug#1448: 23.0.60; update to cvs emacs crash report

[Juanma Barranquero]

On Fri, Nov 28, 2008 at 11:56, Eli Zaretskii <eliz@gnu.org> wrote:

> How does "C-h b" get to display unibyte or composed characters?

In a keymap case I found, Emacs crashed while trying to display \200.
But I could be wrong (again) about what exactly triggers the crash.

> Is it a Heisenbug? i.e., does it disappear if you add printf's around
> the code that crashes or in its callers?

Not exactly a heisenbug, because it does not disappear. It moves.
That's why I've said that it always fails with draw_glyphs in the
stack, but not always in fill_glyph_string.

> If the bug stays put when code around it is modified, you could try
> debugging it by adding "if (something) abort ();" lines testing
> various conditions that are suspect of causing the crash.

I've tried that (well, I added xassert() and/or eassert) at likely
places; they didn't get triggered.

> However, `s' is dereferenced many times in `fill_glyph_string' before
> it gets to line 19740, so I think GDB lies about the place where it
> crashed (because GCC optimizes code to the degree that any relation
> between the code and the source lines is lost).

Yes, I agree that GDB lies. If only the bug happened with non-optimized code...

> Therefore, the first thing to do is disassembly the vicinity of the
> crash locus (0x0101fdd5) and see which code, exactly, crashes, and
> why.  Disassembly should establish (1) the source line that crashes,
> and (2) which C-level variable causes the crash.

I'll try to do that.

> Note that `s' is allocated via `alloca' in BUILD_CHAR_GLYPH_STRINGS,
> which is called by BUILD_GLYPH_STRINGS, which in turn is called by
> `draw_glyphs' at line 20332 in frame #1:

Sorry, I fail to understand what you are trying to say. I've suspected
that alloca'd memory is related to the crash, but I don't see how.

  Juanma

bug#1448: 23.0.60; update to cvs emacs crash report

[Eli Zaretskii]

> Date: Fri, 28 Nov 2008 12:23:33 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: 1448@emacsbugs.donarmstrong.com, "Feng li" <fengli@blackmagic-design.com>
> 
> > Note that `s' is allocated via `alloca' in BUILD_CHAR_GLYPH_STRINGS,
> > which is called by BUILD_GLYPH_STRINGS, which in turn is called by
> > `draw_glyphs' at line 20332 in frame #1:
> 
> Sorry, I fail to understand what you are trying to say.

I was just trying to add more info about where `s' comes from.  Since
it comes from a call to `alloca', which is a compiler built-in with
GCC, it could be a compiler bug

> I've suspected that alloca'd memory is related to the crash, but I
> don't see how.

Neither do I.

bug#1448: 23.0.60; update to cvs emacs crash report

[Juanma Barranquero]

On Fri, Nov 28, 2008 at 13:06, Eli Zaretskii <eliz@gnu.org> wrote:

> Since
> it comes from a call to `alloca', which is a compiler built-in with
> GCC, it could be a compiler bug

Ah, of course! Thanks.

   Juanma

bug#1448: 23.0.60; update to cvs emacs crash report

[Feng Li]

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

> I've been trying to debug it, without success (it doesn't help that I
> know very little about the glyph handling code). I'm not even sure
> whether it is a compiler bug, or a bug in Emacs (it happens in code
> that was undergoing changes quite recently).
>

I doubt this is a compiler bug because it did not happen in my previous
Emacs build which is compiled with the same compiler in October.

-- 
# Feng Li

bug#1448: 23.0.60; update to cvs emacs crash report

[Juanma Barranquero]

On Sun, Nov 30, 2008 at 23:11, Feng Li <fengli@blackmagic-design.com> wrote:

> I doubt this is a compiler bug because it did not happen in my previous
> Emacs build which is compiled with the same compiler in October.

It also started suddenly for me, after some big changes related (I
think) to character composition.

But that does not mean that it could not be a compiler bug: perhaps
the new code triggers the bug, and the old code didn't.

That said, my gut feeling is that is not a compiler bug because I'm
getting it with two compilers, 4.2.1 and 4.3.0, but it is not
impossible that such a bug, if it is specific to the MinGW port, could
go undetected between releases.

  Juanma

bug#1448: 23.0.60; update to cvs emacs crash report

[Feng Li]

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

> On Sun, Nov 30, 2008 at 23:11, Feng Li <fengli@blackmagic-design.com> wrote:
>
>> I doubt this is a compiler bug because it did not happen in my previous
>> Emacs build which is compiled with the same compiler in October.
>
> It also started suddenly for me, after some big changes related (I
> think) to character composition.
>
> But that does not mean that it could not be a compiler bug: perhaps
> the new code triggers the bug, and the old code didn't.
>
> That said, my gut feeling is that is not a compiler bug because I'm
> getting it with two compilers, 4.2.1 and 4.3.0, but it is not
> impossible that such a bug, if it is specific to the MinGW port, could
> go undetected between releases.
>
>   Juanma
>

I can confirm this bug happens for msvc2003 builds too.

And just like the mingw build, "C-h b" then scroll down will crash emacs
100% of the time.

-- 
# Feng Li

# Blackmagic Design
# fengli@blackmagic-design.com
# www.blackmagic-design.com

bug#1448: 23.0.60; update to cvs emacs crash report

[Juanma Barranquero]

On Thu, Dec 4, 2008 at 03:47, Feng Li <fengli@blackmagic-design.com> wrote:

> I can confirm this bug happens for msvc2003 builds too.

That's good news, of a sort. We can discard the GCC bug hypothesis.

Now, it would be great to know why does it happen only on Windows.

    Juanma

bug#1448: 23.0.60; update to cvs emacs crash report

[Stefan Monnier]

>> I can confirm this bug happens for msvc2003 builds too.
> That's good news, of a sort. We can discard the GCC bug hypothesis.
> Now, it would be great to know why does it happen only on Windows.

The description of the bug makes me think it may have to do with the
font code.  E.g. when you scroll C-h b you may end up displaying
something like the character #x3fff7f.


        Stefan

bug#1448: 23.0.60; update to cvs emacs crash report

[Juanma Barranquero]

On Thu, Dec 4, 2008 at 14:31, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The description of the bug makes me think it may have to do with the
> font code.

Crash is always in the call stack after draw_glyphs, so yes.

Whatever the reason, it appeared on or before 2008-08-05.

    Juanma

bug#1448: marked as done (23.0.60; update to cvs emacs crash report)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 831 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 23.0.60; update to cvs emacs crash report
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: 13872 bytes --]

From: Feng li <fengli@blackmagic-design.com>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; update to cvs emacs crash report
Date: Fri, 28 Nov 2008 16:15:49 +1100
Message-ID: <81hc5s5t2y.fsf@blackmagic-design.com>


Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Start emacs with "-q". Press "C-h b" to bring up the keybinding
help. Switch to the keybinding help window and press "PgDn" a few times
will cause emacs to crash.

I have rebuilt a new emacs binary with debug info and attached the back
trace of the crash location at below.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/emacs/etc/DEBUG for instructions.

Current directory is c:/emacs/bin/
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) set args "-q"
(gdb) r
Starting program: c:\emacs\bin/emacs.exe "-q"
Loaded symbols for C:\WINDOWS\system32\ntdll.dll
Loaded symbols for C:\WINDOWS\system32\kernel32.dll
Loaded symbols for C:\WINDOWS\system32\advapi32.dll
Loaded symbols for C:\WINDOWS\system32\rpcrt4.dll
Loaded symbols for C:\WINDOWS\system32\secur32.dll
Loaded symbols for C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll
Loaded symbols for C:\WINDOWS\system32\msvcrt.dll
Loaded symbols for C:\WINDOWS\system32\gdi32.dll
Loaded symbols for C:\WINDOWS\system32\user32.dll
Loaded symbols for C:\WINDOWS\system32\shlwapi.dll
Loaded symbols for C:\WINDOWS\system32\comdlg32.dll
Loaded symbols for C:\WINDOWS\system32\shell32.dll
Loaded symbols for C:\WINDOWS\system32\mpr.dll
Loaded symbols for C:\WINDOWS\system32\ole32.dll
Loaded symbols for C:\WINDOWS\system32\usp10.dll
Loaded symbols for C:\WINDOWS\system32\winmm.dll
Loaded symbols for C:\WINDOWS\system32\winspool.drv

Program received signal SIGSEGV, Segmentation fault.
0x0101fdd5 in fill_glyph_string (s=0x820000, face_id=27, start=<value optimized out>, end=<value optimized out>, overlaps=<value optimized out>) at xdisp.c:19740
(gdb) bt full
#0  0x0101fdd5 in fill_glyph_string (s=0x820000, face_id=27, start=<value optimized out>, end=<value optimized out>, overlaps=<value optimized out>) at xdisp.c:19740
	glyph = (struct glyph *) 0x334f120
	last = (struct glyph *) 0x334f3c0
	voffset = 0
	glyph_not_available_p = 0
#1  0x01040a0c in draw_glyphs (w=0x3439800, x=72, row=0x3345260, area=TEXT_AREA, start=0, end=30, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20332
	base_face = (struct face *) 0xf00021
	char2b = <value optimized out>
	cmp = <value optimized out>
	first_s = (struct glyph_string *) 0x100000
	n = <value optimized out>
	first_glyph = <value optimized out>
	head = (struct glyph_string *) 0x82eb40
	tail = (struct glyph_string *) 0x82ea20
	s = (struct glyph_string *) 0x0
	clip_head = <value optimized out>
	clip_tail = <value optimized out>
	i = 8
	j = <value optimized out>
	x_reached = <value optimized out>
	last_x = 648
	area_left = 8
	f = (struct frame *) 0x2d26600
	hdc = (HDC) 0x500110bc
#2  0x01044f61 in x_write_glyphs (start=0x334f000, len=30) at xdisp.c:21896
	x = <value optimized out>
#3  0x010ed18d in update_window_line (w=0x3439800, vpos=4, mouse_face_overwritten_p=0x82f008) at dispnew.c:4603
	current_row = (struct glyph_row *) 0x3397260
	desired_row = (struct glyph_row *) 0x3345260
	rif = (struct redisplay_interface *) 0x12bd710
	changed_p = 0
#4  0x010ee614 in update_window (w=0x3439800, force_p=0) at dispnew.c:4310
	tm = {
  tv_sec = 1227849103, 
  tv_usec = 187000
}
	vpos = 0
	i = <value optimized out>
	end = (struct glyph_row *) 0x3346398
	header_line_row = (struct glyph_row *) 0x0
	changed_p = 1
	mouse_face_overwritten_p = 0
	row = (struct glyph_row *) 0x3345260
	yb = 304
	desired_matrix = (struct glyph_matrix *) 0x333e400
	paused_p = 8580796
	rif = (struct redisplay_interface *) 0x12bd710
#5  0x010f0714 in update_window_tree (w=0x3439800, force_p=0) at dispnew.c:4003
	paused_p = <value optimized out>
#6  0x010f06fe in update_window_tree (w=0x3439400, force_p=0) at dispnew.c:4001
	paused_p = <value optimized out>
#7  0x010f0cf3 in update_frame (f=0x2d26600, force_p=0, inhibit_hairy_id_p=0) at dispnew.c:3930
	tm = {
  tv_sec = 1227849103, 
  tv_usec = 187000
}
	p = -nan(0x8000000000000)
	sec = 51984384
	usec = <value optimized out>
	paused_p = <value optimized out>
	root_window = (struct window *) 0x3439400
#8  0x010378b4 in redisplay_internal (preserve_echo_area=<value optimized out>) at xdisp.c:11891
	mini_window = <value optimized out>
	mini_frame = <value optimized out>
	w = (struct window *) 0x3439800
	pause = <value optimized out>
	must_finish = 1
	tlbufpos = {
  charpos = 0, 
  bytepos = 0
}
	number_of_visible_frames = 1
	polling_stopped_here = 0
	old_frame = 47343108
	consider_all_windows_p = 0
#9  0x0106b456 in read_char (commandflag=1, nmaps=3, maps=0x82fbb0, prev_event=45590529, used_mouse_menu=0x82fc44, end_time=0x0) at keyboard.c:2649
	keys = 45590529
	key_count = <value optimized out>
	key_count_reset = 45590529
	saved_ok_to_echo = (struct kboard *) 0x82faa0
	saved_echo_string = 51982336
	c = 45590529
	local_getcjmp =   {524,
  525,
  8583944,
  18038426,
  2,
  1,
  51982340,
  45842961,
  51982340,
  4208,
  8584024,
  17924685,
  51982336,
  49875565,
  8584000,
  0}
	save_jump =   {0,
  -1,
  0,
  8583936,
  8583937,
  45624064,
  8583912,
  17296387,
  54484181,
  54484205,
  8584012,
  11000,
  3667,
  54484189,
  19635,
  51773440}
	key_already_recorded = 0
	tem = 51982336
	save = <value optimized out>
	previous_echo_area_message = 45590529
	also_record = 45590529
	reread = 0
	polling_stopped_here = <value optimized out>
	orig_kboard = (struct kboard *) 0x3000d80
#10 0x0106e08f in read_key_sequence (keybuf=0x82fce4, bufsize=30, prompt=45590529, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9344
	interrupted_kboard = (KBOARD *) 0x3000d80
	key = 54993268
	used_mouse_menu = 0
	echo_local_start = 0
	last_real_key_start = 0
	keys_local_start = 0
	local_first_binding = 0
	from_string = 45590529
	count = 2
	t = 0
	echo_start = 0
	keys_start = 0
	nmaps = 3
	nmaps_allocated = 3
	defs = (Lisp_Object * volatile) 0x82fb90
	submaps = (Lisp_Object * volatile) 0x82fbb0
	orig_local_map = 49879613
	orig_keymap = 45590529
	localized_local_map = 0
	first_binding = 0
	first_unbound = 31
	mock_input = 0
	fkey = {
  parent = 46299045, 
  map = 46299045, 
  start = 0, 
  end = 0
}
	keytran = {
  parent = 45580157, 
  map = 45580157, 
  start = 0, 
  end = 0
}
	indec = {
  parent = 46299221, 
  map = 46299221, 
  start = 0, 
  end = 0
}
	shift_translated = 0
	delayed_switch_frame = 45590529
	original_uppercase = 8584332
	original_uppercase_position = -1
	starting_buffer = (struct buffer *) 0x3193000
	fake_prefixed_keys = 45590529
#11 0x0106ff38 in command_loop_1 () at keyboard.c:1621
	cmd = <value optimized out>
	lose = 4356
	nonundocount = 0
	keybuf =   {45968033,
  888,
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  84,
  0,
  234881024,
  84,
  33689241,
  0,
  13,
  33689241,
  0,
  -402653185,
  0,
  8584520,
  8584368,
  0,
  33685504,
  45590529,
  46654801,
  46227456,
  46227472,
  46227456,
  8584552}
	i = 4356
	prev_modiff = 4356
	prev_buffer = (struct buffer *) 0x3193000
	already_adjusted = 0
#12 0x01013b58 in internal_condition_case (bfun=0x106fd94 <command_loop_1>, handlers=45654281, hfun=0x106a3ac <cmd_error>) at eval.c:1511
	val = <value optimized out>
	c = {
  tag = 45590529, 
  val = 45590529, 
  next = 0x82fe2c, 
  gcpro = 0x0, 
  jmp =     {8584696,
    46227456,
    46227456,
    46227472,
    8584556,
    16857872,
    8585184,
    0,
    8584632,
    16873592,
    0,
    10,
    0,
    16884063,
    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 = 45654281, 
  var = 45590529, 
  chosen_clause = 2, 
  tag = 0x82fd78, 
  next = 0x0
}
#13 0x01069976 in command_loop_2 () at keyboard.c:1338
	val = 0
#14 0x01013bf3 in internal_catch (tag=45650353, func=0x1069953 <command_loop_2>, arg=45590529) at eval.c:1247
	c = {
  tag = 45650353, 
  val = 45590529, 
  next = 0x0, 
  gcpro = 0x0, 
  jmp =     {8584856,
    46227456,
    46227456,
    46227472,
    8584732,
    16858086,
    8585184,
    0,
    16812203,
    45871369,
    45870490,
    45590529,
    45629440,
    8726632,
    2009473784,
    45590553}, 
  backlist = 0x0, 
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 0, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
#15 0x0106a21b in command_loop () at keyboard.c:1317
No locals.
#16 0x0106a537 in recursive_edit_1 () at keyboard.c:942
	val = <value optimized out>
#17 0x0106a653 in Frecursive_edit () at keyboard.c:1004
	buffer = 45590529
#18 0x01002d37 in main (argc=2, argv=0xa44e68) at emacs.c:1777
	old_log_max = <value optimized out>
	symbol = <value optimized out>
	tail = <value optimized out>
	inhibit_unibyte = <value optimized out>
	dummy = 2009288258
	stack_bottom_variable = 1 '\001'
	do_initial_setlocale = <value optimized out>
	skip_args = 0
	no_loadup = 0
	junk = 0x0
	dname_arg = 0x0
(gdb) xbacktrace
(gdb) 

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-11-28 on SCUMBAG
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.2) --cflags -I../../emacs_libs/inc'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
  shell-dirtrack-mode: t
  recentf-mode: t
  cua-mode: t
  which-function-mode: t
  show-paren-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x C-f <C-S-left> <C-S-left> <C-S-left> <C-S-left> 
d e v <tab> <C-S-left> e m a c s / b i n <tab> <return> 
<C-end> M-x g d b <return> <return> s e t SPC a r g 
s SPC " " <left> - q <return> r <return> b t SPC f 
u l l <return> x b a c k t r a c e <return> <prior> 
<prior> <prior> <prior> <prior> <prior> <prior> <prior> 
<prior> <prior> <prior> <prior> <prior> <prior> <prior> 
<prior> <prior> <prior> <C-end> <C-end> <C-home> <next> 
<C-end> C-x h <C-insert> <down-mouse-1> <mouse-1> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <send-emacs-bug-report>

Recent messages:
Loading c:/Documents and Settings/fengli/.recentf...done
Ido mode enabled
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
Truncate long lines enabled
Loading semanticdb-file...done
Loading vc-cvs...done
Mark set [23 times]
cua-scroll-down: Beginning of buffer [5 times]
Mark set [6 times]

-- 
# Feng Li

# Blackmagic Design
# fengli@blackmagic-design.com
# www.blackmagic-design.com



[-- 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.