38941 - Linux 2000-05-11 crashes on exit _everytime_

Status: VERIFIED WONTFIX

(Core :: Layout, defect, P3)

Description

[John Morrison]

The linux verification build from today will crash on exit 
_everytime_ [Simply start mozilla, then quit and talkback 
comes up]. 

Windows and mac builds for this morning do not have this crash.

Here is a sample trace from talkback (not particularly useful
other than it ends in raptorhtml.so

http://cyclone/reports/SingleIncidentInfo.cfm?dynamicBBID=10324763


libraptorhtml.so + 0x373044 (0x412e7044) 
libraptorhtml.so + 0x1df28a (0x4115328a) 
libraptorhtml.so + 0x20b87e (0x4117f87e) 
libraptorhtml.so + 0x36004b (0x412d404b) 
libraptorhtml.so + 0x365940 (0x412d9940) 
libraptorhtml.so + 0x3656a5 (0x412d96a5) 
libxpcom.so + 0x74e0f (0x400b2e0f) 
libdocshell.so + 0xd6e0 (0x4168e6e0) 
libraptorwebwidget.so + 0xe35c (0x4167b35c) 
libnsappshell.so + 0x1052c (0x4051852c) 
libnsappshell.so + 0x191f0 (0x405211f0) 
libnsappshell.so + 0x15bdb (0x4051dbdb) 
libnsappshell.so + 0x138dc (0x4051b8dc) 
libnsappshell.so + 0x139f5 (0x4051b9f5) 
libxpcom.so + 0x6ba84 (0x400a9a84) 
libxpcom.so + 0x3ea87 (0x4007ca87) 
libplds4.so + 0x1300 (0x4014c300) 
libxpcom.so + 0x3eb00 (0x4007cb00) 
libxpcom.so + 0x3ee2f (0x4007ce2f) 
libxpcom.so + 0x3ed4e (0x4007cd4e) 
libxpcom.so + 0x6bb52 (0x400a9b52) 
libxpcom.so + 0x6bbc1 (0x400a9bc1) 
libxpcom.so + 0x6c26d (0x400aa26d) 
libxpcom.so + 0x3a5d7 (0x400785d7) 
mozilla-bin + 0x35d9 (0x0804b5d9) 
libc.so.6 + 0x181eb (0x402331eb)

Comment 1

[sairuh (rarely reading bugmail)]

odd, i wasn't able to repro this using this am's opt comm bits...

Comment 2

[sairuh (rarely reading bugmail)]

addendum from jrgm: he removed his existing profile, and is no longer able to
repro this...

however, my current issue this that i can no longer start nscp, whether from
using claudius' new_build -d script, or even going into the install dir and
running ./netscape:

sairuh@hopey 86: ./netscape
.//run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=/u/sairuh/seamonkey/00051109/package
 
LD_LIBRARY_PATH=/u/sairuh/seamonkey/00051109/package/Cool:/u/sairuh/seamonkey/00051109/package:/u/sairuh/linux/seamonkey/package
         
LIBPATH=/u/sairuh/seamonkey/00051109/package:/u/sairuh/seamonkey/00051109/package/Cool
      
SHLIB_PATH=/u/sairuh/seamonkey/00051109/package:/u/sairuh/seamonkey/00051109/package/Cool
      XPCS_HOME=/u/sairuh/seamonkey/00051109/package/Cool
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
**************************************************
nsNativeComponentLoader: GetFactory(error) Load FAILED with error: error: cannot
open shared object file: No such file or directory
**************************************************
**************************************************
nsNativeComponentLoader: GetFactory(error) Load FAILED with error: error: cannot
open shared object file: No such file or directory
**************************************************

Comment 3

[Jeremy M. Dolan]

We'll, I've tracked this down, somewhat.

Linux builds have been segfaulting-on-exit "_everytime_" for some weeks now.

I deleted all mozilla prefs and restarted, viewed one page, exited fine.
Deleted Prefs/profile again, start up, view a few pages, and click on a mailto:
link. select 'quit' from the composer, and on exit i get this:

WEBSHELL- = 1
we have an event stuck -- removing it.
~nsProfile 
WEBSHELL- = 0

But no crash.
Keep profile, start up mozilla again, view one page, exit, crash.

It's not crashing every time, but the more I do while in mozilla (don't even
have to touch mail), the greater the crash of crash on exit:

