[debbugs-tracker] bug#11964: closed (describe-char causes a fatal error (abort trap: 6) in non-windowed mode)

[GNU bug Tracking System]

Your message dated Sat, 24 Nov 2012 18:59:54 +0100
with message-id <address@hidden>
and subject line Re: bug#11964: describe-char causes a fatal error (abort trap: 
6) in non-windowed mode
has caused the debbugs.gnu.org bug report #11964,
regarding describe-char causes a fatal error (abort trap: 6) in non-windowed 
mode
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
11964: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11964
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: describe-char causes a fatal error (abort trap: 6) in non-windowed mode Date: Mon, 16 Jul 2012 23:51:50 +0100 GNU Emacs 24.1.1 (x86_64-apple-darwin11.4.0, NS apple-appkit-1138.47)

emacs -Q -nw

n C-x 8 <RET> 0303 <RET> C-b C-u C-x =

This crashes emacs. I am returned to bash. "Fatal error (10)" is written to the screen. After about 3 seconds, "Abort trap: 6" is appended to the same line, and I am returned to the prompt.

This does not happen in the windowed version (Emacs.app)

every locale variable is en_GB.UTF-8

TERM is dumb.

This (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9172) might be of use. It describes a similar bug on emacs 23.3 running on an xterm, but the program does not crash.

Cheers,

Dan

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#11964: describe-char causes a fatal error (abort trap: 6) in	non-windowed mode
>
>
>
>
> Date: 
>
> Sat, 24 Nov 2012 18:59:54 +0100
>
>
>
>
> Hello.
>
> This has been fixed in the trunk.
> The problem was that ns-win created fontsets unconditionally during load and 
> that lead to problems when running with -nw, in face_for_char.  Shouldn't 
> fontsets/font objects be ignored if the terminal is a non-GUI one?
>
>         Jan D.
>
> 23 nov 2012 kl. 08:07 skrev Jan Djärv <address@hidden>:
>
> > Hello.
> > 
> > 23 nov 2012 kl. 07:26 skrev Chong Yidong <address@hidden>:
> > 
> >> Jan Djärv <address@hidden> writes:
> >> 
> >>> Here is a backtrace.  The fontdriver does not have an encode_char
> >>> function (it is NULL).  But I don't know which driver this is.  Lisp
> >>> backtrace is broken it seems.
> >> 
> >> Could you do
> >> 
> >> f 1
> >> pp face->font->driver->type
> >> 
> >> and see what font driver it is (or if there is one)?
> > 
> > Basically no, because
> > 
> > p face->font->driver
> > $3 = (struct font_driver *) 0x3
> > 
> > Uninitialized memory?
> > 
> >       Jan D.
> > 
>
>
>
> --- End Message ---