41414 - Crash in [@nsProxyEventObject::GetNewOrUsedProxy()]

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect, P1)

Description

[David Krause]

Overview Description:
Mozilla crashes sometimes on startup when trying to load the chrome.

Steps to Reproduce:
1) remove .mozilla
2) remove old nightly and download latest
3) ./mozilla
4) watch it segfault

Actual Results:
WEBSHELL+ = 1
WEBSHELL+ = 2
CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/david/.mozilla/default/
>chrome/user.css' failed.  Error code: 16389
CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/button.css'
> failed.  Error code: 16389
.//run-mozilla.sh: line 29: 30683 Segmentation fault      $prog ${1+"$@"}

Expected Results:
starts normally

Reproducibility:
about 60% of the time

Build Date & Platform Bug Found:
2000060308 linux i686 redhat 6.2

Additional Builds and Platforms Tested On:
this has been happening on earlier builds also

Additional Information:
each time it fails on a different file (see below)

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome:
//communicator/skin/sidebar/sidebar.css' failed.  Error code: 16389
.//run-mozilla.sh: line 29:  7792 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://global/skin/menulist.css'
failed.  Error code: 16389
.//run-mozilla.sh: line 29:  3028 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://global/skin/splitter.css'
failed.  Error code: 16389
.//run-mozilla.sh: line 29:  2998 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://global/skin/radio.css'
failed.  Error code: 16389
.//run-mozilla.sh: line 29:  1797 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://global/skin/button.css'
failed.  Error code: 16389
.//run-mozilla.sh: line 29:  1635 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome:
//communicator/skin/formatting.css' failed.  Error code: 16389
.//run-mozilla.sh: line 29:  1443 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/menu.css'
failed.  Error code: 16389
.//run-mozilla.sh: line 29:  1251 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/button.css'
failed.  Error code: 16389
.//run-mozilla.sh: line 29:   680 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/box.css'
failed.  Error code: 16389
.//run-mozilla.sh: line 29:   658 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome:
//communicator/skin/sidebar/sidebar.css' failed.  Error code: 16389
.//run-mozilla.sh: line 29: 31830 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://global/skin/button.css'
failed.  Error code: 16389
.//run-mozilla.sh: line 29: 31095 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome:
//communicator/skin/formatting.css' failed.  Error code: 16389
.//run-mozilla.sh: line 29: 31064 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/menu.css'
failed.  Error code: 16389
.//run-mozilla.sh: line 29: 31024 Segmentation fault      $prog ${1+"$@"}

CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/button.css'
failed.  Error code: 16389
.//run-mozilla.sh: line 29: 30683 Segmentation fault      $prog ${1+"$@"}

Comment 1

[David Krause]

Attachment: stack trace

Comment 2

[David Krause]

reassigning to XPCOM component as per the stack trace

Comment 3

[leger]

valeski, you the right person for this?

jrgm can you reproduce internally?

Comment 4

[Judson Valeski]

probably not. I'm guessing that Ben's resource changes over the weekend are the 
root???

Comment 5

[John Morrison]

I can't reproduce with the same build 06/03, or with today's mozilla build
on a RH6.1 system.

Comment 6

[don]

Hmmm, let me a pull a tree and see if I can reporduce this ...

Comment 7

[don]

Actually, why don't I first attempt to spell "reproduce" correctly. :-)

Comment 8

[don]

OK, my build from this morning works just fine.  Resolving as "WORKSFORME".  Can
anybody else reproduce this?

Comment 9

[David Krause]

I am still noticing this on the latest nightly.  Unfortuately everyone I have
talked to seems unable to reproduce this.  The wierd thing is that this bug only
occurs part of the time.  It will crash several times in a row and then suddenly
load fine with no problems.  My box is Redhat 6.2 with updates and nothing out
of the ordinary I don't think.  I have been having this problem for around a
month now but have been using mozilla for a while with nothing like this before.

Comment 10

[don]

Ben, can you reproduce this?  If not, resolve it as WORKSFORME until we can find
a repeatable scenario.

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

worksforme. check to see that your chrome dir is completely up to date. lots of 
changes have been happening recently. 

