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
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
I'll mark dupe then. Anyone objects, please reopen *** This bug has been marked as a duplicate of 19600 ***
mark verified as a duplicate then.
You need to log in before you can comment on or make changes to this bug.