43355 - Mozilla crashes on attempt to load any valid URL

Status: VERIFIED WORKSFORME

(SeaMonkey :: General, defect, P3)

Description

[John Goshdigian]

Machine: Compaq XP1000 EV6
OS: Redhat Linux 6.2 (Alpha)
Memory: 256mb
Compiler: gcc/g++ version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) 

Mozilla compiled and linked successfully, however when attempting to browse any 
valid URL, the application crashed without any error message.  No core file was 
seen, the window simply disappears and no sort of message was given on the 
invoking window.  The last thing seen before the mozilla window simply 
disappeared and the process died was:

WEBSHELL- = 6
nsWidget::~nsWidget() of toplevel: 27 widgets still exist.
WEBSHELL- = 5
WEBSHELL- = 4
Entry at index 0 is http://www.mozilla.org/projects/seamonkey/release-notes/ 
bash$

Comment 1

[Doron Rosenberg (IBM)]

reporter - what mozilla build are you using?

Comment 2

[Asa Dotzler [:asa]]

matt, can you look at this.

Comment 3

[John Morrison]

What did the rest of the console messages say?

Comment 4

[msw]

The M16 build blizzard did exhibited a segfault that looked much like this.  Are
you using the alpha RPM?

Comment 5

[msw]

*reads full bug report* -- Oh, I guess you're not running the RPM.  Which pull
are you building?

Comment 6

[leger]

Adding crash keyword

Comment 7

[John Goshdigian]

This is M16.  Tried building the rpm from the source RPM - gave us a seg 
fault.  There was no alpha binary RPM in the directory named "alpha".  Tried 
building from the tarball from the mozilla website, no segfault (at least the 
window did not report "Segmentation fault"), just exits.  

John Goshdigian

Comment 8

[msw]

Check to make sure that the build you made from the tarball is using the same
./configure flags and compiler optimization flags.

Comment 9

[John Goshdigian]

Just rebuilt the tarball with the same ./configure options as the SRPM.  
Added "--enable-optimize --disable-debug --enable-strip-libs" to the tarball 
configure line, reran make and make install.  M16 quits with the same effect as 
before.  What's funny is yesterday we did a diff -r on the entire source tree, 
and did not notice any differences (with exception to some CVS tags and files 
laying around that got removed by rpm when we ran rpm -bb mozilla.spec from the 
SRPM).  So, conceivably, we should have the exact same situation in both 
cases.  Again, after executing the tarball version, it simply exits without a 
segmentation fault.  The rpm built version executes the same way, but exits in 
the same place and gives a segmentation fault.  In either case, it's not 
working as expected, but it is still bizarre that one spits out "segmentation 
fault" and the other does not.

For those of you asking for the entire output when executing mozilla, here it 
is:

bash$ ./mozilla
.//run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=/home/andy/mozilla/dist/bin
  LD_LIBRARY_PATH=/home/andy/mozilla/dist/bin
     LIBRARY_PATH=/home/andy/mozilla/dist/bin
       SHLIB_PATH=/home/andy/mozilla/dist/bin
          LIBPATH=/home/andy/mozilla/dist/bin
       ADDON_PATH=/home/andy/mozilla/dist/bin
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
nsNativeComponentLoader: autoregistering begins.
*** Registering nsTimeBomb components (all right -- a generic module!)
nsNativeComponentLoader: autoregistering succeeded
***** Chrome Registration: Installing skin at resource:/chrome/skins/modern/
***** Chrome Registration: Installing package at resource:/chrome/packages/core/
***** Chrome Registration: Installing locale at resource:/chrome/locales/en-US/
***** Chrome Registration: Installing package at resource:/chrome/packages/widge
t-toolkit/
***** Chrome Registration: Installing package at resource:/chrome/packages/messe
nger/
ProfileManager : CreateNewProfile
Profile Name: default                 
Profile Dir: /root/.mozilla
ProfileName : default
ProfileDir  : /root/.mozilla/default
GFX: dpi=96 t2p=0.0666667 p2t=15 depth=16
WEBSHELL+ = 1
Initialized app shell component {18c2f989-b09f-11d2-bcde-00805f0e1353}, rv=0x000
00000
WEBSHELL+ = 2
Obtained name of Personal Toolbar from bookmarks string bundle.
Start reading in bookmarks.html
Finished reading in bookmarks.html  (337816 microseconds)
Enabling Quirk StyleSheet
Note: verifyreflow is disabled
Enabling Quirk StyleSheet
Note: styleverifytree is disabled
Note: frameverifytree is disabled
WEBSHELL+ = 3
Enabling Quirk StyleSheet
Enabling Quirk StyleSheet
WEBSHELL+ = 4
Enabling Quirk StyleSheet
Setting content window        
  *** Pulling out the charset
Loading page specified via openDialog
in SetSecurityButton
Document: Done (0.488 secs)
*** check number of frames in content area
Error loading URL http://www.mozilla.org/mozorg.html
WEBSHELL+ = 5
Entry at index 0 is www.compaq.com
bash$

The second we type in www.compaq.com, the window simply is destroyed and we're 
returned to a prompt.  If we had been running the RPM compiled version there 
(the one we compiled from the SRPM), it would have shown us:
--- CUT ---
Entry at index 0 is www.compaq.com
Segmentation fault
bash$
--- CUT ---

One other thing - the reason why we saw "Error loading URL 
http://www.mozilla.org/mozorg.html" above is because the browser was run on a 
machine behind a firewall, and the firewall options were not set as yet.  
www.compaq.com is an internal website to the machine, accessible without a 
proxy and not subject to the firewall, so we should have been able to contact 
this site.  (It was confirmed with Netscape 4.7).  Even after adjusting proxy 
settings, we get the same behavior of the window simply disappearing.  

Comment 10

[Christopher Blizzard (:blizzard)]

The reason that there were no alpha rpms is because it was crashing on startup
but you might have noticed that. :)

I'm respinning rpms now with a fix in them that have an additional fix in them
and there's a slight chance it might fix the problem.  If you do find the fix,
let me know and I can respin rpms for all the architectures.  I just don't have
time to track it down myself and I know that the tip does work on alpha linux.

Comment 11

[Christopher Blizzard (:blizzard)]

The rpms that I respun still don't work on alpha. :(

Comment 12

[Asa Dotzler [:asa]]

one of you guys wanna take this bug?

Comment 13

[Christopher Blizzard (:blizzard)]

This is an M16 bug.  I know that the tip does work on alpha linux so something
between then and now is beaking the alpha.  I don't have time to find it myself
so I don't want the bug.

Comment 14

[Asa Dotzler [:asa]]

setting bug Status to New.  adding qawanted and helpwanted keywords.

Comment 15

[Asa Dotzler [:asa]]

(John Goshdigian) can you test if this is still happening for you with a current
build.

Comment 16

[John Goshdigian]

We just tried the latest nightly build (Aug 2, 2000).  We built it from the 
source using gcc on Redhat 6.2.  The system was an Alpha XP1000 EV67 667 mhz.  
It compiled, linked, and ran correctly.  We were able to view any of the 
webpages we tried to.  So, it looks like the problem is solved!  Thank you!

Comment 17

[Asa Dotzler [:asa]]

Great! Resolving WORKSFORME per reporter's comments

Comment 18

[John Morrison]

verified per john and asa. Thanks.