Re: crash with glyph on tty

I wrote: > > At 07:30 AM 11/10/00 +0100, Norbert Koch wrote: > > >Katsuhiro Hermit Endo <hermit(a)koka-in.org&gt; wrote: > > > > > >Hi! > > > > > > > I'm using XEmacs 21.2.36 from CVS. > > > > xemacs -nw and gnuclient -nw crashed with viewing a mail (Gnus) with > > > > X-Face. > > > > Does anyone fixed this bug ? > > > > > >Not a fix, a suggestion: I shut off displaying of x-faces when in > > >terminal mode. Thus, at least, I can work without having to restart > > >xemacs every odd minute. Yes, I know, I should investigate .... too > > >many things in real life :-( > > > > > >(when (equal (device-type) 'tty) > > > (setq gnus-article-x-face-too-ugly "^.*$")) > > > Nope. I can reproduce this crash on ttys with my patch applied. > AFAICT right now, it looks like a problem with specifier_instance: it seems > that it's returning Qunbound where it shouldn't, because the glyph has > indeed a fallback of [nothing]. I've just got a crash very likely to be the same one, when trying to display a (possibly) corrupted image in Gnus. I can track this one more easily, but I don't understand what's going on. There'is a mix of C code and Lisp execution and I'm not familiar with that. What happens is that when the glyph is being instantiated, the instantiation process ends up trying the fallbacks (the nothing vector actually) via `specifier_instance_from_inst_list'. This in turns calls `image_instantiate'. The following piece line returns nil: | instance = Fgethash (pointerp ? ls3 : glyph, | subtable, Qunbound); and afterwards, an error is signaled with that piece of code: | else if (NILP (instance)) | signal_simple_error ("Can't instantiate image (probably cached)", | instantiator);

This does obscure things which I don't understand (involving specpdl, record_unwind I don't know what), ends up on a jmp and barfs on the assertion in glyph_image_instance.