[Flame][Browser]Device will reboot in browser.

VERIFIED FIXED in Firefox 40

Status

()

defect
--
major
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: jihao, Assigned: sotaro)

Tracking

({regression})

unspecified
mozilla40
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(blocking-b2g:2.2+, firefox38 wontfix, firefox39 wontfix, firefox40 fixed, b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master verified)

Details

Attachments

(5 attachments)

(Reporter)

Description

4 years ago
[1.Description]:
[Flame][v2.2&3.0][Browser]Device will reboot if we tap show windows button at once in Browser while the website is loading.
Attachment: logcat_flame_2101.txt and Device_Crash.3gp
Occurrence time: 21:01

[2.Testing Steps]: 
1. Open Browser.
2. Tap the URL bar.
3. When the Key-board pops up, tap the  Website a few times under TOP SITES.
4. While the  Website is loading, tap Show Windows button at once.

[3.Expected Result]: 
4. Device should enter show windows page.

[4.Actual Result]: 
4. The device will reboot.

[5.Reproduction build]: 
Flame 2.2 build: (Affected)
Build ID               20150315162500
Gaia Revision          a6b2d3f8478ec250beb49950fecbb8a16465ff6f
Gaia Date              2015-03-15 14:33:22
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/18619f8f6c5c
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150315.195030
Firmware Date          Sun Mar 15 19:50:42 EDT 2015
Bootloader             L1TC000118D0

Flame 3.0 build: (Affected)
Build ID               20150315160203
Gaia Revision          d4177902b04b8fedcb7df9a30ae6e9677e03d2d4
Gaia Date              2015-03-13 15:58:35
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/af68c9c0e903
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150315.192711
Firmware Date          Sun Mar 15 19:27:22 EDT 2015
Bootloader             L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
Free Test
(Reporter)

Comment 1

4 years ago
Posted video Device_Crash.3gp
(Reporter)

Updated

4 years ago
A regression bug?

--- -- - --- -- - --- -- - --- -- - --- -- -
Hi, Paladin,

May I have your help?
Can we have a branch check? (v2.1)

One more request, please attach crash ID here if it is a app/system crash.

Many thanks.
blocking-b2g: --- → 2.2?

Updated

4 years ago
Flags: needinfo?(jihao)
This seems like a bug in the browser api. Kanru can you take a look?

[Child 1606] WARNING: Transparent content with displayports can be expensive.: file ../../../layout/base/nsDisplayList.cpp, line 1713
[Parent 1190] WARNING: INPQ received useless SetConfirmedTargetApzc: file ../../../gfx/layers/apz/src/InputQueue.cpp, line 357
[Child 1752] WARNING: nsWindow::GetNativeData not implemented for this type: file ../../widget/PuppetWidget.cpp, line 961
[Parent 1190] WARNING: NS_ENSURE_TRUE(openerFrameElement) failed: file ../../../dom/browser-element/BrowserElementParent.cpp, line 213
[Parent 1190] WARNING: Error constructing actor PRenderFrameParent: file PBrowserParent.cpp, line 1458
[Parent 1190] ###!!! ASSERTION: IPDL error [PBrowserParent]: "Error deserializing 'PRenderFrameParent'". Killing child side as a result.: 'Error', file ../../../ipc/glue/ProtocolUtils.cpp, line 212

Program received signal SIGTERM, Terminated.
kill () at bionic/libc/arch-arm/bionic/kill.S:45
45	    ldmfd   sp!, {r4-r7, ip, lr}
(gdb) bt
#0  kill () at bionic/libc/arch-arm/bionic/kill.S:45
#1  0xb4346754 in base::KillProcess (process_id=process_id@entry=0, exit_code=exit_code@entry=1, wait=wait@entry=false) at ../../../ipc/chromium/src/base/process_util_posix.cc:70
#2  0xb435a75e in mozilla::ipc::FatalError (aProtocolName=0xb5e7adb1 "PBrowserParent", aMsg=aMsg@entry=0xad683a80 "X\"j\266", aHandle=0, aIsParent=aIsParent@entry=true)
    at ../../../ipc/glue/ProtocolUtils.cpp:215
