Reproducible bug in processing a piece of (html?) email

Reproducible bug in processing a piece of (html?) email

[David Maslen]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

Gnus v5.8.4
XEmacs 21.2  (beta26) "Millenium" [Lucid] (i686-pc-linux) of Mon Jan 17 2000 on trinity
200 Leafnode NNTP Daemon, version 1.9.7 running at 10.10.10.10


I have found a piece of mail that crashes the above combination every
time. The crash is so bad that xemacs quits as well. I'm submitting
this as a bug for gnus, because from the look of the backtrace it has
something to do with gnus running the article through w3. 

If you feel this is an bug with xemacs, let me know and I send it
there.


[-- Attachment #2: User settings --]
[-- Type: application/x-emacs-lisp, Size: 2 bytes --]

[-- Attachment #3: backtrace output --]
[-- Type: application/octet-stream, Size: 7016 bytes --]

Re: Reproducible bug in processing a piece of (html?) email

[David Maslen]

Sorry to follow up my own post, but I've discovered, that the error
doesn't not occur if I run xemacs -nw. I'm pretty sure it's w3 related
no. I also notice that the delay that has been annoying me when w3
passes html email messages is almost unnoticeable in text mode.

Why would there be this speed difference in w3, with text and X?
Is it possible to run w3 in a not graphic mode to make it faster
without running xemacs -nw?

Re: Reproducible bug in processing a piece of (html?) email

[Daniel Pittman]

On 17 Jan 2000, David Maslen <david.maslen@iname.com> wrote:

> Sorry to follow up my own post, but I've discovered, that the error
> doesn't not occur if I run xemacs -nw. I'm pretty sure it's w3 related
> no. I also notice that the delay that has been annoying me when w3
> passes html email messages is almost unnoticeable in text mode.
> 
> Why would there be this speed difference in w3, with text and X?
> Is it possible to run w3 in a not graphic mode to make it faster
> without running xemacs -nw?

If you use W3 from CVS and a recent XEmacs, you might be seeing the
progress widget lossage. Do you get `dynamic symbol XXX has the wrong
size, consider relinking' messages when starting XEmacs?

If so you have a 3D Athena shared library loaded but XEmacs complied for
the flat Athena library. This makes displaying a widget subclass raise
SIGSEGV :(

        Daniel

-- 
Quid sit futurem cras fuge quaerere
        -- Horace

Re: Reproducible bug in processing a piece of (html?) email

[David Maslen]

Daniel Pittman <daniel@danann.net> writes:
> If you use W3 from CVS and a recent XEmacs, you might be seeing the
> progress widget lossage. Do you get `dynamic symbol XXX has the wrong
> size, consider relinking' messages when starting XEmacs?
> 
> If so you have a 3D Athena shared library loaded but XEmacs complied for
> the flat Athena library. This makes displaying a widget subclass raise
> SIGSEGV :(

The exact error on starting were, 
xemacs: Symbol `toggleClassRec' has different size in shared object, consider re-linking
xemacs: Symbol `labelClassRec' has different size in shared object, consider re-linking

But a quick browse through xemacs21.2 code show that is related to the
xaw3d libs, and unfortunately the developement files were present on
the machine where I did the build.

I think that's probably solved it. Well done.

Re: Reproducible bug in processing a piece of (html?) email

[Daniel Pittman]

On 18 Jan 2000, David Maslen <david.maslen@iname.com> wrote:

> Daniel Pittman <daniel@danann.net> writes:
>> If you use W3 from CVS and a recent XEmacs, you might be seeing the
>> progress widget lossage. Do you get `dynamic symbol XXX has the wrong
>> size, consider relinking' messages when starting XEmacs?
>> 
>> If so you have a 3D Athena shared library loaded but XEmacs complied
>> for the flat Athena library. This makes displaying a widget subclass
>> raise SIGSEGV :(
> 
> The exact error on starting were, xemacs: Symbol `toggleClassRec' has
> different size in shared object, consider re-linking xemacs: Symbol
> `labelClassRec' has different size in shared object, consider
> re-linking
> 
> But a quick browse through xemacs21.2 code show that is related to the
> xaw3d libs, and unfortunately the developement files were present on
> the machine where I did the build.
> 
> I think that's probably solved it. Well done.

That's precisely it. You should, if you can, try building with
`--with-athena=3d' or one of the other non-flat variants. That is the
most stable way of avoiding this problem forever. 

The other solution is to make *sure* that the flat libXaw.so is *first*
in the load-path. This will almost certainly require that you edit
ld.so.conf if you are using Debian/unstable...

        Daniel

-- 
Anyone who goes to a psychiatrist ought to have his head examined.
        -- Samuel Goldwyn

Re: Reproducible bug in processing a piece of (html?) email

[Daniel Pittman]

On 18 Jan 2000, Aaron M. Ucko <amu@MIT.EDU> wrote:

> Daniel Pittman <daniel@danann.net> writes:
> 
>> Debian unstable has done away with the xaw-wrappers in favor of
>> frobbing ld.so.conf to load a 3D Athena library when something looks
>> for libXaw.so, unconditionally.
> 
> That's news to me; as far as I can tell, xaw-wrappers is alive and
> well.  What evidence do you have to the contrary?

I stand corrected; the package is still there and works. Color me
embarrassed.

        Daniel

-- 
Reality is not as strong as perception. Perception all too often swallows
reality and spits it out in a new, unrecognizable form.
        -- Maytee Aspuro

Re: Reproducible bug in processing a piece of (html?) email

[Aaron M. Ucko]

Daniel Pittman <daniel@danann.net> writes:

> Debian unstable has done away with the xaw-wrappers in favor of frobbing
> ld.so.conf to load a 3D Athena library when something looks for
> libXaw.so, unconditionally.

That's news to me; as far as I can tell, xaw-wrappers is alive and
well.  What evidence do you have to the contrary?

-- 
Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)

Re: Reproducible bug in processing a piece of (html?) email

[Kai Großjohann]

Daniel Pittman <daniel@danann.net> writes:

> This means that anything using flat Xaw gets your favorite 3D variant --
> and anything which subclasses widgets from flat Athena will now explode
> in flames.

(Off-topic alert)

Can I turn off 3d variants altogether?  I hate them.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Reproducible bug in processing a piece of (html?) email

[Daniel Pittman]

On 18 Jan 2000, Aaron M. Ucko <amu@MIT.EDU> wrote:

> "Daniel Pittman" <daniel@danann.net> writes:
> 
>> The other solution is to make *sure* that the flat libXaw.so is
>> *first* in the load-path. This will almost certainly require that you
>> edit ld.so.conf if you are using Debian/unstable...
> 
> Well, either that or installing xaw-wrappers and frobbing its
> configuration suitably...

Debian unstable has done away with the xaw-wrappers in favor of frobbing
ld.so.conf to load a 3D Athena library when something looks for
libXaw.so, unconditionally.

This means that anything using flat Xaw gets your favorite 3D variant --
and anything which subclasses widgets from flat Athena will now explode
in flames.

Were it that simple I would use that method myself. This is probably a
little off topic for the gnus list though. If you want to know more
about it, the XEmacs beta list is full of discussions about how to fix
this lossage right now. :)

        Daniel

-- 
My fate cannot be mastered; it can only be collaborated with and thereby, to
some extent, directed. Nor am I the captain of my soul; I am only the noisiest
passenger.
        -- Aldous Huxley

Re: Reproducible bug in processing a piece of (html?) email

[Aaron M. Ucko]

"Daniel Pittman" <daniel@danann.net> writes:

> The other solution is to make *sure* that the flat libXaw.so is *first*
> in the load-path. This will almost certainly require that you edit
> ld.so.conf if you are using Debian/unstable...

Well, either that or installing xaw-wrappers and frobbing its
configuration suitably...

-- 
Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)