134221 - mozilla fails to start on Tru64 UNIX

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX, defect, P2)

Description

[bobbell]

mozilla fails to get to the point of creating a GUI on Tru64 UNIX.  I am
compiling mozilla using the same method I have used in the past.  Previously,
mozilla would compile and run just fine.  Currently, however, milestone 0.9.9
and nightly releases fail to start properly.  Optimized builds hang without
producing any output.  Debug builds print a slew of messages which I will attach
separately.  Unfortunately, I can't run a debugger on this crash due to memory
restraints.  I will attempt to reproduce this bug on another machine to get a
stack trace.

I believe this bug is critical because mozilla is currently completely broken on
Tru64 UNIX.  Tru64 UNIX 5.1B is currently planned to ship with Netscape
Navigator 6.x (based on mozilla, of course) as the default browser.

Comment 1

[bobbell]

Attachment: Out of a debug build

Output from running a debug build.  mozilla hangs undefinitely without
producing further output.

Comment 2

[bobbell]

Attachment: Output of a debug build + stack traces of threads

I was able to determine that running 'limit datasize unlimited' would solve my
memory problems.  So, here is the output of another run of a debug build, this
time annotated with stack traces of the various threads running at the time.

Comment 3

[bobbell]

Marking this bug as critical, as was my original intent.  As stated, this
completely breaks mozilla of Tru64 UNIX.  Also marking it as blocking other bugs
that I have reported, as I am unable to test those bugs.

Comment 4

[Andrew Schultz]

your debug output deviates from mine here:

WARNING: NS_ENSURE_TRUE(mDeviceContext) failed, file nsDocShell.cpp, line 3842

That error would be due to do_CreateInstance failing, which seems to be part of
XPCOM...  This problem might lead to the rest of the WARNINGS and ASSERTIONS and
the eventual crash.

I had a bit of trouble compiling to test bug 94734.  Part of it was the
ldap/c-sdk directory shuffling, and part of it was previous failed compiles that
didn't get recompiled properly when I changed configure flags or updated from CVS.

If you haven't already done so, you might try
gmake -f client.mk distclean

update from CVS and start over.

Comment 5

[Boris Zbarsky [:bzbarsky]]

To compositor for further triage.... not getting device contexts is bad.  :)

Comment 6

[bobbell]

Is anyone looking at this?  mozilla on Tru64 UNIX is completely unusable.

Comment 7

[Andrew Schultz]

does 1.0rc1 also have this problem?

Comment 8

[Aron Griffis]

I don't know about 1.0rc1, but I know is doing nightly builds, and it's still
broken as of May 2.  Since that's a couple weeks after 1.0rc1, I would assume
that covers the question...  or is that a bad assumption?

Comment 9

[Aron Griffis]

I meant "I know Bob is doing nightly builds..."

Comment 10

[Andrew Schultz]

I asked if he had tried 1.0rc1 to distinguish between what might be a build
config problem and what a real GFX Compositor bug.  If the Mozilla-built 1.0rc1
doesn't work, then it's probably Compositor bug.

However, closer inspection of available binaries for download indicates that
1.0rc1 is not available for OSF (doh!) and the latest nightly is Mar 12 (and
it's corrupt!)

marking NEW to get some attention, although if no one else can reproduce this,
it will be difficult to figure out.

Probably the best (and most time consuming) way to help here is to build from
old source and figure out when this started happening...

Comment 11

[bobbell]

ajschult:

I have a script that routinely builds mozilla nightlys from source.  The build
ID is set to the time of the source tarball on ftp.mozilla.org.  I am currently
using build 2002021315, which works.  The next build I have is build 2002022513,
which does not work.  No nightly builds since then work, either.

Unfortunately, there is obviously a 12 day window between those builds.  I
believe my build failed during that time period because the method of setting
the build ID changed.  If you could point me to source tarballs during that time
period, I could potentially identify the build in which this problem began more
precisely.

Even if no one else can reproduce this, I am willing to work closely with a
developer, following his/her instructions, in order to see this problem resolved.

Comment 12

[Andrew Schultz]

AFAIK, the old source tarballs are unavailable.  the archives in
http://download.mozilla.org/pub/mozilla/nightly/
go back to 4-15-2002.

the older source is still available from CVS.

Comment 13

[tilps]

Just thought I would add that I have 1.0rc3 bringing up a GUI on OSF 4.0d - I
havent tested it much yet since X forwarding over a modem line is a pain.

which is quite an advance from where i was a few days ago ... but that was
because i was using old compiler versions which were not happy.

Comment 14

[Shanmugavelu Shanmuganathan (gone)]

I have been building mozilla very regularly and have no problems 
using it. I am using Tru64 UNIX 5.0A. Let me know what is the 
version of Tru64 UNIX is involved here. 

By the way,  mozilla 1.0 RC1 is availble at the click of 
the following URL.

ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla1.0rc1/

Download 'em and report here if you still face any problems.

Comment 15

[Andrew Schultz]

1.0rc3 osf builds are also available

I think he's running Tru64 UNIX V5.1.  perhaps this bug is specific to v5.1

Comment 16

[Shanmugavelu Shanmuganathan (gone)]

I just tried Mozilla 1.0RC3 on
Compaq Tru64 UNIX V5.1A (Rev. 1885) where everything seemed 
to work fine. 
I saw a similar problem sometimes back on my 5.0A, where 
I found "netstat" was hanging in my system. Though there is 
a remote possibilty of the same happening with another system, 
can I ask the reporter to check if that is the case here. 

Comment 17

[Simon Paquet [:sipaq]]

Reporter, is this still an issue? Comment 14 and comment 16 seem to suggest,
that this works fine now.

Comment 18

[bobbell]

This problem still appears to occur for me.  I have not been building mozilla
builds for some time (due to lack of available time).  However, I have just
recently attempted to build Mozilla Firebird 0.7.  Initial attempts, using lots
of compile-time options produced odd results.  I cut back on the number of
custom compile-time options (i.e., .mozconfig stuff), and the behavior I'm
seeing now appears to be consistent with this bug.  The optimized build that I
just built starts, but seems to hang without producing any output.  I haven't
tried a debug build.  Please advise.

Comment 19

[Simon Paquet [:sipaq]]

Please open a separate bug for Firebird not building/working correctly.

Comment 20

[bobbell]

I suspect that both Firebird and Mozilla proper are suffering from the same
problem.  However, I will attempt to build Mozilla proper again to verify that.

Comment 21

[bobbell]

Things broke at first, but seem to be working just dandy now, so I suppose this
bug can be closed.

Comment 22

[Simon Paquet [:sipaq]]

Ok, marking WFM