bug#5123: 23.1.50; emacs hang / 100% CPU load

[Eli Zaretskii <eliz@gnu.org>]

> From: djcb.bulk@gmail.com
> Date: Fri, 04 Dec 2009 22:55:59 +0200
> Cc: 
> 
> I was opening an email with a picture in Wanderlust. Emacs hung, CPU load
> went to 100%. I captured the following backtrace (using gdb emacs `pidof
> emacs`):

Thank you for your report.

Can you tell where to get that picture, in order to reproduce the
hang?

> #0  0x0806b17f in append_glyph (it=0xbfde4c48) at xdisp.c:20525
> #1  0x08075517 in x_produce_glyphs (it=0xbfde4c48) at xdisp.c:21241
> #2  0x08082c6e in display_line (it=0xbfde4c48) at xdisp.c:16598
> #3  0x080892a2 in try_window (window=186534188, pos=..., check_margins=0) at xdisp.c:14000
> #4  0x0808dc7d in try_scrolling (window=<value optimized out>, 
>     just_this_one_p=<value optimized out>) at xdisp.c:12788
> #5  redisplay_window (window=<value optimized out>, just_this_one_p=<value optimized out>)
>     at xdisp.c:13678
> #6  0x0808f363 in redisplay_window_0 (window=186534188) at xdisp.c:12261

This is an optimized build.  Too many parameters are optimized out,
and even the backtrace itself is not reliable in optimized builds.

Could you perhaps rebuild Emacs with "-O0 -ggdb -g3", and then show
the backtrace from the same hang?  Also, if you single-step Emacs from
this point, or use `finish', does it loop in endlessly, or does it
remain stuck in append_glyph?  See the section "If the symptom of the
bug is that Emacs fails to respond" in etc/DEBUG for more details
about this.

Finally, please run GDB from the Emacs's src/ directory?  There's a
.gdbinit file there which will show a Lisp backtrace as well.

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

Yes, please do that as well.

> Load-path shadows:
> [long list of shadows deleted]

Wow, that's a lot of shadowing!  Is it intentional?