This bug was filed from the Socorro interface and is report bp-5b374516-277f-4649-a459-b5eb92130204 . ============================================================= Crashing Thread Frame Module Signature Source 0 @0xffdfffde 1 libxul.so mozilla::layout::RenderFrameParent::ContentReceivedTouch RenderFrameParent.cpp:979 2 libxul.so mozilla::dom::TabParent::RecvContentReceivedTouch TabParent.cpp:1304 3 libxul.so mozilla::dom::PBrowserParent::OnMessageReceived PBrowserParent.cpp:1477 4 libxul.so mozilla::dom::PContentParent::OnMessageReceived PContentParent.cpp:1394 5 libxul.so mozilla::ipc::AsyncChannel::OnDispatchMessage AsyncChannel.cpp:473 6 libxul.so mozilla::ipc::RPCChannel::OnMaybeDequeueOne RPCChannel.cpp:402 7 libxul.so RunnableMethod<IPC::ChannelProxy::Context, void , Tuple0>::Run tuple.h:383 8 libxul.so mozilla::ipc::RPCChannel::DequeueTask::Run RPCChannel.h:425 9 libxul.so MessageLoop::RunTask message_loop.cc:333 10 libxul.so MessageLoop::DeferOrRunPendingTask message_loop.cc:341 11 libxul.so MessageLoop::DoWork message_loop.cc:441 12 libxul.so mozilla::ipc::DoWorkRunnable::Run MessagePump.cpp:42 13 libxul.so nsThread::ProcessNextEvent nsThread.cpp:620 14 libxul.so NS_ProcessNextEvent_P nsThreadUtils.cpp:237 15 libxul.so mozilla::ipc::MessagePump::Run MessagePump.cpp:117 16 libxul.so MessageLoop::RunInternal message_loop.cc:215 17 libxul.so MessageLoop::Run message_loop.cc:208 18 libxul.so nsBaseAppShell::Run nsBaseAppShell.cpp:163 19 libxul.so nsAppStartup::Run nsAppStartup.cpp:290 20 libxul.so XREMain::XRE_mainRun nsAppRunner.cpp:3794 21 libxul.so XREMain::XRE_main nsAppRunner.cpp:3860 22 libxul.so XRE_main nsAppRunner.cpp:3935 23 b2g main nsBrowserApp.cpp:164 24 libc.so __libc_init libc_init_dynamic.c:114 25 libc.so __cxa_atexit atexit.c:99 26 @0xbefeed24 Crash on Otoro for touch events... Not sure how to repro ATM. Build ID 20130203070202

Here's an unreduced orangutan script testcase that results in this crash.

I haven't tried to reproduce this crash with the testcase yet.

I crashed on the following build: 20130311095652: https://crash-stats.mozilla.com/report/index/1b26b023-bbc0-4976-b6d8-eab2b2130314

We'll track since this is reproducible and we should get an engineer to investigate further so we can get a sense of how likely users are to hit it. Assigning to David for delegation.

I let the script run over lunch (~1h30) and it didn't crash for me. I'm using 20130310230202. Also, this is a Gecko crash so not my area of expertise.

Gabriele: Could you take a look?

