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

Previous Next

Full log

View this message in rfc822 format

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

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

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

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

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

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

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

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

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

Previous Next

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