Mozilla (Trunk) fails to open X window when started



14 years ago
14 years ago


(Reporter: Glenn Randers-Pehrson, Unassigned)



Firefox Tracking Flags

(Not tracked)




14 years ago
Downloaded a fresh tree from CVS on Sept 17, ran autoconf and gmake.
Typed "mozilla" and nothing happens.  Repeated several times to verify.
My previous download was on Sept 11 and it opens an X window as expected.
I'm running FreeBSD and attempting to display on a PC running MI-X 4.1

Comment 1

14 years ago
Does it crash ? What happens when Mozilla is run in GDB ?

Comment 2

14 years ago
It doesn't crash.  It simply does nothing until I type <ctrl>c into the
console window; then I get back my prompt.  I don't know about GDB.

Comment 3

14 years ago
I experienced the same problem. I have two trees I update through cvs. Last
night around 9 PM pacific I updated both and started depend builds. This morning
both builds had completed successfully, but when I tried to run them they would

I didn't spend a lot of time troubleshooting it, but it looked like things were
going wrong just before the point when the profile manager window would open;
mozilla would dump a few hundred assertion failure messages and then stop. The
program was still running, but there was no more output and no windows had opened.

So I updated both trees again, did a make clean in one of them, and rebuilt in
both. The tree I cleaned is still rebuilding but the other one finished quickly
and works fine. My update this morning was before roc's checkin at 7:39, and
none of the checkins from last night to that point look very significant.

Comment 4

14 years ago
To narrow this down I've checked out -D "2004-09-13" and -D "2004-09-15".
Finished building 09-13 and it opens a window and produces a normal
display except that PNGs are missing. GIFs and JPEGs are OK.  09-15 is still

Comment 5

14 years ago
The 9-15 checkout fails like the Sept 17 one.  Nothing happens, except that
there is a little bit of traffic through my firewall every 7-10 seconds.
No window ever opens.  After a couple of minutes I get bored and hit <ctrl>c
(Normally the window opens in about 15 seconds).

Comment 6

14 years ago
After autoconf, configure is considerably changed.  Has someone checked in
an edited "configure" that is not consistent with

Comment 7

14 years ago
The 9-14 checkout opens a mozilla window (and fails to show PNG files)
like 9-13.  So it seems that some checkout between 9-11 and 9-13 causes
PNG images to fail and some checkout on 9-15 causes window-opening to fail.
Whether the two failures are related is anyone's guess.

Comment 8

14 years ago
Checkout at 07:00 PDT 9/14 works
Checkout at 10:00 PDT 9/14 hangs

According to bonsai there was only one checkin during that period,
for bug#258121

Comment 9

14 years ago
Reversing the patch for bug #258121 in a Sept 19 checkout fixes this
problem.  Also (unrelated I suppose) my PNG images are back again.

Comment 10

14 years ago

the patch only adds an extra stron reference to the pointer ... so I don't think
that this causes a problem.
But on the other side it seems you have make real clean compiles :-?

Comment 11

14 years ago
Yes, really clean.  I remove /tmp/glennrp/Mozilla/lib/* and do a complete
checkout and gmake.  Each iteration takes quite a while, so it took several
days to home in on the culprit.  It looks innocent enough, but the fact
remains that with the patch I get no X window, and after reversing the patch
I do get one.  Why that is so is a mystery to me.
hmm. can you set a breakpoint in that function to see where it is hit on startup?

or even a printf to see whether it's hit?

Comment 13

14 years ago
Printf says it's not hit.  Also if I reinstall the patch and include a
printf, it works OK and nothing is printed.  This is beginning to look
like a compiler optimization bug of some sort.  I'm using gcc-3.4.2 with
optimization on and debug off.  I'll try some other combinations and see
what happens.

Comment 14

14 years ago
I find that I am now unable to reliably reproduce the problem I was having.  My
guess now is that it is some transient hardware trouble.  Resolving bug as WFM.
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.