The default bug view has changed. See this FAQ.

crash in mozilla::layout::RenderFrameParent::ContentReceivedTouch

RESOLVED WORKSFORME

Status

()

Core
Layout
--
critical
RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: nhirata, Unassigned)

Tracking

(Blocks: 2 bugs, 4 keywords)

Trunk
ARM
Gonk (Firefox OS)
b2g-testdriver, crash, sec-moderate, unagi
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(b2g18+ affected, b2g18-v1.0.0 wontfix, b2g-v1.3 unaffected, b2g-v1.3T unaffected, b2g-v1.4 unaffected, b2g-v2.0 unaffected, b2g-v2.1 unaffected)

Details

(Whiteboard: [b2g-crash], crash signature)

Attachments

(2 attachments)

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

Updated

4 years ago
Whiteboard: [b2g-crash]

Updated

4 years ago
Crash Signature: [@ mozilla::layout::RenderFrameParent::ContentReceivedTouch] → [@ mozilla::layout::RenderFrameParent::ContentReceivedTouch] [@ @0x0 | mozilla::layout::RenderFrameParent::ContentReceivedTouch ]
Created attachment 724739 [details]
unreduced orangutan script that crashes at this location after ~20+ minutes

Here's an unreduced orangutan script testcase that results in this crash.
I haven't tried to reproduce this crash with the testcase yet.
Blocks: 832328
I crashed on the following build: 20130311095652:

https://crash-stats.mozilla.com/report/index/1b26b023-bbc0-4976-b6d8-eab2b2130314
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
tracking-b2g18: --- → ?
Keywords: b2g-testdriver, qawanted, regressionwindow-wanted, testcase, unagi
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.
Assignee: nobody → david.scravaglieri
tracking-b2g18: ? → +
Keywords: reproducible
Assignee: david.scravaglieri → anthony
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.
Assignee: anthony → dscravaglieri
Gabriele: Could you take a look?
Assignee: dscravaglieri → gsvelto

Updated

4 years ago
Component: Gaia::System → Layout
Product: Boot2Gecko → Core
Version: unspecified → Trunk
(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.
Blocks: 857276
No longer blocks: 832328
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!
Created attachment 733239 [details]
Backtrace for the segfault seen in comment #11

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.
Keywords: qawanted, regressionwindow-wanted, testcase → steps-wanted
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.
Keywords: sec-moderate
Blocks: 862082
I was unable to make further progress on this so I'm unassigning the bug.
Assignee: gsvelto → nobody
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.
Flags: needinfo?(gary)
Whiteboard: [b2g-crash] → [b2g-crash][closeme 5/17/2013]
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.
Flags: needinfo?(gary)
(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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Keywords: steps-wanted
Resolution: --- → INCOMPLETE

Updated

4 years ago
Whiteboard: [b2g-crash][closeme 5/17/2013] → [b2g-crash]
I'd say WFM - running the testcase no longer seems to throw that crash. At least not till a better testcase comes around.
Resolution: INCOMPLETE → WORKSFORME

Comment 22

4 years ago
It's still happen. See https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Alayout%3A%3ARenderFrameParent%3A%3AContentReceivedTouch
Status: RESOLVED → REOPENED
Keywords: reproducible
Resolution: WORKSFORME → ---
It looks like it's happening on 1.0.1 and not 1.1?  We need to be able to query this better.

Comment 24

4 years ago
(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.

Comment 25

4 years ago
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?

Comment 26

4 years ago
Kats, you fixed bug 833964, does this look like it's just a dupe or a different issue?
Flags: needinfo?(bugmail.mozilla)
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.
Flags: needinfo?(bugmail.mozilla)

Comment 28

4 years ago
(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.
Depends on: 833964
See Also: → bug 849884
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?
Flags: needinfo?(jsmith)

Updated

3 years ago
Flags: needinfo?(jsmith) → needinfo?(nhirata.bugzilla)
Crashes look like they are all on 18 only.  Closing as WFM.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago3 years ago
status-b2g-v1.3: --- → unaffected
status-b2g-v1.3T: --- → unaffected
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → unaffected
status-b2g-v2.1: --- → unaffected
Flags: needinfo?(nhirata.bugzilla)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.