Closed Bug 591555 Opened 11 years ago Closed 11 years ago

Crash [@ mozilla::layers::PLayersParent::DeallocShmem]

Categories

(Core :: IPC, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
fennec 2.0b1+ ---

People

(Reporter: mfinkle, Assigned: cjones)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

Here's the back trace:

#0  0x00007f0c438d735d in nanosleep () from /lib/libc.so.6
#1  0x00007f0c438d71d0 in sleep () from /lib/libc.so.6
#2  0x00007f0c44a14237 in ah_crap_handler (signum=11) at /home/mfinkle/source/cedar/mozilla/toolkit/xre/nsSigHandlers.cpp:132
#3  0x00007f0c44a179fc in nsProfileLock::FatalSignalHandler (signo=11, info=0x7fff9795a2f0, context=0x7fff9795a1c0)
    at nsProfileLock.cpp:221
#4  <signal handler called>
#5  0x00007f0c45f739bc in mozilla::layers::PLayersParent::DeallocShmem (this=0x7f0c275a3d80, aMem=...) at PLayersParent.cpp:396
#6  0x00007f0c46282a76 in mozilla::layers::ShadowLayerManager::DestroySharedSurface (this=0x7f0c2cfbe8e0, aSurface=0x7f0c26c991c0)
    at /home/mfinkle/source/cedar/mozilla/gfx/layers/ipc/ShadowLayers.cpp:335
#7  0x00007f0c4626b120 in mozilla::layers::BasicShadowThebesLayer::Disconnect (this=0x7f0c2cc73f00)
    at /home/mfinkle/source/cedar/mozilla/gfx/layers/basic/BasicLayers.cpp:1646
#8  0x00007f0c46287213 in mozilla::layers::ShadowLayerParent::ActorDestroy (this=0x7f0c274ba680, 
    why=mozilla::ipc::IProtocolManager<mozilla::ipc::RPCChannel::RPCListener>::Deletion)
    at /home/mfinkle/source/cedar/mozilla/gfx/layers/ipc/ShadowLayerParent.cpp:79
#9  0x00007f0c45f725c9 in mozilla::layers::PLayerParent::DestroySubtree (this=0x7f0c274ba680, 
    why=mozilla::ipc::IProtocolManager<mozilla::ipc::RPCChannel::RPCListener>::Deletion) at PLayerParent.cpp:283
#10 0x00007f0c45f71e82 in mozilla::layers::PLayerParent::OnMessageReceived (this=0x7f0c274ba680, __msg=...) at PLayerParent.cpp:88
#11 0x00007f0c45f644cf in mozilla::dom::PContentParent::OnMessageReceived (this=0x7f0c2cf76c00, __msg=...) at PContentParent.cpp:342
#12 0x00007f0c45f1311f in mozilla::ipc::AsyncChannel::OnDispatchMessage (this=0x7f0c2cf76c10, msg=...)
    at /home/mfinkle/source/cedar/mozilla/ipc/glue/AsyncChannel.cpp:262
#13 0x00007f0c45f1bcce in mozilla::ipc::RPCChannel::OnMaybeDequeueOne (this=0x7f0c2cf76c10)
    at /home/mfinkle/source/cedar/mozilla/ipc/glue/RPCChannel.cpp:438
#14 0x00007f0c45f21bb6 in void DispatchToMethod<mozilla::ipc::RPCChannel, bool (mozilla::ipc::RPCChannel::*)()>(mozilla::ipc::RPCChannel*, bool (mozilla::ipc::RPCChannel::*)(), Tuple0 const&) () from /home/mfinkle/source/cedar/mobile-debug/dist/bin/libxul.so
#15 0x00007f0c45f21b06 in RunnableMethod<mozilla::ipc::RPCChannel, bool (mozilla::ipc::RPCChannel::*)(), Tuple0>::Run() ()
   from /home/mfinkle/source/cedar/mobile-debug/dist/bin/libxul.so
#16 0x00007f0c45f1d66b in mozilla::ipc::RPCChannel::RefCountedTask::Run() ()
   from /home/mfinkle/source/cedar/mobile-debug/dist/bin/libxul.so
#17 0x00007f0c45f1d76e in mozilla::ipc::RPCChannel::DequeueTask::Run() ()
   from /home/mfinkle/source/cedar/mobile-debug/dist/bin/libxul.so
