464389 - [@ DEBUG_CheckWrapperThreadSafety] Crash when dismissing Safe Mode dialog, if I press anything but "Continue in Safe Mode"

Status: VERIFIED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Daniel Holbert [:dholbert]]

STEPS TO REPRODUCE:
 1. Run "firefox -no-remote -safe-mode"
 2. When Safe Mode dialog appears, do any of the following:
        press "Esc" key...
    OR: press the "X" on the titlebar, to close it
    OR: press "Quit" button
    OR: check any checkbox and press "Make Changes And Restart"

RESULTS: Firefox crashes.

This happens with a completely fresh profile (e.g. "mkdir foo; firefox -profile foo -no-remote -safe-mode"), as well as with my existing normal-use profile.

It seems to crash when I dismiss the dialog in any way *other* than clicking "Continue in Safe Mode"

(Possibly related to bug 455617?)

Comment 1

[Daniel Holbert [:dholbert]]

Below are some crash reports for this crash.  They all have one of these three signatures:
  [@ libgobject-2.0.so.0.1800.2@0x295ef ]
  [@ libgobject-2.0.so.0.1800.2@0x295d2 ]
  [@ imgRequest::NotifyProxyListener(imgRequestProxy*) ]

(I'm not sure, but I think the signature might depend on button used to dismiss the safe-mode dialog -- esc key vs. close button vs. etc.)

http://crash-stats.mozilla.com/report/index/c86b3d4d-612e-4de0-bbcd-fa4220081111
http://crash-stats.mozilla.com/report/index/268e8f01-6a40-4dd0-8bf5-6e5e20081111
http://crash-stats.mozilla.com/report/index/04342264-31fc-48ba-8061-dc9620081111
http://crash-stats.mozilla.com/report/index/6af8079b-681a-4551-8f9c-b92c20081111
http://crash-stats.mozilla.com/report/index/54d3ae05-0e3f-4894-8785-76ca20081111
http://crash-stats.mozilla.com/report/index/76e7e8cd-23e6-49a3-8d4c-c84a20081111
http://crash-stats.mozilla.com/report/index/ca267126-3922-436d-b637-d97320081111

Comment 2

[Daniel Holbert [:dholbert]]

Build ID:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081111 Minefield/3.1b2pre

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

WFM on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081111 Minefield/3.1b2pre

Comment 4

[Daniel Holbert [:dholbert]]

Thanks, Gary! Sounds like this is a Linux-only issue.

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Confirming on Ubuntu 8.04:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081111 Minefield/3.1b2pre

http://crash-stats.mozilla.com/report/index/8aaff8c8-4a4a-4459-ade2-dcb720081111

I pressed "Quit" and it crashed at libgobject-2.0.so.0.1600.3

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Regression range?

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

passes: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081104 Minefield/3.1b2pre

fails: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081105 Minefield/3.1b2pre

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #7)
> passes: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081104
> Minefield/3.1b2pre
> 
> fails: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081105
> Minefield/3.1b2pre

sorry, regression range for another issue, my bad.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #8)
> sorry, regression range for another issue, my bad.

Was for bug 463938.

Comment 10

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I don't have much time to test this fully, but 2008-11-04 Linux builds crash when pressing "Quit", builds as far back as 2008-10-23 and 2008-10-09 crash only when clicking "No" to the dialog asking whether to set Firefox as default, but this is strange because I had pressed "Quit" too.

There's tons of output spew for the 2008-10-09 builds:

(many identical lines of:)
(firefox-bin:7225): Gdk-CRITICAL **: gdk_gc_set_ts_origin: assertion `GDK_IS_GC (gc)' failed

(firefox-bin:7225): Gdk-CRITICAL **: gdk_gc_set_ts_origin: assertion `GDK_IS_GC (gc)' failed

(firefox-bin:7225): Gtk-CRITICAL **: gtk_paint_shadow: assertion `style->depth == gdk_drawable_get_depth (window)' failed

Comment 11

[Daniel Holbert [:dholbert]]

Regression Window:

WORKS: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080911020347 Minefield/3.1b1pre

BROKEN: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080912020354 Minefield/3.1b1pre

Comment 12

[Daniel Holbert [:dholbert]]

HG link for regression range ("2008-09-11 00:00:00" to "2008-09-12 04:00:00"): 
http://tinyurl.com/5j73vz

Comment 13

[Daniel Holbert [:dholbert]]

I've narrowed it to between changeset 475542ec5079 (works) and changeset a530d5f2f15a (broken), with a few changesets landing in between those.

I suspect changeset a530d5f2f15a as the problem (bug 453146), because all the other changesets between those two look pretty trivial.

I'm currently building that changset's parent (8fcf92cfd811) to confirm this.

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to comment #13)
> I suspect changeset a530d5f2f15a as the problem (bug 453146)
> I'm currently building that changset's parent (8fcf92cfd811) to confirm this.

Yeah, that's the one. If I do
  hg revert --all -r 8fcf92cfd811
then the safe-mode dialog works fine, but if I do
  hg revert --all -r a530d5f2f15a
then I get crashes and the Gtk/Gdk errors mentioned in Comment 10 when I dismiss the safe-mode dialog.

Adding dependency on that bug.

Comment 15

[Peter Van der Beken [:peterv]]

That's odd, can you check if nsJSRuntime::Shutdown is called before the crash?

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

Any update here?

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to comment #16)
> Any update here?

Sorry -- I somehow missed comment 15.

peterv: In answer to comment 15 -- that method is *not* called.  I just ran safe-mode firefox, placed a breakpoint in nsJSRuntime::Shutdown, and then pressed "Quit" on the safe-mode dialog.  I crashed, and the breakpoint never got hit.

The crash was at this line:
http://mxr.mozilla.org/mozilla-central/source/js/src/xpconnect/src/xpcwrappednative.cpp#3446
>  3446     else if(NS_SUCCEEDED(wrapper->mThread->IsOnCurrentThread(&val)) && !val)

At this point, wrapper->mThread is a null XPCOM pointer, which is presumably the cause of the crash.

I also fail this assertion just before the crash (presumably about mThread's nullness):
###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../../../dist/include/xpcom/nsCOMPtr.h, line 796

I'll attach a backtrace in a second.

Comment 18

[Daniel Holbert [:dholbert]]

Attachment: backtrace of crash

Here's the backtrace of the crash, from my previous comment.

Comment 19

[Daniel Holbert [:dholbert]]

(FWIW, the crash in comment 17 & 18 is from an up-to-date mozilla-central build, at revision 48cf9ff42c74)

Comment 20

[timeless]

Attachment: catch problem sooner

dholbert: so um.... 

#0  0xb4f45aa9 in DEBUG_CheckWrapperThreadSafety
...
#11 0xb5a94201 in nsXBLProtoImplAnonymousMethod::Execute
...
#15 0xb5b1b2f8 in nsGlobalWindow::PostHandleEvent
...
#20 0xb5564e49 in DocumentViewerImpl::PageHide
...
#23 0xb47e9f7d in ~nsWebShell
...
#28 0xb5200270 in ~nsXULWindow
...
#33 0xb52086c5 in ~nsWindowInfo
...
#34 0xb5211aff in nsWindowMediator::UnregisterWindow
...
#35 0xb5211d76 in ~nsWindowMediator
...
#40 0xb7c6573e in FreeServiceContractIDEntryEnumerate
...
#43 0xb7c041a5 in NS_ShutdownXPCOM_P

nsWindowMediator is a service, it's dying at shutdown (this is vaguely ok)
It's letting go of the last window it has (i'm not sure if this is ok)
The window is triggering webshell destruction including a pagehide (this seems vaguely bad)
That triggers a dom event (this is bad)
That triggers xbl (which involves some js)
That involves xpconnect which will try to get the current thread, which i believe at a certain point goes off and becomes null (by which point we're hosed)
Then the debug code goes off and tries to use the thread it got earlier (see patch) and dies.

Since dying isn't really comfortable, we can yell early and be vaguely tolerant later.

That said, it'd be nice if smaug or bz or someone could speak to the rest of the summarized stack trace.

Comment 21

[timeless]

I think the other two crash signatures are:
bug 484442 [@ g_object_set_data - setup_widget_prototype]
Bug 441563 [@ imgRequest::NotifyProxyListener(imgRequestProxy*)]

Comment 22

[Boris Zbarsky [:bzbarsky]]

> It's letting go of the last window it has (i'm not sure if this is ok)

It should do this earlier, imo.  Like say off the xpcom-shutdown notification or some such.  Benjamin might be tell you which exact notification you want here.

Comment 23

[Benjamin Smedberg]

Yeah, windowmediator should let go of its windows at xpcom-shutdown or even before at quit-application.

Comment 24

[timeless]

filed bug 514638 with a patch for that....

Comment 25

[Daniel Veditz [:dveditz]]

Assuming crash is unexploitable since the app is shutting down before having loaded any remote content yet.

Comment 26

[timeless]

dholbert: can you indicate how this behaves today? the bug from comment 24 is resolved.

Comment 27

[Daniel Holbert [:dholbert]]

Hooray, this is WORKSFORME now!  Resolving as such.  (Feel free to change to FIXED if you're confident that comment 24 is what fixed it.)

I tried everything under "Step 2" from comment 0, and everything worked as expected, with no crashes.

I'm running Ubuntu 10.10, with:
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101007 Firefox/4.0b8pre

Comment 28

[timeless]

nah, worksforme is fine, but could you verify bug 514638 since that's the one that "fixed" this.

Comment 29

[Daniel Holbert [:dholbert]]

How do I verify that bug? (there's no clear STR there)

Comment 30

[Daniel Holbert [:dholbert]]

ok, verified.  Thanks for fixing!