Crashes on draw_glyphs

Crashes on draw_glyphs

[Juanma Barranquero]

The underling bug that causes #872/#1179 is really getting annoying.

Apparently I'm the only one suffering it (perhaps I'm the only one
compiling Emacs on Windows with GCC 4.3.0), and I've been
unsuccessfully trying to debug it for weeks. Unfortunately, as soon as
I even add an assertion, the crash point moves. It seems like the
thing to do is to run draw_glyphs step-by-step, but with the macros
and all that it is quite difficult, not to mention that I know very
little about the redisplay code and that the bug is much harder to
catch when I compile a non-optimized build.

The breaking point (for my patience, at least) is that I now can crash
Emacs even without setting unibyte-display-via-language-environment,
just by doing

  emacs -Q
  M-x ucs-insert AEGEAN CHECK MARK <return>

which causes an assertion failure.

Any help, pointer, idea, or mojo will be deeply appretiated.

  Juanma


Breakpoint 1, w32_abort () at w32fns.c:7279
7279      button = MessageBox (NULL,
(gdb) bt
#0  w32_abort () at w32fns.c:7279
#1  0x01034045 in fill_glyph_string (s=0x82e8c0, face_id=1,
start=-1151, end=1, overlaps=0) at xdisp.c:19695
#2  0x01057492 in draw_glyphs (w=0x2e44a00, x=17, row=0x2ffb260,
area=TEXT_AREA, start=0, end=1, hl=DRAW_NORMAL_TEXT,
    overlaps=0) at xdisp.c:20329
#3  0x0105a72b in x_write_glyphs (start=0x3029000, len=1) at xdisp.c:21893
#4  0x01160263 in update_window_line (w=0x2e44a00, vpos=4,
mouse_face_overwritten_p=0x82ee7c) at dispnew.c:4594
#5  0x01160824 in update_window (w=0x2e44a00, force_p=0) at dispnew.c:4310
#6  0x01162f71 in update_window_tree (w=0x2e44a00, force_p=0) at dispnew.c:4003
#7  0x01164769 in update_frame (f=0x2e44200, force_p=0,
inhibit_hairy_id_p=0) at dispnew.c:3930
#8  0x010481a2 in redisplay_internal (preserve_echo_area=<value
optimized out>) at xdisp.c:11828
#9  0x0104930e in redisplay_preserve_echo_area (from_where=2) at xdisp.c:12043
#10 0x01159e0f in sit_for (timeout=0, reading=0, do_display=2) at dispnew.c:6609
#11 0x01084352 in Fexecute_extended_command (prefixarg=47908865) at
keyboard.c:10459
#12 0x0101a000 in Ffuncall (nargs=2, args=0x82fab0) at eval.c:3044
#13 0x01149d8d in Fcall_interactively (function=47968905,
record_flag=47908865, keys=47942404) at callint.c:857
#14 0x01019fd6 in Ffuncall (nargs=4, args=0x82fc78) at eval.c:3050
#15 0x0101a258 in call3 (fn=48100449, arg1=47968905, arg2=47908865,
arg3=47908865) at eval.c:2870
#16 0x01096338 in command_loop_1 () at keyboard.c:1880
#17 0x01019316 in internal_condition_case (bfun=0x1095d5f
<command_loop_1>, handlers=47972617,
    hfun=0x108cf97 <cmd_error>) at eval.c:1511
#18 0x0108c42b in command_loop_2 () at keyboard.c:1338
#19 0x010193c0 in internal_catch (tag=47968689, func=0x108c408
<command_loop_2>, arg=47908865) at eval.c:1247
#20 0x0108cde2 in command_loop () at keyboard.c:1317
#21 0x0108d130 in recursive_edit_1 () at keyboard.c:942
#22 0x0108d29b in Frecursive_edit () at keyboard.c:1004
#23 0x01002fb1 in main (argc=2, argv=0xa941e0) at emacs.c:1777

Lisp Backtrace:
"execute-extended-command" (0x82fab4)
"call-interactively" (0x82fc7c)