#18 0x00007f0c461867c6 in MessageLoop::RunTask (this=0x7f0c365116a0, task=0x7f0c26c877a0)
    at /home/mfinkle/source/cedar/mozilla/ipc/chromium/src/base/message_loop.cc:343
#19 0x00007f0c46186836 in MessageLoop::DeferOrRunPendingTask (this=0x7f0c365116a0, pending_task=...)
    at /home/mfinkle/source/cedar/mozilla/ipc/chromium/src/base/message_loop.cc:351
#20 0x00007f0c46186c34 in MessageLoop::DoWork (this=0x7f0c365116a0)
    at /home/mfinkle/source/cedar/mozilla/ipc/chromium/src/base/message_loop.cc:451
#21 0x00007f0c45f190f6 in mozilla::ipc::MessagePump::Run (this=0x7f0c36525880, aDelegate=0x7f0c365116a0)
    at /home/mfinkle/source/cedar/mozilla/ipc/glue/MessagePump.cpp:114
#22 0x00007f0c461862d1 in MessageLoop::RunInternal (this=0x7f0c365116a0)
    at /home/mfinkle/source/cedar/mozilla/ipc/chromium/src/base/message_loop.cc:219
#23 0x00007f0c46186256 in MessageLoop::RunHandler (this=0x7f0c365116a0)
    at /home/mfinkle/source/cedar/mozilla/ipc/chromium/src/base/message_loop.cc:202
#24 0x00007f0c461861e7 in MessageLoop::Run (this=0x7f0c365116a0)
    at /home/mfinkle/source/cedar/mozilla/ipc/chromium/src/base/message_loop.cc:176


From the frame:

(gdb) frame 5
#5  0x00007f0c45f739bc in mozilla::layers::PLayersParent::DeallocShmem (this=0x7f0c275a3d80, aMem=...) at PLayersParent.cpp:396
396	    bool ok = DestroySharedMemory(aMem);
Thanks.