#3  0xb443dba6 in mozilla::dom::PBrowserParent::FatalError (this=<optimized out>, aMsg=0xad683a80 "X\"j\266") at PBrowserParent.cpp:3376
#4  0xb4452f44 in mozilla::dom::PBrowserParent::OnMessageReceived (this=0xad683a80, __msg=..., __reply=@0xbe8aa67c: 0x0) at PBrowserParent.cpp:3202
#5  0xb44a566a in mozilla::dom::PContentParent::OnMessageReceived (this=0xaf217200, __msg=..., __reply=@0xbe8aa67c: 0x0) at PContentParent.cpp:4918
#6  0xb435ea96 in mozilla::ipc::MessageChannel::DispatchSyncMessage (this=this@entry=0xaf217230, aMsg=...) at ../../../ipc/glue/MessageChannel.cpp:1182
#7  0xb435f47a in mozilla::ipc::MessageChannel::DispatchMessage (this=this@entry=0xaf217230, aMsg=...) at ../../../ipc/glue/MessageChannel.cpp:1139
#8  0xb4363f4c in mozilla::ipc::MessageChannel::OnMaybeDequeueOne (this=0xaf217230) at ../../../ipc/glue/MessageChannel.cpp:1127
#9  0xb4156d48 in DispatchToMethod<FdWatcher, void (FdWatcher::*)()> (method=(void (FdWatcher::*)(FdWatcher * const)) 0xb4363eb9 <mozilla::ipc::MessageChannel::OnMaybeDequeueOne()>, 
    obj=<optimized out>, arg=...) at ../../../ipc/chromium/src/base/tuple.h:383
#10 RunnableMethod<FdWatcher, void (FdWatcher::*)(), Tuple0>::Run (this=<optimized out>) at ../../../ipc/chromium/src/base/task.h:310
#11 0xb435b0de in Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:445
#12 mozilla::ipc::MessageChannel::DequeueTask::Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:462
#13 0xb434b62c in MessageLoop::RunTask (this=0xb6a321c0, task=0xaa16f148) at ../../../ipc/chromium/src/base/message_loop.cc:361
#14 0xb434e762 in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=...) at ../../../ipc/chromium/src/base/message_loop.cc:369
#15 0xb4350538 in DoWork (this=<optimized out>) at ../../../ipc/chromium/src/base/message_loop.cc:456
#16 MessageLoop::DoWork (this=0xb6a321c0) at ../../../ipc/chromium/src/base/message_loop.cc:435
#17 0xb43586f6 in mozilla::ipc::DoWorkRunnable::Run (this=<optimized out>) at ../../../ipc/glue/MessagePump.cpp:233
#18 0xb4192b4c in nsThread::ProcessNextEvent (this=0xb6a533c0, aMayWait=<optimized out>, aResult=0xbe8aa837) at ../../../xpcom/threads/nsThread.cpp:855
#19 0xb41a87c8 in NS_ProcessNextEvent (aThread=0xb6a533c0, aMayWait=aMayWait@entry=false) at /Volumes/mac/moz/ib2g/xpcom/glue/nsThreadUtils.cpp:265
#20 0xb4360ae4 in mozilla::ipc::MessagePump::Run (this=0xb6a07690, aDelegate=0xb6a321c0) at ../../../ipc/glue/MessagePump.cpp:99
#21 0xb434c618 in MessageLoop::RunInternal (this=this@entry=0xb6a321c0) at ../../../ipc/chromium/src/base/message_loop.cc:233
#22 0xb434c632 in RunHandler (this=0xb6a321c0) at ../../../ipc/chromium/src/base/message_loop.cc:226
#23 MessageLoop::Run (this=0xb6a321c0) at ../../../ipc/chromium/src/base/message_loop.cc:200
#24 0xb502b932 in nsBaseAppShell::Run (this=0xb6a48340) at ../../widget/nsBaseAppShell.cpp:164
#25 0xb5472292 in nsAppStartup::Run (this=0xb1e12550) at ../../../../toolkit/components/startup/nsAppStartup.cpp:281
#26 0xb54a2568 in XREMain::XRE_mainRun (this=this@entry=0xbe8aa9c0) at ../../../toolkit/xre/nsAppRunner.cpp:4202
#27 0xb54a273c in XREMain::XRE_main (this=this@entry=0xbe8aa9c0, argc=argc@entry=1, argv=argv@entry=0xb6a27288, aAppData=aAppData@entry=0xb6fa6858 <_ZL8sAppData>)
    at ../../../toolkit/xre/nsAppRunner.cpp:4278
