Closed Bug 51482 Opened 24 years ago Closed 24 years ago

can't start mozilla. crash at the beginning.

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 41414

People

(Reporter: tapio.piironen, Assigned: dougt)

References

Details

I cannot start mozilla 2000090506. Previous nightly build did this too.
Crashlog:

[gandalf@HALVI153 package]$ ./mozilla
./run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.::/opt/netware/lib:/opt/netware/lib
     LIBRARY_PATH=.
       SHLIB_PATH=.
          LIBPATH=.
       ADDON_PATH=.
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
WEBSHELL+ = 1
CSSLoaderImpl::LoadAgentSheet: Load of URL
'file:///home/gandalf/.mozilla/default/chrome/userChrome.css' failed.  Error
code: 16389
CSSLoaderImpl::LoadAgentSheet: Load of URL
'file:///home/gandalf/.mozilla/default/chrome/userContent.css' failed.  Error
code: 16389
WEBSHELL+ = 2
CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://global/skin/menu.css'
failed.  Error code: 16389

So I have removed .mozilla some times, doesnt help.
My system is redhat 6.2 with newest updates.

-tapio
Yep I just started having this exact problem on this exact system
Thanks for ur "latest update" detail, helped me figure out the glibc update
fuggered it
I have no idea where to send this bug to :( I'll leave it browser general and
confirm it
anyone want me to get some data from my box I will gladly and promptly do so :P
Severity: normal → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Starting with..
change in changelog from the glibc-2.1.3-15 rpm (shipped) and the update
2.1.3-19

* Sat Sep 02 2000 Jakub Jelinek <jakub@redhat.com>

- two more locale related security fixes

* Fri Sep 01 2000 Jakub Jelinek <jakub@redhat.com>

- don't allow LANG/LC_* to contain / in suid/sgid programs
- Solar Designer's crypt alignment patch

* Sat Aug 26 2000 Jakub Jelinek <jakub@redhat.com>

- properly unset LD_ variables in setuid/setgid applications
- fix timezone handling with certain settings of TZ environment variable
- avoid thread deadlocks in certain situations (#13785)

hrm
By the way, the output of ./mozilla isn't too useful, with the older glibc
mozilla just continues on WEBSHELL+ = 3 through to successfully loading the
browser
I too confirm this bug with the latest nightly build.  
redhat's got this at http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=17203
according to the changelog, the problem comes from using a newer base glibc
sources package in the new rpm

over to dougt
Assignee: asa → dougt
I am also seeing this problem. I posted this to a dupe of this bug(51653) by
mistake. =( If the third webshell opens it loads. From GDB:

(gdb) run
Starting program: /home/greg/package/./mozilla-bin 
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...[New Thread 9769 (manager thread)]
[New Thread 9766 (initial thread)]
[New Thread 9770]
WEBSHELL+ = 1
[New Thread 9771]
CSSLoaderImpl::LoadAgentSheet: Load of URL
'file:///home/greg/.mozilla/default/chrome/userChrome.css' failed.  Error code:
16389
CSSLoaderImpl::LoadAgentSheet: Load of URL
'file:///home/greg/.mozilla/default/chrome/userContent.css' failed.  Error code:
16389
WEBSHELL+ = 2
[New Thread 9772]

Program exited with code 01.
dupe of 51164?
is this fixed now? cause 51164 is.
*** Bug 51653 has been marked as a duplicate of this bug. ***
*** Bug 51674 has been marked as a duplicate of this bug. ***
this is probably a dupe of bug 51164.  Can someone experiencing this problem
test a current build and see if it is fixed.  Thanks
Bug 41414 is for problems with certain versions of glibc.
Still happens here about 3 out of every 5 starts. Using Kernel 2.2.17 on a RH 
6.2 system with the new security fixed GLIBC. Mozilla build id 2000090708.
This really sounds like a dup of Bug 41414.  Asa, can you take a look at that?
One thing that is differant is that I don't think its segfaulting. It seems 
like its exiting... When I tried to run a stack trace GDB claimed there was no 
stack.
I suspect that those seeing this with the new glibc are seeing bug 41414.
Redhat relesed a bugfix GLIBC 2.1.3-21 which fixed this for me. The release
earlier in the week was 2.1.3-19. In the errata for -21 it mentions fixing
threading issues that show up in Mozilla.

It doesn't look like this is Mozilla's fault.
I'm running 90508 and it's most definitely not fixed..

bug 41414? well.. the glibc update we're talking about was only issued in the
last few days, mozilla isn't segfaulting, it's exit(1)ing as greg's gdb run (and
my own) show.

The -21 update fixes the problem by pulling out the newer glibc tarball
that they threw in with the -19 update.


this is a dup. 

*** This bug has been marked as a duplicate of 41414 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Did this fix it for everyone? if yes, please mark verified dupe.
I don't have the power to mark it as verified, but the latest nightly build
starts up fine for me.
works for me with the -21 update
marking verified per users comments
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.