[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6593: emacs-23.2 crashes in get_glyph_face_and_encoding with a null

From: Eli Zaretskii
Subject: bug#6593: emacs-23.2 crashes in get_glyph_face_and_encoding with a null face returned by FACE_FROM_ID(0)
Date: Sat, 10 Jul 2010 11:13:33 +0300

> From: John Lumby <address@hidden>
> Date: Fri, 9 Jul 2010 09:54:55 -0400
> Cc: 
>  paste this text into any lisp-interaction buffer e.g. *scratch*,  position 
> cursor at end, and press Ctl-X Ctl-E
> (progn (modify-frame-parameters (selected-frame) '((menu-bar-lines . 0)))
> (set-face-font 'modeline 
> "-misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1")
>  (face-set-after-frame-default (selected-frame)) (set-face-background 
> 'default (cdr (assoc 'background-color (frame-parameters (selected-frame))))) 
> (set-face-background 'fringe (cdr (assoc 'background-color (frame-parameters 
> (selected-frame))))) (set-face-foreground 'default (cdr (assoc 
> 'foreground-color (frame-parameters (selected-frame))))) (server-start))
> I get a crash in get_glyph_face_and_encoding. 

Thanks for your report.  It misses a few crucial details, though.

What system is that?  I couldn't reproduce the crash on my machine

> I started emacs with something like
> emacs --name=sawlist --title=sawlist -ms "#14892b" -cr red -fn 
> "-Misc-Fixed-bold-R-*--15-*-*-*-C-90-ISO8859-1" -bg "#E0EDED" -fg "#751503" 
> -q -load sawlist.el
> I can send my sawlist.el  if needed

Does the crash happen if you start Emacs with "emacs -Q"?  Without -Q,
your customizations on ~/.emacs also come into play.

> I obtained a core file after rebuilding to get the debugging information and 
> here is the relevant piece
> (gdb) bt
> #0  0x00d57424 in __kernel_vsyscall ()
> #1  0x00876006 in kill () at ../sysdeps/unix/syscall-template.S:82
> #2  0x0810fe76 in fatal_error_signal (sig=11) at emacs.c:402
> #3  <signal handler called>
> #4  get_glyph_face_and_encoding (f=0x920c4f0, glyph=0x946b9a0, 
> char2b=0xbfbeb890, two_byte_p=0xbfbeb85c) at xdisp.c:19511
> #5  0x0806bc58 in fill_glyph_string (s=0xbfbeb8b0, face_id=0, start=<value 
> optimized out>, end=1, overlaps=0) at xdisp.c:19681
> #6  0x0806c68b in draw_glyphs (w=0x920c670, x=27, row=0x93fa530, 
> area=TEXT_AREA, start=0, end=1, hl=DRAW_NORMAL_TEXT, overlaps=0)
>     at xdisp.c:20297

Please show the full backtrace, including the Lisp backtrace (shown if
you start GDB from the src directory).  The above only shows the top 6
stack frames.

Also, if you could rebuild without optimizations (-O0), it would help,
because the stack trace in an optimized build cannot be trusted and
too many variables have their values shown as ``optimized out'', which
doesn't really help debugging.

> This patch (below) fixes one obvious mistake (but not the cause) and also 
> works around the problem.  This mistake is that the assert is located after 
> the dereference of the face pointer  - should be before.   But that just 
> changes the crash to an assert failure.   The workaround to is to try all 
> other faces cached on the frame.    I don't know what the correct fix is for 
> the default face being null.

Sorry, but I don't think this is the right fix.  The default face
should always be realized.  Looking up some face, any face, in the
face cache is not TRT.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]