~nsProfile 
WEBSHELL- = 0
.//run-mozilla.sh: line 29: 17272 Segmentation fault      $prog ${1+"$@"}

View at least 5 URLs, and it's pretty much a garunteed segfault-on-exit.

This is with may 7th build, though I don't think that matters much, like I said
I've been experiancing this for weeks. On my way to download todays build, ill
report if anything is differant.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I've seen this crash, but only on my profile rather than a blank one.  Here's
the stack trace:

> #0  0x4169ebeb in nsGenericElement::SetDocument (this=0x8254164,
>     aDocument=0x0, aDeep=1) at nsGenericElement.cpp:965
> #1  0x41440590 in nsGenericHTMLElement::SetDocument (this=0x8254164,
>     aDocument=0x0, aDeep=1) at nsGenericHTMLElement.cpp:830
> #2  0x41480ca6 in nsHTMLHtmlElement::SetDocument (this=0x8254150,
>     aDocument=0x0, aDeep=1) at nsHTMLHtmlElement.cpp:65
> #3  0x4167d81e in nsDocument::SetScriptGlobalObject (this=0x81ed570,
>     aScriptGlobalObject=0x0) at nsDocument.cpp:1509
> #4  0x41685b44 in DocumentViewerImpl::~DocumentViewerImpl (this=0x81e0e70,
>     __in_chrg=3) at nsDocumentViewer.cpp:406
> #5  0x416857e2 in DocumentViewerImpl::Release (this=0x81e0e70)
>     at nsDocumentViewer.cpp:344
> #6  0x402aeaac in nsCOMPtr<nsIContentViewer>::assign_assuming_AddRef (
>     this=0x81734ac, newPtr=0x0) at ../../dist/include/nsCOMPtr.h:450
> #7  0x402aeb28 in nsCOMPtr<nsIContentViewer>::assign_with_AddRef (
>     this=0x81734ac, rawPtr=0x0) at ../../dist/include/nsCOMPtr.h:830
> #8  0x402b79e7 in nsCOMPtr<nsIContentViewer>::operator= (this=0x81734ac,
>     rhs=0x0) at ../../dist/include/nsCOMPtr.h:565
> #9  0x402e5b20 in nsDocShell::Destroy (this=0x8173418) at nsDocShell.cpp:1292
> #10 0x402abde6 in nsWebShell::Destroy (this=0x8173418) at nsWebShell.cpp:1598
> #11 0x406901c8 in nsXULWindow::Destroy (this=0x80ffb40) at nsXULWindow.cpp:413
> #12 0x4069f23e in nsWebShellWindow::Destroy (this=0x80ffb40)
>     at nsWebShellWindow.cpp:1728
> #13 0x40699467 in nsWebShellWindow::Close (this=0x80ffb40)
>     at nsWebShellWindow.cpp:365
> #14 0x40695acc in nsAppShellService::~nsAppShellService (this=0x8116498,
>     __in_chrg=3) at nsAppShellService.cpp:94
> #15 0x40695c64 in nsAppShellService::Release (this=0x8116498)
>     at nsAppShellService.cpp:107
> ...

Comment 5

[leger]

Adding crash keyword

Comment 6

[harishd]

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

Comment 7

[harishd]

Reassinging to vidur. Refer bug 39307.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The line of this crash actually seems to be in XBL code:

bindingManager->GetBinding(mContent, getter_AddRefs(binding));

bindingManager is null.  cc:ing hyatt.

Note:  I can reproduce this reliably.  If you want a copy of my profile (or
parts thereof) or want me to help debug a little, I can help.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This crash looks like it should be fixed by the fix to bug 39744, although since
an assertion was added with the fix, there's probably still something wrong
here.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, maybe not, if it was the bindingManager that was null...

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, definitely not, since those changes were in a different file.

Comment 12

[David Hyatt]

mine.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The aspect of my profile that was causing this was that GFX scrollbars were
turned off.

Comment 14

[Peter Trudelle]

resolving as wontfix, since it only occurs with native scrollbars, which are 
unsupported.

Comment 15

[John Morrison]

verified wontfix