Comment 12

[David Krause]

Reopening because someone else besides me has finally reproduced it.  Go SuSE!!

Comment 13

[David Krause]

*** Bug 41696 has been marked as a duplicate of this bug. ***

Comment 14

[David Krause]

Please read the comments from bug 41696.  He suggests maybe a threading problem
which would explain the randomness of this bug.  Also, like he said you can
eventually get it to start if you keep trying like 20 times. Really cuts into my
ability to bugtest mozilla though. :(

Comment 15

[John Morrison]

Yes, this is beginning to sound like a threading issue while loading the 
initial bit of chrome. So far this has only been seen on RH 6.2 and Suse

----------------------------------------------------------------------
Comments from bug #41414, by Daniel Egger: 

  Mozilla is sometimes crashing at startup time with random messages,
  sometimes with segmentation fault and sometimes with illegal instruction.
  
  I manage to get it working though by restarting it about 20 times.
  
  nNCL: registering deferred (0)
  
  Gdk-WARNING **: locale not supported by C library
  WEBSHELL+ = 1
  WEBSHELL+ = 2
  CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:
  ///root/.mozilla/default/chrome/user.css' failed.  Error code: 16389
  CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/box.css'
  failed.  Error code: 16389
  Ungültiger Maschinenbefehl
  
  The last line means illegal instruction.
  
  Unfortunately I cannot further debug it because debugging builds run fine
  and the nondebug build is even crashing gdb (version 4.17.0.13 with threads
  support as well as 5.0).
  
  The crash itself is REALLY random thus I believe it's a threading problem.
  I tried different things like different compilers (currently gcc 2.95.2
  otherwise the latest CVS version) different linux kernels, different
  machines, different locales and different glibc versions.
  
  This bug is there for me at least 1 month now.
  
  My normal configure options are:
  --disable-debug --disable-tests --disable-mailnews
  
  Changing them to other values doesn't help either. Optimized builds are
  even more broken and debugging builds don't crash.
  
  I'd really like to try some patch or ideas if someone steps up with
  something...

Comment 16

[John Morrison]

Removing '[dogfood+][nsbeta2-]' for reconsideration in the interim. We have not 
reproduced it here at Mt. View, and we'll need to do that first, or get help 
from Daniel or David to sort this out.

Comment 17

[leger]

Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2.

Comment 18

[Daniel Egger]

Okay, finally I can reproduce it with 100% chance.
It's thread related: TestThreads shows this very clearly as
randomly different numbers are missing. It only occurs on non
debugging builds of libnspr.so. When I replace a normal version
by one containing debugging symbols, everything runs fine
(including TestThreads).
I'm going to investigate further whether it's an nspr problem
or a libc/libpthreads race and which systems are affected or how
this one can be circumvented.
As a temporary workaround I'd suggest building nspr ALWAYS with
debugging...

Comment 19

[tarrant_tristan]

It has been happening to me as well: once it took me 23 retries before Mozilla
started...

Tristan

Comment 20

[David Krause]

cc'ing rpotts and wtc as this appears to be a threading/nspr issue

Comment 21

[Wan-Teh Chang]

I read the comments in this bug report.  I don't
see anything obviously wrong with NSPR.  Note
that TestThreads does not use NSPR directly,
but rather through nsIThread and nsIThreadPool.

Comment 22

[Warren Harris]

Does this depend on having an SMP system to reproduce?

Maybe dougt should look at this since he's back now and it dies in the proxy 
event code.

Comment 23

[Daniel Egger]

It crashes my non SMP system. Haven't tried SMP, yet...

Comment 24

[David Krause]

I second that.  It crashes on my single processor system.  I don't have an SMB 
system to test it on.

Comment 25

[Warren Harris]

I can't reproduce this.

Comment 26

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 27

[jr]

when i pull a build from mozilla.org it cannot start up on my rh6.2-linux2.2.16
box. if i pull from cvs & build it works. if i pull
build from mozilla.org & replace libnspr4.so with one built locally from
cvs sources it works, i think something is screwy with build process of
libnspr4.so that causes this behavior - i get what others above have described
when i use pure mozilla.org build w/o locally built libnspr4.so

Comment 28

[Wan-Teh Chang]

Is there a RedHat 6.2 box at Netscape that I
can use?

Comment 29

[John Morrison]

Yes, there is one that I have set up in the cube across from mine. However, I 
can run the mozilla nightly builds on it with no problem. I haven't set it up 
as a development system yet, but that could be done as needed. I am in cube 
27012, building 21, second floor. 

However, it is being used on a part-time basis for the Palo Alto kids, but 
Claudius, can we make arrangements for wtc to make use of it for a bit? 

Comment 30

[Claudius Gayle]

not a problem. They're typically there from 2-6 but have other machines available to them if that one is needed in a pinch.

Comment 31

[Warren Harris]

Honestly, I'm not going to get to this bug. Handing it off to a linux guru --> 
pavlov.

Comment 32

[leger]

Moving from [nsbeta2+] to [nsbeta2-] per todays PDT XP Toolkit Beta2 Review mtg.

Comment 33

[Daniel Egger]

It seems this bug appears only with the latest versions of glibc2
i.e. glibc 2.1.3. I can reproduce it on my own system as I can
on SuSE linux 6.3, 6.4, 7.0beta. If you want to do the same feel
free to ask for some packages and I'll send them to you.

I checked in a workaround for SuSE Linux 7.0 which basically builds
mozilla with debugging and strips it afterwards which has the slight
disadvantage of having tons of debugging output, but since I don't
have time to search the bug and no better idea how to get around this,
this will make it into the distribution.

Comment 34

[Daniel Egger]

This bug is the same as 29182. Please merge.

Comment 35

[Peter Trudelle]

*** This bug has been marked as a duplicate of 29182 ***

Comment 36

[John Morrison]

verified duplicate.

Comment 37

[Doug Turner (:dougt)]

This is a root bug.  I am reopening it and look at it.

Comment 38

[Doug Turner (:dougt)]

crap.  Not this bug.  I am going to reopen and look at another bug....

Comment 39

[Doug Turner (:dougt)]

this is the bug that I reopened: 47046.  This bug and 47046 are dups.

Comment 40

[David Krause]

reopening since dougt thinks that this bug is not a dup

Comment 41

[David Krause]

assigning to dougt and marking bug 47046 as dup

Comment 42

[David Krause]

*** Bug 47046 has been marked as a duplicate of this bug. ***

Comment 43

[David Krause]

fixing summary
removing old whiteboard comments

also see talkbacks in bug 47046

Comment 44

[Doug Turner (:dougt)]

Daniel Egger - can you confirm again that this is only a problem with glibc
2.13?  Anyone else?

Comment 45

[Daniel Egger]

I can confirm that the problems went away after upgrading to the latest
stable GLIBC from CVS two weeks ago. Thus I really suspect it's related
to some weird linuxthreads bug...

Comment 46

[Doug Turner (:dougt)]

Okay.  Marking WONTFIX.  

Comment 47

[R.K.Aa.]

Take a look at bug 51164 and bug 51225.

Comment 48

[R.K.Aa.]

Oh..btw.. A problem with glibc 2.1.3 is not "only".
If this bug remains  "wontfix", it means moz doesn't support RH6.*
All RH6 versions are for now glibc-2.1.3-* after the latest errata. 

Comment 49

[Doug Turner (:dougt)]

?  I am running rh6.2 and I can not reproduce this.

Comment 50

[Christopher Blizzard (:blizzard)]

I tried this with both the upgraded glibc and the old glibc and it crashes
equally as badly with either.

Comment 51

[Doug Turner (:dougt)]

Chris, alot of folks are having trouble reproducing this.  Did you have trouble?

reopening until we have a better understanding of what is going on.

Comment 52

[Doug Turner (:dougt)]

*** Bug 51482 has been marked as a duplicate of this bug. ***

Comment 53

[R.K.Aa.]

Upgrading to the latest errata of glibc from RedHat: glibc-2.1.3-21
(released on the 7th) fixed every oddity i've seen the past week, also this
crash here.

Comment 54

[Doug Turner (:dougt)]

sounds like i DONT have to do anything.  Marking as WONTFIX.