260212 - Mozilla (Trunk) fails to open X window when started

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Glenn Randers-Pehrson]

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

[Olivier Cahagne]

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

Comment 2

[Glenn Randers-Pehrson]

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

[Kenneth Herron]

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
freeze.

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

[Glenn Randers-Pehrson]

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
compiling.

Comment 5

[Glenn Randers-Pehrson]

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

[Glenn Randers-Pehrson]

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

Comment 7

[Glenn Randers-Pehrson]

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

[Glenn Randers-Pehrson]

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

[Glenn Randers-Pehrson]

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

[Alexander Opitz]

Glenn,

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

[Glenn Randers-Pehrson]

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.

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

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

[Glenn Randers-Pehrson]

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

[Glenn Randers-Pehrson]

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.