Re: Crashes on draw_glyphs

[Chong Yidong]

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

> The underling bug that causes #872/#1179 is really getting annoying.
>
> Apparently I'm the only one suffering it (perhaps I'm the only one
> compiling Emacs on Windows with GCC 4.3.0), and I've been
> unsuccessfully trying to debug it for weeks. Unfortunately, as soon as
> I even add an assertion, the crash point moves. It seems like the
> thing to do is to run draw_glyphs step-by-step, but with the macros
> and all that it is quite difficult, not to mention that I know very
> little about the redisplay code and that the bug is much harder to
> catch when I compile a non-optimized build.
>
> Any help, pointer, idea, or mojo will be deeply appretiated.

Is it only the composition glyph part of the 2008-04-09 change to
w32term.c that causes the crash?  For instance, what happens if you
comment out the "else if (s->cmp) ..." part in
w32_compute_glyph_string_overhangs?

Re: Crashes on draw_glyphs

[Juanma Barranquero]

On Tue, Nov 4, 2008 at 18:06, Chong Yidong <cyd@stupidchicken.com> wrote:

> Is it only the composition glyph part of the 2008-04-09 change to
> w32term.c that causes the crash?  For instance, what happens if you
> comment out the "else if (s->cmp) ..." part in
> w32_compute_glyph_string_overhangs?

It still fails.

But, truth be told, the description in #879 is outdated and I no
longer believe Jason's changes are responsible for the bug (bisecting
to find the first commit where it appears is hard because in many
cases a bootstrap is needed after the checkout).

My gut feeling, because of temporal correlation, is that the whole
problem is somehow related to this change:

2008-08-29  Kenichi Handa  <handa@m17n.org>

        These changes are to re-implement the automatic composition so
        that it doesn't use text properties.

But I could be wrong (again).

  Juanma

Re: Crashes on draw_glyphs

[Chong Yidong]

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

> The underling bug that causes #872/#1179 is really getting annoying.
>
> Apparently I'm the only one suffering it (perhaps I'm the only one
> compiling Emacs on Windows with GCC 4.3.0), and I've been
> unsuccessfully trying to debug it for weeks. Unfortunately, as soon as
> I even add an assertion, the crash point moves. It seems like the
> thing to do is to run draw_glyphs step-by-step, but with the macros
> and all that it is quite difficult, not to mention that I know very
> little about the redisplay code and that the bug is much harder to
> catch when I compile a non-optimized build.
>
> The breaking point (for my patience, at least) is that I now can crash
> Emacs even without setting unibyte-display-via-language-environment,
> just by doing
>
>   emacs -Q
>   M-x ucs-insert AEGEAN CHECK MARK <return>
>
> which causes an assertion failure.
>
> Breakpoint 1, w32_abort () at w32fns.c:7279
> 7279      button = MessageBox (NULL,
> (gdb) bt
> #0  w32_abort () at w32fns.c:7279
> #1  0x01034045 in fill_glyph_string (s=0x82e8c0, face_id=1,
> start=-1151, end=1, overlaps=0) at xdisp.c:19695
> #2  0x01057492 in draw_glyphs (w=0x2e44a00, x=17, row=0x2ffb260,
> area=TEXT_AREA, start=0, end=1, hl=DRAW_NORMAL_TEXT,
>     overlaps=0) at xdisp.c:20329

Any luck debugging this?

I notice that the START argument in fill_glyph_string is
negative---could you try to trace this back to see where it comes from?

Re: Crashes on draw_glyphs

[Juanma Barranquero]

On Thu, Nov 13, 2008 at 16:38, Chong Yidong <cyd@stupidchicken.com> wrote:

> Any luck debugging this?

No. It is quite time consuming, so I can only do it every now and
then. I'll try again during the weekend.

> I notice that the START argument in fill_glyph_string is
> negative---could you try to trace this back to see where it comes from?

I don't think that's reliable. I've had pretty similar crashes where
START was positive; I think START being negative is an indication of
memory corruption.

  Juanma