What page were you on when this happened?  Were you doing something "unusual" like tab switching?
Assignee: nobody → jones.chris.g
Blocks: 582057
(In reply to comment #1)
> Thanks.
> 
> What page were you on when this happened?  Were you doing something "unusual"
> like tab switching?

Went to http://bugzilla.mozilla.org and clicked in the quick search text box.

That would normally cause Form Assistant to appear, zooming in on the textbox.
Interesting; just repro'd "a" crash, but it was

#5  0x00007f103e1b2a34 in nsTArray_base::Length (this=0x0) at ../../../../dist/include/nsTArray.h:66
#6  0x00007f103f7b8b4d in IPC::ParamTraits<nsTArray<nsHttpHeaderArray::nsEntry> >::Write (aMsg=0x7f10245da7b0, aParam=...) at ../../dist/include/IPC/IPCMessageUtils.h:256
#7  0x00007f103f7b7396 in WriteParam<nsTArray<nsHttpHeaderArray::nsEntry> > (m=0x7f10245da7b0, p=...) at /home/cjones/mozilla/cedar/ipc/chromium/src/chrome/common/ipc_message_utils.h:124
#8  0x00007f103f7b78f4 in IPC::ParamTraits<nsHttpHeaderArray>::Write (aMsg=0x7f10245da7b0, aParam=...) at ../../dist/include/mozilla/net/PHttpChannelParams.h:149
#9  0x00007f103f7b73bb in WriteParam<nsHttpHeaderArray> (m=0x7f10245da7b0, p=...) at /home/cjones/mozilla/cedar/ipc/chromium/src/chrome/common/ipc_message_utils.h:124
#10 0x00007f103f7b7919 in IPC::ParamTraits<nsHttpResponseHead>::Write (aMsg=0x7f10245da7b0, aParam=...) at ../../dist/include/mozilla/net/PHttpChannelParams.h:168
#11 0x00007f103f7b7484 in WriteParam<nsHttpResponseHead> (m=0x7f10245da7b0, p=...) at /home/cjones/mozilla/cedar/ipc/chromium/src/chrome/common/ipc_message_utils.h:124
#12 0x00007f103f7b883f in mozilla::net::PHttpChannelParent::Write<nsHttpResponseHead> (this=0x7f10245f2e70, __v=..., __msg=0x7f10245da7b0) at ../../ipc/ipdl/_ipdlheaders/mozilla/net/PHttpChannelParent.h:245
#13 0x00007f103f7b4d52 in mozilla::net::PHttpChannelParent::SendRedirect1Begin (this=0x7f10245f2e70, newChannel=0x25e9f50, newUri=..., redirectFlags=@0x7fff56fff374, responseHead=...) at PHttpChannelParent.cpp:229
#14 0x00007f103e333153 in mozilla::net::HttpChannelParentListener::AsyncOnChannelRedirect (this=0x7f10245d87a0, oldChannel=0x7f10245d78a0, newChannel=0x7f10245d8d20, redirectFlags=2, callback=0x7f10245d8108) at /home/cjones/mozilla/cedar/netwerk/protocol/http/HttpChannelParentListener.cpp:227
#15 0x00007f103e204f1e in nsAsyncRedirectVerifyHelper::DelegateOnChannelRedirect (this=0x7f10245d8100, sink=0x7f10245d87a8, oldChannel=0x7f10245d78a0, newChannel=0x7f10245d8d20, flags=2) at /home/cjones/mozilla/cedar/netwerk/base/src/nsAsyncRedirectVerifyHelper.cpp:180
#16 0x00007f103e205448 in nsAsyncRedirectVerifyHelper::Run (this=0x7f10245d8100) at /home/cjones/mozilla/cedar/netwerk/base/src/nsAsyncRedirectVerifyHelper.cpp:274
#17 0x00007f103f8fc619 in nsThread::ProcessNextEvent (this=0x1774d30, mayWait=0, result=0x7fff56fff52c) at /home/cjones/mozilla/cedar/xpcom/threads/nsThread.cpp:547
#18 0x00007f103f883534 in NS_ProcessNextEvent_P (thread=0x1774d30, mayWait=0) at nsThreadUtils.cpp:250
#19 0x00007f103f6df1f4 in mozilla::ipc::MessagePump::Run (this=0x1762e40, aDelegate=0x1763040) at /home/cjones/mozilla/cedar/ipc/glue/MessagePump.cpp:110

Looks like a use-after-free issue.  Will see what valgrind has to say.
It's a null-ptr deref "nsTArray_base::Length (this=0x0)", looks unrelated to the layers crash.  Filed bug 591567.
Severity: normal → critical
Keywords: crash
Summary: Crash @ [mozilla::layers::PLayersParent::DeallocShmem] → Crash [@ mozilla::layers::PLayersParent::DeallocShmem]
I get (almost, the frame above nsProfileLock::FatalSignalHandler is just raise (sig=11)) the same stack trace with about 75% reproducibility by just opening a few tabs, loading some page to each tab and then closing one tab.
When working on something else, Matt found STR

 (1) open http://limpet.net/mbrubeck
 (2) open a new tab
 (3) close the new tab
 (4) close mbrubeck tab
 (5) BOOM
The problem here is very bad: the shadow manager code just doesn't handle multiple forwarders correctly.  We're going to have just one layer manager for all of chrome, but we'll have a layer forwarder per <browser>.  It's amazing we've gotten this far with the code that's there.  Luckily the fixes should be relatively simple.

This needs to block b1.
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0b1+
Each "tab" (<browser remote>) has its own PuppetWidget, and each PuppetWidget hierarchy has its own layer manager (which implements ShadowLayerForwarder).  These connect into the chrome process's BasicLayer manager.  There can be any number of <browser remote>s with active layers, but this code previously assumed that there was only one active at any point in time.  IOW, there can be many PLayersParents for one BasicShadowLayerManager.

This patch fixes that wrong assumption by moving the PLayersParent handle (which corresponds to a PuppetWidget's layer manager) out of the chrome-process layer manager and into Shadow*Layer.
Attachment #478085 - Flags: superreview?(roc)
Attachment #478085 - Flags: review?(joe)
Attachment #478085 - Flags: superreview?(roc) → superreview+
Attachment #478085 - Flags: review?(joe) → review+
http://hg.mozilla.org/mozilla-central/rev/868af8c9dbdd
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Crash Signature: [@ mozilla::layers::PLayersParent::DeallocShmem]
You need to log in before you can comment on or make changes to this bug.