559534 - e10s: valgrind reports uninitialized value in nsDocShell::EnsureScriptEnvironment

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Josh Matthews [:jdm]]

==16113== Thread 2:
==16113== Conditional jump or move depends on uninitialised value(s)
==16113==    at 0x5029FAD: nsDocShell::EnsureScriptEnvironment() (nsDocShell.cpp:10291)
==16113==    by 0x50071D8: nsDocShell::GetInterface(nsID const&, void**) (nsDocShell.cpp:858)
==16113==    by 0x5575CA6: nsGetInterface::operator()(nsID const&, void**) const (nsIInterfaceRequestorUtils.cpp:52)
==16113==    by 0x469CD46: nsCOMPtr<nsIDOMWindow>::assign_from_helper(nsCOMPtr_helper const&, nsID const&) (nsCOMPtr.h:1249)
==16113==    by 0x469A4F4: nsCOMPtr<nsIDOMWindow>::nsCOMPtr(nsCOMPtr_helper const&) (nsCOMPtr.h:621)
==16113==    by 0x50B61AB: nsWebBrowser::GetContentDOMWindow(nsIDOMWindow**) (nsWebBrowser.cpp:414)
==16113==    by 0x50B9AE3: nsWebBrowser::Create() (nsWebBrowser.cpp:1225)
==16113==    by 0x546DA14: mozilla::dom::TabChild::RecvcreateWidget(unsigned long const&) (TabChild.cpp:350)
==16113==    by 0x5535115: mozilla::dom::PIFrameEmbeddingChild::OnMessageReceived(IPC::Message const&) (PIFrameEmbeddingChild.cpp:611)
==16113==    by 0x552FEFC: mozilla::dom::PContentProcessChild::OnMessageReceived(IPC::Message const&) (PContentProcessChild.cpp:220)
==16113==    by 0x548F124: mozilla::ipc::AsyncChannel::OnDispatchMessage(IPC::Message const&) (AsyncChannel.cpp:245)
==16113==    by 0x54954BE: mozilla::ipc::RPCChannel::OnMaybeDequeueOne() (RPCChannel.cpp:417)
==16113== 

>    nsCOMPtr<nsIWebBrowserChrome> browserChrome(do_GetInterface(mTreeOwner));
>    NS_ENSURE_TRUE(browserChrome, NS_ERROR_NOT_AVAILABLE);
>
>    PRUint32 chromeFlags;
>    browserChrome->GetChromeFlags(&chromeFlags);
>
>    PRBool isModalContentWindow =
>        (chromeFlags & nsIWebBrowserChrome::CHROME_MODAL) &&
>        !(chromeFlags & nsIWebBrowserChrome::CHROME_OPENAS_CHROME);

I assume this is because the return value of GetChromeFlags isn't being checked, and it's probably failing because of some assumption that's been violated with the advent of e10s.

Comment 1

[Boris Zbarsky [:bzbarsky]]

It's because of this:

  NS_IMETHODIMP
  TabChild::GetChromeFlags(PRUint32* aChromeFlags)
  {
    return NS_ERROR_NOT_IMPLEMENTED;
  }

We can add a check in docshell, but TabChild needs to be fixed too.  It really does.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Forward nsIXULWindow.chromeFlags to remote tabs

The spam from this was bugging me during valgrind runs.

This is an intermediate solution bz and I discussed on IRC --- instead of adding an nsIXULWindow listener interface to allow the TabParent to forward chromeFlag changes to the content process, we instead optimistically assume (checked by a new assert) that the chrome flags are frozen by the time we create the remote <browser>.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

http://hg.mozilla.org/mozilla-central/rev/bfba1780141d