2:05 a.m.
Hello.
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 ?
-- Katsuhiro Hermit Endo
6:30 a.m.
Katsuhiro Hermit Endo <hermit(a)koka-in.org> 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 "^.*$"))
5:27 p.m.
Katsuhiro Hermit Endo <hermit(a)koka-in.org> wrote:
xemacs -nw and gnuclient -nw crashed with viewing a mail (Gnus) with
X-Face.
Norbert Koch <nk(a)LF.net> writes:
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 "^.*$"))
Ah, thank you very much !
I didn't know the variable gnus-article-x-face-too-ugly.
I use your code in my ~/.gnus.el, and keep hacking glyphs.c ... =(
-- Katsuhiro Hermit Endo
9:24 a.m.
Does Didier's latest fix help here?
Thanks
andy
At 07:30 AM 11/10/00 +0100, Norbert Koch wrote:
Katsuhiro Hermit Endo <hermit(a)koka-in.org> 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 "^.*$"))
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
11:40 a.m.
Andy Piper <andy(a)xemacs.org> wrote:
Does Didier's latest fix help here?
Thanks
andy
At 07:30 AM 11/10/00 +0100, Norbert Koch wrote:
>Katsuhiro Hermit Endo <hermit(a)koka-in.org> 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].
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
6:04 p.m.
I wrote:
> At 07:30 AM 11/10/00 +0100, Norbert Koch wrote:
> >Katsuhiro Hermit Endo <hermit(a)koka-in.org> 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.
That's all I can say. I don't understand what's going on in the code.
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
8:01 a.m.
At 07:04 PM 11/29/00 +0100, Didier Verna wrote:
I wrote:
> > At 07:30 AM 11/10/00 +0100, Norbert Koch wrote:
> > >Katsuhiro Hermit Endo <hermit(a)koka-in.org> 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 is correct so far. The hastables should contain nil for something that
can't be instantiated (e.g. a corrupt image).
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.
I'm inclined to think the assertion is wrong, although I'm not convinced
about this since I don't understand why we haven't seen this with other
things. Try putting
if (!NILP(instance))
{
...
}
around the code in check_image_instance_structure and see whether that
makes any difference. Ben is the only one who really understands how this
error trapping works.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
8:42 a.m.
Andy Piper <andyp(a)bea.com> wrote:
This is correct so far. The hastables should contain nil for
something that
can't be instantiated (e.g. a corrupt image).
And I think that's actually the case (the image is corrupted).
Try putting
if (!NILP(instance))
{
...
}
around the code in check_image_instance_structure and see whether that makes
any difference. Ben is the only one who really understands how this error
trapping works.
OK.
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
5:43 a.m.
[ Disclaimer: I don't understand glyph code. ]
Andy Piper <andyp(a)bea.com> writes:
I'm inclined to think the assertion is wrong, although I'm
not convinced
about this since I don't understand why we haven't seen this with other
things.
I don't think the assertion is wrong. The easiest way to
reproduce crash is xemacs -nw and evaluate following
expression. (substitute "white.xpm" to (locate-data-file
"xemacs.xpm") or some other xpm.)
(glyph-height
(make-glyph (vector 'xpm :data
(with-temp-buffer (insert-file-contents "white.xpm")
(buffer-string)))))
Oddly,
(glyph-height
(make-glyph (vector 'xpm :file "white.xpm")))
doesn't crash.
The problem is, now image_instantiate doesn't instantiate
[nothing] and signals an error instead. If you evaluate
above expression, image_instantiate is called twice. First
one is XPM specifier and second one is its fallback,
[nothing]. The first time, it signals an error and this is
a right behavior. The second time,
instance = Fgethash (pointerp ? ls3 : glyph,
subtable, Qunbound);
return nil instead of correct unbound. I compared the code
with 21.1 and using glyph here looks really suspicious. All
the logic is same and now glyph is used instead of
instantiator. I replaced glyph with instantiator like
following patch and Bingo! The crash went away. However,
this patch apparently breaks glyph code. Could you provide
a right fix?
Index: glyphs.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs.c,v
retrieving revision 1.23.2.86
diff -u -r1.23.2.86 glyphs.c
--- glyphs.c 2000/11/07 23:24:28 1.23.2.86
+++ glyphs.c 2000/12/05 05:19:22
＠＠ -3139,7 +3139,7 ＠＠
{
pointer_fg = FACE_FOREGROUND (Vpointer_face, domain);
pointer_bg = FACE_BACKGROUND (Vpointer_face, domain);
- ls3 = list3 (glyph, pointer_fg, pointer_bg);
+ ls3 = list3 (instantiator, pointer_fg, pointer_bg);
}
/* First look in the device cache. */
＠＠ -3179,7 +3179,7 ＠＠
}
else
{
- instance = Fgethash (pointerp ? ls3 : glyph,
+ instance = Fgethash (pointerp ? ls3 : instantiator,
subtable, Qunbound);
}
}
＠＠ -3188,7 +3188,7 ＠＠
/* Subwindows have a per-window cache and have to be treated
differently. */
instance =
- Fgethash (pointerp ? ls3 : glyph,
+ Fgethash (pointerp ? ls3 : instantiator,
XWINDOW (governing_domain)->subwindow_instance_cache,
Qunbound);
}
＠＠ -3201,7 +3201,7 ＠＠
{
Lisp_Object locative =
noseeum_cons (Qnil,
- noseeum_cons (pointerp ? ls3 : glyph,
+ noseeum_cons (pointerp ? ls3 : instantiator,
DEVICEP (governing_domain) ? subtable
: XWINDOW (governing_domain)
->subwindow_instance_cache));
＠＠ -3234,7 +3234,7 ＠＠
#ifdef ERROR_CHECK_GLYPHS
if (image_instance_type_to_mask (XIMAGE_INSTANCE_TYPE (instance))
& (IMAGE_SUBWINDOW_MASK | IMAGE_WIDGET_MASK))
- assert (EQ (Fgethash ((pointerp ? ls3 : glyph),
+ assert (EQ (Fgethash ((pointerp ? ls3 : instantiator),
XWINDOW (governing_domain)
->subwindow_instance_cache,
Qunbound), instance));
--
Yoshiki Hayashi
2:10 p.m.
A complicated fix for a simple bug ...
2000-12-31 Andy Piper <andy(a)xemacs.org>
* window.c (allocate_window): use
make_image_instance_cache_hash_table.
(make_dummy_parent): ditto.
(Fset_window_configuration): ditto.
* glyphs.h (INSTANTIATOR_TYPE): new macro. declare new functions.
* glyphs.c (process_image_string_instantiator): use
INSTANTIATOR_TYPE.
(get_image_instantiator_governing_domain): ditto.
(normalize_image_instantiator): ditto.
(instantiate_image_instantiator): ditto.
(make_image_instance_1): ditto.
(image_instantiate): ditto. Key on glyph *and* instantiator type.
(instantiator_eq_equal): new function for use with instance hash
tables.
(instantiator_eq_hash): ditto.
(make_image_instance_cache_hash_table): create a suitable hash
table for storing image instances.
* elhash.h (hash_table_weakness): new internal weakness type
HASH_TABLE_KEY_CAR_VALUE_WEAK.
declare new functions.
* elhash.c (finish_marking_weak_hash_tables): introduce yet
another weakness type for glyphs.
(make_standard_lisp_hash_table): new function split out from
make_general_lisp_hash_table.
(make_lisp_hash_table): call make_standard_lisp_hash_table.
(hash_table_instantiate): ditto.
(Fmake_hash_table): ditto.
At 14:43 05/12/00 +0900, Yoshiki Hayashi wrote:
I don't think the assertion is wrong. The easiest way to
reproduce crash is xemacs -nw and evaluate following
expression. (substitute "white.xpm" to (locate-data-file
"xemacs.xpm") or some other xpm.)
(glyph-height
(make-glyph (vector 'xpm :data
(with-temp-buffer (insert-file-contents "white.xpm")
(buffer-string)))))
I have a feeling the implications of not fixing this would have been quite
fundamental.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
8540
days inactive
8591
days old
9 comments
7 participants
participants (7)
-
Andy Piper -
Andy Piper -
Didier Verna -
Didier Verna -
Katsuhiro Hermit Endo -
Norbert Koch -
Yoshiki Hayashi