(In reply to Anthony Ricaud (:rik) from comment #6) > Gabriele: Could you take a look? Sure, will have a look at it ASAP.

Some tips to help reproduce (as I recall from its initial run): 1. First reset your phone. Make sure one is on the beta channel without any test apps (e.g. Test Receiver etc.) 2. Boot up the phone without a SIM card, make sure it has no contacts, no extra apps on screen. 3. Only have wifi connected.

I tried running the script provided in attachment 724739 [details], following the instructions from comment 8 using a v1-train userdebug build on my Unagi. The script went past the ~30 minutes mark without crashing. I'll try running the whole procedure again a couple more times to see if I can reproduce the issue; I'd be grateful if someone could add even more information on how to reproduce it reliably (and possibly in a shorter timespan).

I've

I've managed to reproduce a crash with the script and capture the event in GDB but the top stack frames look different than what we have here: #0 0x4141a0e0 in mozilla::layers::GestureEventListener::HandleInputEvent ( this=0x4863ba60, aEvent=...) at /home/gsvelto/projects/mozilla-b2g18/gfx/layers/ipc/GestureEventListener.cpp:159 #1 0x414151f6 in mozilla::layers::AsyncPanZoomController::HandleInputEvent ( this=0x48f6d400, aEvent=...) at /home/gsvelto/projects/mozilla-b2g18/gfx/layers/ipc/AsyncPanZoomController.cpp:251 #2 0x414153bc in mozilla::layers::AsyncPanZoomController::ReceiveInputEvent ( this=0x48f6d400, aEvent=...) at /home/gsvelto/projects/mozilla-b2g18/gfx/layers/ipc/AsyncPanZoomController.cpp:244 #3 0x414154c4 in mozilla::layers::AsyncPanZoomController::ReceiveMainThreadInputEvent (this=0x48f6d400, aEvent=...) at /home/gsvelto/projects/mozilla-b2g18/gfx/layers/ipc/AsyncPanZoomController.cpp:161 #4 0x40d2b5de in mozilla::layout::RenderFrameParent::NotifyInputEvent ( this=<value optimized out>, aEvent=...) at /home/gsvelto/projects/mozilla-b2g18/layout/ipc/RenderFrameParent.cpp:782 I'll do some further investigation on this tomorrow.

(In reply to Gabriele Svelto [:gsvelto] from comment #9) > I tried running the script provided in attachment 724739 [details], > following the instructions from comment 8 using a v1-train userdebug build > on my Unagi. The script went past the ~30 minutes mark without crashing. > I'll try running the whole procedure again a couple more times to see if I > can reproduce the issue; I'd be grateful if someone could add even more > information on how to reproduce it reliably (and possibly in a shorter > timespan). Gabriele, thanks for being able to reproduce it! orangfuzz (the fuzzer that produced this test output, see bug 857276) and the running harness is still in its infant stages - we're definitely thinking of making testcases more reliable and reducing to smaller steps. I'm glad this is now reproducible!

I've attached the backtrace I got with gdb of the segmentation fault I've got while running the script. I have not yet fully understood what's going on; the crash is caused by the |mLongTapTimeoutTask| field pointing to what looks like a corrupt (or already freed?) object. This makes the |mLongTapTimeoutTask->Cancel()| call to cause the segfault. More importantly I'm not sure if this issue is the same as the one seen in this bug though they both seem related to handling touch events and one might be causing the other. I'll try to reproduce yet again today and see what I get.

I did another run today with an updated build and the script run without problems for over two hours. Unfortunately this seems really hard to reproduce :-(

Sounds like what we are really looking for here is a more consistent STR. Flipping keywords as such to reflect this.

The initial stack and comment 13 are exploitable conditions. Giving a lower "moderate" rating on the belief (hope) attackers can't create the sequence of user touches required to get into this state.

I was unable to make further progress on this so I'm unassigning the bug.

Gary - Can you take another shot at reproducing this? We might have to close if we don't have a way to make this actionable.

I don't have any progress on this yet. Please feel free to close - I'll be sure to open a new bug when I have something more concrete.

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #19) > I don't have any progress on this yet. Please feel free to close - I'll be > sure to open a new bug when I have something more concrete. Sounds good.

I'd say WFM - running the testcase no longer seems to throw that crash. At least not till a better testcase comes around.

It's still happen. See https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Alayout%3A%3ARenderFrameParent%3A%3AContentReceivedTouch

It looks like it's happening on 1.0.1 and not 1.1? We need to be able to query this better.

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #23) > It looks like it's happening on 1.0.1 and not 1.1? We need to be able to > query this better. We don't know whether it still happens on 1.1 because there are no enough users of that version on devices. Upgrading Geekphone users (considered as Beta testers) to that version would help.

This seems to appear on 1.0.1 only for now, from what I see (but we have very little data on 1.1) - has bug 833964 fixed this one as well?

Kats, you fixed bug 833964, does this look like it's just a dupe or a different issue?

From the stack in comment 0 it does look like it could be a dupe. I'm not sure about the crash that :gsvelto reproduced in comment 13, that looks different.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #27) > I'm not sure about the crash that :gsvelto reproduced in comment 13, that looks > different. There have been no crashes for the last four weeks with the mozilla::layers::GestureEventListener::HandleInputEvent signature.

Is this bug still relevant? There are a few recently reported crashes but they are all on 1.0.1.0-prerelease afaict. Wontfix/worksforme?

Crashes look like they are all on 18 only. Closing as WFM.