Closed Bug 19996 Opened 25 years ago Closed 25 years ago

[CRASH] loading this mailbox kills my X server

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 19600

People

(Reporter: akkzilla, Assigned: alecf)

Details

I have a local mail folder (which I use for testing) stored at
/u/akkana/mozillamail/KillXServer.  It used to work in mozilla.

Now, opening this folder with mozilla, then clicking on the first message in the
folder, repeatably kills my X server (Accelerated-X, not XFree86).  This is 100%
repeatable, even after renaming the folder and removing the .msf file.

I don't know that it's the first message in the folder causing the problem,
since due to another bug (filed separately), clicking on a message in a local
folder loads that message plus every subsequent one.

Happens both with my modified tree and with a release build from 11/23.
akkana, is there ANY chance you can get a stack trace? Maybe by running it under
gdb remotely from another machine or something?

I'll warn you upfront :) - if this really is an AcceleratedX-specific problem, I
really doubt that
a) it's mail related
b) that pavlov will have the time to fix this.

Actually, I doubt it's mail related anyway.
Running Accelerated X under gdb?  Is that possible?

Running mozilla under gdb won't help since all the processes under X get killed
when the X server crashes (don't they?)  It might require a proxy server or
something.

I'd love to run XFree86; wish it handled my video card.  I suppose I should talk
my manager into buying me a better video card ... But there *are* reasons for
using another X server and it would be nice if we could play nice with them.

I just tried it on moocow (running Debian and, I assume, XFree86).  It didn't
crash the server, but what I saw was the lines from the entire folder run
together with no newlines in between them.  I'll take a wild guess and speculate
that we may be passing some huge string with no newlines to the X server all at
once, and that this is choking Xaccel.
no no, running the browser under gdb.... since you can't get a core (glibc 2.1.1
problem) and since your X server dies, you'll have to run gdb remotely somehow.
I'm thinking go to another machine, telnet into your machine and set the display
to display on your box's X server. Then use mozilla from your machine. When the
X server goes down, see what mozilla does. It might crash and at least maybe we
can see a stacktrace in mozilla.

I realize there are good reasons to run different X servers, I'm just saying
it's a very small percentage of an already [relatively] small platform... so it
gets lower priority than, say, making scrolling fast.
Yes, run the X server and mozilla both under gdb (just telnet in from another
machine, or maybe use a virtual console, or even another X server running
locally).  You won't get symbol data from AccelX, but the stack trace can still
be informative.

Also, you will want to run Mozilla in synchronous mode, or you'll see the crash
happening in whatever happens to cause the X command queue to flush.

(What's your card?  Is there an AccelX update out there?  FWIW, Pav's box is
likely running XF3.9.)
How do I run in synchronous mode? I don't see anything that looks like a --sync
flag searching for "sync" in lxr.

This is probably academic anyway -- even in XFree86 it's clear that trying to
load this folder screws up badly in mozilla mail for some reason (try it and see
for yourself), and my guess is that fixing that problem will also fix the server
crash.
Oh, BTW, my card (on an HP Kayak XAs 450) is an Elsa Gloria Synergy.  The 3DLabs
server claims to support it, but it didn't work last time I tried it.  I may try
installing a newer XFree86 and/or a newer Xaccel, but since there's clearly a
bug visible here even under XFree86 I'm not in a hurry to change my server
(besides, it makes a good test case).
Yes, it's a great test case, but getting stack data from it is going to make it
a lot easier to find the bug.

mozilla-bin --sync starts it in synchronous mode for me (I think -- it's a
_hell_ of a lot slower over a remote display).
Waterson has a patch to fix 19600 (not seeing message separators in local
folders), and it fixes this bug as well.  I can now load every message in that
folder individually, without crashing the server.  (One of the messages hangs
mozilla, but I'll file that as a separate bug.)  So this can probably be
considered a dup of 19600.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
I'll mark dupe then. Anyone objects, please reopen

*** This bug has been marked as a duplicate of 19600 ***
Status: RESOLVED → VERIFIED
mark verified as a duplicate then.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.