#28 0xb54a28b6 in XRE_main (argc=1, argv=0xb6a27288, aAppData=0xb6fa6858 <_ZL8sAppData>, aFlags=<optimized out>) at ../../../toolkit/xre/nsAppRunner.cpp:4498
#29 0xb6f8b12e in do_main (argc=argc@entry=1, argv=argv@entry=0xb6a27288) at ../../../b2g/app/nsBrowserApp.cpp:167
#30 0xb6f8b26a in b2g_main (argc=argc@entry=1, argv=argv@entry=0xbe8abc94) at ../../../b2g/app/nsBrowserApp.cpp:299
Flags: needinfo?(kchen)
Component: Gaia::Browser → DOM: Content Processes
Product: Firefox OS → Core
(Reporter)

Comment 4

4 years ago
Hi William,
We can't reproduce this issue on Flame 2.1
Reproducing Rate: 0/10

The device does not crash. If it is a crash happening in app/system, I will update it.

Flame 2.1 build: (Unaffected)
Build ID               20150316161200
Gaia Revision          e53469fe3a5e563a9146d0fb028e544a423b7e96
Gaia Date              2015-03-16 15:30:43
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/32d1cae787e0
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150316.192737
Firmware Date          Mon Mar 16 19:27:48 EDT 2015
Bootloader             L1TC000118D0
Flags: needinfo?(jihao) → needinfo?(whsu)
(In reply to Paladin from comment #4)
> Hi William,
> We can't reproduce this issue on Flame 2.1
> Reproducing Rate: 0/10
> 
> The device does not crash. If it is a crash happening in app/system, I will
> update it.
> 
> Flame 2.1 build: (Unaffected)
> Build ID               20150316161200
> Gaia Revision          e53469fe3a5e563a9146d0fb028e544a423b7e96
> Gaia Date              2015-03-16 15:30:43
> Gecko Revision        
> https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/32d1cae787e0
> Gecko Version          34.0
> Device Name            flame
> Firmware(Release)      4.4.2
> Firmware(Incremental)  eng.cltbld.20150316.192737
> Firmware Date          Mon Mar 16 19:27:48 EDT 2015
> Bootloader             L1TC000118D0

Thanks for your help.
A regression bug. Nominate it.
Flags: needinfo?(whsu)
Keywords: regression
I found it almost impossible to tap the "show windows" buttons while the page is loading. It immediately switches to "..."

Is there easier STR? Or I'm doing it wrong?
Flags: needinfo?(kchen)
I could reproduce this on latest m-c so it looks like a recent regression. Regression window wanted.
blocking-b2g: 2.2? → 2.2+
QA Contact: ychung
I was unable to get the regression window as the repro rate reduces significantly. While the recent builds reproduce the issue easily, I reproduced once after attempting more than 10 times on an earlier build. This is the earliest build I could reproduce:

Environmental Variables:
Device: Flame 2.2
BuildID: 20141120231111
Gaia: d695e7cdcd162e779e15594054931c84dec34a95
Gecko: 7b56755a63ba
Version: 36.0a1 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Contact: ychung
(In reply to Kan-Ru Chen [:kanru] from comment #7)
> I could reproduce this on latest m-c so it looks like a recent regression.
> Regression window wanted.

You might want to try with a debug gecko. I had no issues reproducing it.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
OK, so this is reproducible from a quite old build. It just become easier to trigger recently.

Comment 11

4 years ago
Hi Kan-Ru, do you mind taking this bug? thank.
Flags: needinfo?(kchen)
Assignee: nobody → kchen
Flags: needinfo?(kchen)
Looks like a regression from bug 108565, Sotaro, could you take a look?

http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp?rev=ca6d6b665bc1&mark=1530-1539#1530

1530   TextureFactoryIdentifier textureFactoryIdentifier;
1531   uint64_t layersId = 0;
1532   PRenderFrameChild* renderFrame = newChild->SendPRenderFrameConstructor();
1533   newChild->SendGetRenderFrameInfo(renderFrame,
1534                                    &textureFactoryIdentifier,
1535                                    &layersId);
1536   if (layersId == 0) { // if renderFrame is invalid.
1537     PRenderFrameChild::Send__delete__(renderFrame);
1538     renderFrame = nullptr;
1539   }

We stop at line 1533 because if renderFrame is invalid it couldn't be deserialized by B2G process. The IPC layer will kill itself because of the malformed message. How could the renderFrame be invalid? See below:

http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.cpp?rev=ca6d6b665bc1&mark=2299-2319#2299

2299 PRenderFrameParent*
2300 TabParent::AllocPRenderFrameParent()
2301 {
2302   MOZ_ASSERT(ManagedPRenderFrameParent().IsEmpty());
2303   nsRefPtr<nsFrameLoader> frameLoader = GetFrameLoader();
2304   TextureFactoryIdentifier textureFactoryIdentifier;
2305   uint64_t layersId = 0;
2306   bool success = false;
2307   if(frameLoader) {
2308     PRenderFrameParent* renderFrame = 
2309       new RenderFrameParent(frameLoader,
2310                             &textureFactoryIdentifier,
2311                             &layersId,
2312                             &success);
2313     MOZ_ASSERT(success);
2314     AddTabParentToTable(layersId, this);
2315     return renderFrame;
2316   } else {
2317     return nullptr;
2318   }
2319 }

I'm not sure what's happening here yet, but in this bug the GetFrameLoader returns nullptr. Maybe we are trying to initialize PRenderFrame before the iframe is attached to the document?
Flags: needinfo?(sotaro.ikeda.g)
(Assignee)

Comment 13

4 years ago
Okey, I take a look.
Flags: needinfo?(sotaro.ikeda.g) → needinfo?(sotaro.ikeda.g)
(Assignee)

Comment 14

4 years ago
> 
> I'm not sure what's happening here yet, but in this bug the GetFrameLoader
> returns nullptr. Maybe we are trying to initialize PRenderFrame before the
> iframe is attached to the document?

TabParent::mFrameElement was nullptr when the problem happened.

In this use case, it should be set by SetOwnerElement() in BrowserElementParent::OpenWindowOOP()
  https://dxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementParent.cpp#239

But the OpenWindowOOP() was failed at the following.

>  NS_ENSURE_TRUE(openerFrameElement,
>                 BrowserElementParent::OPEN_WINDOW_IGNORED);
  https://dxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementParent.cpp#212

The OpenWindowOOP() returns BrowserElementParent::OPEN_WINDOW_IGNORED. But TabParent::RecvBrowserFrameOpenWindow() handle it as success. Then the following check in TabChild::ProvideWindowCommon() did not work.

>  if (!*aWindowIsNew) {
>    PBrowserChild::Send__delete__(newChild);
>    return NS_ERROR_ABORT;
>  }

https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp#1525

Then "newChild->SendPRenderFrameConstructor();" is called incorrectly.
Flags: needinfo?(sotaro.ikeda.g)
(Assignee)

Comment 15

4 years ago
The patch fixed the problem for me.
(Assignee)

Comment 16

4 years ago
This bug seems regression of Bug 826325.
(Assignee)

Updated

4 years ago
See Also: → 826325
(In reply to Sotaro Ikeda [:sotaro] from comment #14)
> > 
> > I'm not sure what's happening here yet, but in this bug the GetFrameLoader
> > returns nullptr. Maybe we are trying to initialize PRenderFrame before the
> > iframe is attached to the document?
> 
> TabParent::mFrameElement was nullptr when the problem happened.

This is weird.

> In this use case, it should be set by SetOwnerElement() in
> BrowserElementParent::OpenWindowOOP()
>  
> https://dxr.mozilla.org/mozilla-central/source/dom/browser-element/
> BrowserElementParent.cpp#239
> 
> But the OpenWindowOOP() was failed at the following.
> 
> >  NS_ENSURE_TRUE(openerFrameElement,
> >                 BrowserElementParent::OPEN_WINDOW_IGNORED);
>  
> https://dxr.mozilla.org/mozilla-central/source/dom/browser-element/
> BrowserElementParent.cpp#212

Again, this shouldn't happen.

> *aOutWindowOpened = (opened != BrowserElementParent::OPEN_WINDOW_CANCELLED);

I believe this code is doing what's intended.

Thanks, Sotaro. I'm not sure how the STR triggers the nullptr mFrameElement, I'll look into it.
(Assignee)

Comment 18

4 years ago
Posted patch log patchSplinter Review
The patch add some logs around the crash.
(Assignee)

Comment 19

4 years ago
I used attachment 8581596 [details] [diff] [review] to check the sequence until the crash.
(Assignee)

Comment 20

4 years ago
logcat log of the crash by applying attachment 8581596 [details] [diff] [review].
FC for v2.2 is coming. Are we going to postpone this bug?
Comment on attachment 8581186 [details] [diff] [review]
patch - Fix OutWindowOpened flag

Review of attachment 8581186 [details] [diff] [review]:
-----------------------------------------------------------------

So after read the patch in bug 826325 again, I think you are correct, Sotaro.
We should return the same value as in https://dxr.mozilla.org/mozilla-central/source/xpfe/appshell/nsContentTreeOwner.cpp#867
Attachment #8581186 - Flags: review+
(Assignee)

Comment 23

4 years ago
Thanks. As a short time fix, attachment 8581186 [details] [diff] [review] is good, I think.
https://hg.mozilla.org/mozilla-central/rev/d5b2cb89687b
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Carsten, since this bug is a 2.2 blocker, could you please uplift it? Thanks.
Flags: needinfo?(sotaro.ikeda.g)
(Assignee)

Comment 27

4 years ago
Comment on attachment 8581186 [details] [diff] [review]
patch - Fix OutWindowOpened flag

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 826325
User impact if declined: device could reboot when using browser app
Testing completed: locally tested.
Risk to taking this patch (and alternatives if risky): low
String or UUID changes made by this patch:none.
Flags: needinfo?(sotaro.ikeda.g)
Attachment #8581186 - Flags: approval-mozilla-b2g37?
(Assignee)

Updated

4 years ago
Assignee: kchen → sotaro.ikeda.g
Attachment #8581186 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
(Reporter)

Comment 29

4 years ago
This issue had been successfully verified on Flame 2.2&3.0
Reproducing rate: 0/5
Flame 2.2 [Verified]
Build ID               20150406002503
Gaia Revision          a6351e1197d54f8624523c2db9ba1418f2aa046f
Gaia Date              2015-04-03 22:06:41
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/c3335a5d3063
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150406.040047
Firmware Date          Mon Apr  6 04:00:58 EDT 2015
Bootloader             L1TC000118D0

Flame 3.0[Verified]
Build ID               20150406160205
Gaia Revision          834385f4c834238a4306bf87cc4be41615d91ff0
Gaia Date              2015-04-06 19:41:47
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/a530b5c3b713
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150406.194015
Firmware Date          Mon Apr  6 19:40:27 EDT 2015
Bootloader             L1TC000118D0
Leaving verify me for status-firefox40, there is no this device.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
(In reply to Alissa from comment #30)
> Leaving verify me for status-firefox40, there is no this device.

That is not necessary. As long as b2g branches are verified this is considered verified.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.