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.