Closed Bug 792577 Opened 9 years ago Closed 8 years ago
Crash when two activities have the same href in manifest
With today's otoro-ics build (and yesterday's too) if I do a make install-gaia and then I do Contacts->New Contact->Add Photo, the phone crashes and restarts. If I do 'make production' to install gaia, though, it works correctly. That add photo command initiates an inline activity to start the gallery app. I don't see anything useful in logcat or dmesg before the crash. I don't have a debug build to try it on. Seems 100% reproducible to me.
This is a segfault. From logcat: I/GeckoDump( 847): XXX FIXME : Got a mozContentEvent: activity-choice E/GeckoConsole( 847): Content JS INFO at app://system.gaiamobile.org/js/window_manager.js:728 in createFrame: %%%%% Launching Gallery as remote (OOP) E/GeckoConsole( 847): Content JS INFO at app://system.gaiamobile.org/js/window_manager.js:728 in createFrame: %%%%% Launching Gallery as remote (OOP) E/GeckoConsole( 847): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:366 in anonymous: Window Manager: No screenshot in database. This is expected from a fresh installed app. E/GeckoConsole( 847): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:366 in anonymous: Window Manager: No screenshot in database. This is expected from a fresh installed app. F/libc ( 847): Fatal signal 11 (SIGSEGV) at 0x00000018 (code=1)
Okay, I've narrowed it down. Gallery supports a browser activity with type "photos". And it has a "pick" activity with type ["image/jpeg","image/png"]. It doesn't crash with those two alone. But when I add a third activity type to manifest.webapp, I can make it crash. If I add an 'open' activity that is identical to the 'pick' activity, except for its name, then b2g crashes with a sigsegv when I initiate the pick activity. (The gallery does start to open to handle the pick, and then the crash happens, I think.) If I change the href of the open activity to be different than the href of the pick activity, then the crash does not happen. I'll update the bug title to be more descriptive. We can work around this in gaia by just using different hrefs, but it is a crasher. I don't know if it is blocking or not, but I've nominated it.
blocking-basecamp: --- → ?
Summary: Crash when using inline pick activity after make install-gaia → Crash when two activities have the same href in manifest.webapp
I can duplicate this on a desktop build. The 'make production' think that I mentioned in the initial report no longer seems to make a difference. Did I mention that the steps to reproduce are just "hold your finger down on the homescreen"? Also, disposition doesn't have anything to do with it. Any two activities with the same href cause the crash.
Assignee: nobody → fabrice
blocking-basecamp: ? → +
I can reproduce a crash on desktop with similar STR, but I don't think it's directly activity related. Here's the backtrace: #0 0x00007f58589dc03d in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f58589dbedc in sleep () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007f5853d7afb0 in ah_crap_handler (signum=11) at /home/fabrice/dev/inbound/toolkit/xre/nsSigHandlers.cpp:87 #3 0x00007f5853d80cce in nsProfileLock::FatalSignalHandler (signo=11, info=0x7ffffc655230, context=0x7ffffc655100) at /home/fabrice/dev/builds/obj-b2g-desktop/toolkit/profile/nsProfileLock.cpp:190 #4 <signal handler called> #5 0x00007f585589921c in mozilla::layers::ShadowLayerParent::ActorDestroy (this=0x7f582927e820, why=mozilla::ipc::IProtocolManager<mozilla::ipc::RPCChannel::RPCListener>::Deletion) at /home/fabrice/dev/inbound/gfx/layers/ipc/ShadowLayerParent.cpp:60 #6 0x00007f5855513ea4 in mozilla::layers::PLayerParent::DestroySubtree (this=0x7f582927e820, why=mozilla::ipc::IProtocolManager<mozilla::ipc::RPCChannel::RPCListener>::Deletion) at /home/fabrice/dev/builds/obj-b2g-desktop/ipc/ipdl/PLayerParent.cpp:324 #7 0x00007f5855513c1d in mozilla::layers::PLayerParent::OnMessageReceived (this=0x7f582927e820, __msg=...) at /home/fabrice/dev/builds/obj-b2g-desktop/ipc/ipdl/PLayerParent.cpp:172 #8 0x00007f58554e46e3 in mozilla::dom::PContentParent::OnMessageReceived (this=0x7f58292f1000, __msg=...) at /home/fabrice/dev/builds/obj-b2g-desktop/ipc/ipdl/PContentParent.cpp:1286 #9 0x00007f5855461335 in mozilla::ipc::AsyncChannel::OnDispatchMessage (this=0x7f58292f1010, msg=...) at /home/fabrice/dev/inbound/ipc/glue/AsyncChannel.cpp:473 #10 0x00007f585546db57 in mozilla::ipc::RPCChannel::OnMaybeDequeueOne (this=0x7f58292f1010) at /home/fabrice/dev/inbound/ipc/glue/RPCChannel.cpp:402 #11 0x00007f5855471bdf in DispatchToMethod<mozilla::ipc::RPCChannel, bool (mozilla::ipc::RPCChannel::*)()> (obj=0x7f58292f1010, method= (bool (mozilla::ipc::RPCChannel::*)(mozilla::ipc::RPCChannel * const)) 0x7f585546d8f0 <mozilla::ipc::RPCChannel::OnMaybeDequeueOne()>, arg=...) at /home/fabrice/dev/inbound/ipc/chromium/src/base/tuple.h:383 #12 0x00007f5855471b3a in RunnableMethod<mozilla::ipc::RPCChannel, bool (mozilla::ipc::RPCChannel::*)(), Tuple0>::Run (this=0x7f58292889c0) at /home/fabrice/dev/inbound/ipc/chromium/src/base/task.h:307 #13 0x00007f585546c35d in mozilla::ipc::RPCChannel::RefCountedTask::Run (this=0x7f5829746920) at ../../dist/include/mozilla/ipc/RPCChannel.h:425 #14 0x00007f585546c460 in mozilla::ipc::RPCChannel::DequeueTask::Run (this=0x7f5828158520) at ../../dist/include/mozilla/ipc/RPCChannel.h:448 #15 0x00007f5855785ea5 in MessageLoop::RunTask (this=0x7f58586bd310, task=0x7f5828158520) at /home/fabrice/dev/inbound/ipc/chromium/src/base/message_loop.cc:326 #16 0x00007f5855785f14 in MessageLoop::DeferOrRunPendingTask (this=0x7f58586bd310, pending_task=...) at /home/fabrice/dev/inbound/ipc/chromium/src/base/message_loop.cc:334 #17 0x00007f58557862e9 in MessageLoop::DoWork (this=0x7f58586bd310) at /home/fabrice/dev/inbound/ipc/chromium/src/base/message_loop.cc:434 #18 0x00007f585546a899 in mozilla::ipc::DoWorkRunnable::Run (this=0x7f5849567d90) at /home/fabrice/dev/inbound/ipc/glue/MessagePump.cpp:42 #19 0x00007f5855733fd6 in nsThread::ProcessNextEvent (this=0x7f585867c090, mayWait=false, result=0x7ffffc6563af) at /home/fabrice/dev/inbound/xpcom/threads/nsThread.cpp:612 #20 0x00007f58556c55e6 in NS_ProcessNextEvent_P (thread=0x7f585867c090, mayWait=false) at /home/fabrice/dev/builds/obj-b2g-desktop/xpcom/build/nsThreadUtils.cpp:220 #21 0x00007f585546ab0a in mozilla::ipc::MessagePump::Run (this=0x7f58495698c0, aDelegate=0x7f58586bd310) at /home/fabrice/dev/inbound/ipc/glue/MessagePump.cpp:82 ---Type <return> to continue, or q <return> to quit--- #22 0x00007f5855785a81 in MessageLoop::RunInternal (this=0x7f58586bd310) at /home/fabrice/dev/inbound/ipc/chromium/src/base/message_loop.cc:208 #23 0x00007f5855785a12 in MessageLoop::RunHandler (this=0x7f58586bd310) at /home/fabrice/dev/inbound/ipc/chromium/src/base/message_loop.cc:201 #24 0x00007f58557859eb in MessageLoop::Run (this=0x7f58586bd310) at /home/fabrice/dev/inbound/ipc/chromium/src/base/message_loop.cc:175 #25 0x00007f58552ea2cc in nsBaseAppShell::Run (this=0x7f58412a04e0) at /home/fabrice/dev/inbound/widget/xpwidgets/nsBaseAppShell.cpp:163 #26 0x00007f58550472e2 in nsAppStartup::Run (this=0x7f583f80b380) at /home/fabrice/dev/inbound/toolkit/components/startup/nsAppStartup.cpp:290 #27 0x00007f5853d6e45f in XREMain::XRE_mainRun (this=0x7ffffc656820) at /home/fabrice/dev/inbound/toolkit/xre/nsAppRunner.cpp:3782 #28 0x00007f5853d6e73f in XREMain::XRE_main (this=0x7ffffc656820, argc=4, argv=0x7ffffc658c88, aAppData=0x437c40) at /home/fabrice/dev/inbound/toolkit/xre/nsAppRunner.cpp:3848 #29 0x00007f5853d6e95a in XRE_main (argc=4, argv=0x7ffffc658c88, aAppData=0x437c40, aFlags=0) at /home/fabrice/dev/inbound/toolkit/xre/nsAppRunner.cpp:3923 #30 0x0000000000402a7f in do_main (argc=4, argv=0x7ffffc658c88) at /home/fabrice/dev/inbound/b2g/app/nsBrowserApp.cpp:154 #31 0x0000000000402ced in main (argc=4, argv=0x7ffffc658c88) at /home/fabrice/dev/inbound/b2g/app/nsBrowserApp.cpp:239 Chris, any idea what could go wrong here with the ShadowLayer or how I can help diagnose the issue?
This crash looks like use-after-free of a shadow layer, but it shouldn't have anything to do with activities. Best is to file a separate bug, I think.
Chris, this looks a like bug 789399.
P2. But if this is preventing some internal app to work properly then it might be higher prio. Feel free to renom if so.
Priority: -- → P2
I tested again on device, with a modified gallery app that uses the same href both activities it declares. This is not crashing anymore. Since we fixed a number of issues with system message dispatching (which is used by activities) that bug has probably been fixed there.
Milestoning for C2 (deadline of 12/10), as this meets the criteria of "known P2 bugs found before or during C1".
Target Milestone: --- → B2G C2 (20nov-10dec)
This one seems fixed. Both the device and mobile work for me. As mentioned by Fabrice at comment 9, recently we had a bunch of adjustment in system message mechanism and that's why it's working now.
(In reply to Gene Lian [:gene] from comment #12) > This one seems fixed. Both the device and mobile work for me. As mentioned ^^^^^^desktop, sorry! > by Fabrice at comment 9, recently we had a bunch of adjustment in system > message mechanism and that's why it's working now. Hi djf, may we close this one? Thanks!
Gene, Yes, it fine by me to close it. I'd do it myself, except that I'm not sure whether to mark this one resolved/fixed or resolved/worksforme
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.