Closed Bug 1130035 Opened 10 years ago Closed 6 years ago

[System] Device displays a white screen and becomes unresponsive while trying to load a webpage.

Categories

(Core :: Hardware Abstraction Layer (HAL), defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
blocking-b2g -
tracking-b2g backlog
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected
b2g-master --- affected

People

(Reporter: ychung, Unassigned)

References

()

Details

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

Attachments

(2 files)

Description: The same issue as bug 1122119 occurrs with 100% repro rate when going to a specific webpage. This webpage contains a heavy load of pictures, and the white screen occurs while the page is loading. Repro Steps: 1) Update a Flame to 20150205010209. 2) Connect to a Wi-Fi network or turn on the data connection. 3) Go to http://goo.gl/sQPu8j on the browser. Actual: A white screen appears, and the device becomes unresponsive. When connected to a computer, it tries to open device folders indefinitely. Expected: The page loads properly. Environmental Variables: Device: Flame 3.0 Build ID: 20150205010209 Gaia: 2b83a6d5d1185a438b5bbd287497ac2743b501db Gecko: 34a66aaaca81 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Device: Flame 2.2 (319mb, full flash) Build ID: 20150205002503 Gaia: c2047a46e29696238e9b4c9caaba47736421449a Gecko: adfba0a07e9b Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Repro frequency: 5/5 See attached: logcat, video clip http://youtu.be/uWfr4IC9RbY
This issue does NOT reproduce on Flame 2.1. Result: While trying to load the page, the browser app crashes, but the white screen does not appears. Device: Flame 2.1 (319mb, full flash) Build ID: 20150205001711 Gaia: 17bf14f12e43043654498330d610d469b8b55e64 Gecko: bdebcc47ec7a Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Attached file logcat_whitescreen
Depends on: 1025265
Nominating 2.2? the user should not encounter a white screen. Let's get a regression window.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+]
QA Contact: pcheng
(In reply to Yeojin Chung [:YeojinC] from comment #0) > Environmental Variables: > Device: Flame 3.0 > Build ID: 20150205010209 > Gaia: 2b83a6d5d1185a438b5bbd287497ac2743b501db > Gecko: 34a66aaaca81 > Gonk: e7c90613521145db090dd24147afd5ceb5703190 > Version: 38.0a1 (3.0) > Firmware Version: v18D-1 > User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 I've just tested this configuration but I can't seem to reproduce the problem on my Flame.
I have verified this bug on latest Flame 2.1/2.2 and oldest Flame 2.1/2.2 we can find, but the bug still exist in these versions. Steps: 1. Connect to a Wi-Fi network or turn on the data connection. 2. Go to http://goo.gl/sQPu8j on the browser. Actual: A white screen appears, and the device becomes unresponsive. When connected to a computer, it tries to open device folders indefinitely. Expected: The page loads properly. Fail rate:5/5 Flame 2.2: Build ID 20140923160207 Gaia Revision ff6dbb006e4e60edba697639aa2a2a199b07069b Gaia Date 2014-09-23 18:22:24 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/30920bcb070a Gecko Version 35.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20140923.192209 Firmware Date Tue Sep 23 19:22:19 EDT 2014 Bootloader L1TC000118D0 Build ID 20150205002503 Gaia Revision c2047a46e29696238e9b4c9caaba47736421449a Gaia Date 2015-02-04 20:34:04 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/adfba0a07e9b Gecko Version 37.0a2 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150205.045043 Firmware Date Thu Feb 5 04:50:54 EST 2015 Bootloader L1TC000118D0 Flame 2.1: Build ID 20141008161201 Gaia Revision 7ef2e1e59637a34ca4489c329b3bdee93df3ac6c Gaia Date 2014-10-08 12:32:21 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/e3d495eb85c6 Gecko Version 34.0a2 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20141008.195811 Firmware Date Wed Oct 8 19:58:25 EDT 2014 Bootloader L1TC000118D0 Build ID 20150205001711 Gaia Revision 17bf14f12e43043654498330d610d469b8b55e64 Gaia Date 2015-02-03 05:19:41 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/bdebcc47ec7a Gecko Version 34.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150205.035050 Firmware Date Thu Feb 5 03:51:01 EST 2015 Bootloader L1TC000118D0
QA Whiteboard: [MGSEI-Triage+]
Repro rate for this bug is not 100%, especially on 2.1 and 2.0. On these two branches it could take up to 11 attempts before the issue occurs, but I've seen it happened on first try after flashing as well. This issue reproduces on 2.1, 2.0, base image v18D-1 only, and base image v188-1 only. Removing regression keyword.
QA Whiteboard: [MGSEI-Triage+] → [MGSEI-Triage+][QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: needinfo?(ktucker)
Keywords: regression
wesly looks like this could be related to base image as it reproduces with 18D-1, could you have a look at this?
Flags: needinfo?(wehuang)
triage: per comment 5, removing the regression keyword. the experience is too bad so let's block on it. if it's base image problem, please change component to vendcom.
blocking-b2g: 2.2? → 2.2+
Keywords: regression
Hi Youlong: per comment#6 this can be repro. in v18D base image, would you help investigate first? Thanks!
Flags: needinfo?(wehuang) → needinfo?(youlong.jiang)
(In reply to Wesly Huang from comment #9) > Hi Youlong: > > per comment#6 this can be repro. in v18D base image, would you help > investigate first? Thanks! hi wesly - we'll try to reproduce this issue on our side and feedback. tks.
Flags: needinfo?(youlong.jiang)
wesly, can you please help follow-up on this?
Flags: needinfo?(wehuang)
Yes this is(In reply to bhavana bajaj [:bajaj] from comment #11) > wesly, can you please help follow-up on this? Yes I still have weekly issue review meeting with T2M that covering this one, the thing is their responsible engineer take some vacation before and after Chinese New Year (a big holiday in China) so we expect a delayed feedback. @Youlong: as discussed last time please still try to arrange substitute team member to look into this soon, then keep us updated, thank you!
Flags: needinfo?(wehuang)
Flags: needinfo?(youlong.jiang)
test many times(20+) on both v18D-1 and v188-1. but still can't reproduce now.
Hi Yeojin, can you verify Comment 13?
Flags: needinfo?(ychung)
(In reply to howie [:howie] from comment #14) > Hi Yeojin, can you verify Comment 13? I was able to reproduce this issue on the first try on today's nightly Flame Master. Here's my environmental variables: Device: Flame Master (KK, 319mb, full flash) Build ID: 20150305010212 Gaia: eff3321ab4e65da3f906688ebb55ddf1e93d9452 Gecko: 56492f7244a9 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
Flags: needinfo?(ychung)
(In reply to Yeojin Chung [:YeojinC] from comment #15) > (In reply to howie [:howie] from comment #14) > > Hi Yeojin, can you verify Comment 13? > > I was able to reproduce this issue on the first try on today's nightly Flame > Master. Here's my environmental variables: > > Device: Flame Master (KK, 319mb, full flash) > Build ID: 20150305010212 > Gaia: eff3321ab4e65da3f906688ebb55ddf1e93d9452 > Gecko: 56492f7244a9 > Gonk: e7c90613521145db090dd24147afd5ceb5703190 > Version: 39.0a1 (3.0) > Firmware Version: v18D-1 > User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0 NI :wesly to make sure T2M is using the exact build listed here and then trying this issue.
Flags: needinfo?(whuang)
FW NI to Wesly
Flags: needinfo?(whuang) → needinfo?(wehuang)
> > I was able to reproduce this issue on the first try on today's nightly Flame > > Master. Here's my environmental variables: > > > > Device: Flame Master (KK, 319mb, full flash) > > Build ID: 20150305010212 > > Gaia: eff3321ab4e65da3f906688ebb55ddf1e93d9452 > > Gecko: 56492f7244a9 > > Gonk: e7c90613521145db090dd24147afd5ceb5703190 > > Version: 39.0a1 (3.0) > > Firmware Version: v18D-1 > > User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0 > > NI :wesly to make sure T2M is using the exact build listed here and then > trying this issue. Bhavana: this is not the build T2M have and made, so will be good if we can repro. & get log with base image to eliminate other factors introduced by 2.1/2.2/3.0 Gaia/Gecko. @Youlong: As discussed in phone please still try to take a look at the log provided, and let us know any finding you see and reply here, thank you. @Pi Wei: I saw you've repro. the issue in T2M's based image per comment#6, would you help me understand the repro. rate you see? Also share a log based on it so let T2M to check further.
Flags: needinfo?(wehuang) → needinfo?(pcheng)
Whiteboard: [POVB], [b2g-crash]
Adding qawanted to get a logcat and repro rate on v18D base.
QA Whiteboard: [MGSEI-Triage+][QAnalyst-Triage?] → [MGSEI-Triage+]
Flags: needinfo?(pcheng)
Keywords: qawanted
QA Contact: pcheng
QA Contact: ychung
This issue does reproduce on v18D base image only. The white screen appeared when the browser tried to load the website.
QA Whiteboard: [MGSEI-Triage+] → [QAnalyst-Triage?][MGSEI-Triage+]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Contact: ychung
QA Whiteboard: [QAnalyst-Triage?][MGSEI-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Flags: needinfo?(ktucker)
I verify with base image v18D only for 10 times but always cannot reproduce it even I adjust memory to 319MB If any log or video can be referenced here?
Flags: needinfo?(pcheng)
Yeojin, can you provide a logcat and video for this issue reproducing on the base image only?
Flags: needinfo?(ychung)
QA Whiteboard: [QAnalyst-Triage+][MGSEI-Triage+] → [QAnalyst-Triage-][MGSEI-Triage+]
Keywords: qawanted
I cannot reproduce the white screen issue anymore on v18D base image any more. Instead of the white screen, the error message shows up on the browser: "Well, this is embarrassing.We tried to display this Web page, but it's not responding." Then sometimes the device becomes unresponsive. When the user presses the home button, nothing happens. The device has to be restarted to get out of the unresponsive state.
QA Whiteboard: [QAnalyst-Triage-][MGSEI-Triage+] → [QAnalyst-Triage?][MGSEI-Triage+]
Flags: needinfo?(ychung)
Flags: needinfo?(pcheng)
Flags: needinfo?(ktucker)
Keywords: qawanted
Yeojin, can you please try again today?
QA Whiteboard: [QAnalyst-Triage?][MGSEI-Triage+] → [MGSEI-Triage+]
Flags: needinfo?(ktucker) → needinfo?(ychung)
Keywords: qawanted
I was able to reproduce this bug on v18D base only, but the repro rate is below 10%. Before I reproduced it, I tried to load the page about 12 times. I was unable to get the video, but here's the logcat.
Flags: needinfo?(ychung) → needinfo?(ktucker)
QA Whiteboard: [MGSEI-Triage+] → [MGSEI-Triage?]
Keywords: qawanted
QA Whiteboard: [MGSEI-Triage?] → [QAnalyst-Triage?][MGSEI-Triage+]
Flags: needinfo?(ktucker)
I'm a little confused what is the problem now. White screen? Or Browser show error message: "Well, this is embarrassing.We tried to display this Web page, but it's not responding."? If current problem is the later one, I think we should file another bug and close this one since it's indeed cannot reproduce the "white screen" issue.
Peter, According to comment 25, could you please have someone to check the log?
Flags: needinfo?(pchang)
Flags: needinfo?(ktucker)
(In reply to Mike Lien[:mlien] from comment #26) > I'm a little confused what is the problem now. White screen? Or Browser show > error message: "Well, this is embarrassing.We tried to display this Web > page, but it's not responding."? > > If current problem is the later one, I think we should file another bug and > close this one since it's indeed cannot reproduce the "white screen" issue. I DID reproduce the white screen issue, although with a very low repro rate. So I'm not sure if we can close this issue. If you'd like, I can open up a new bug addressing the other issue, but I guessed the cause of those two symptoms is the same. Please let me know. :)
QA Whiteboard: [QAnalyst-Triage?][MGSEI-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Flags: needinfo?(ktucker)
(In reply to Ken Chang[:ken](OOO from 2/18 to 3/1) from comment #27) > Peter, According to comment 25, could you please have someone to check the > log? Found some ipc and memory pressure errors happened and looked like the system got memory pressure. 03-16 13:30:24.659 204 689 I GonkMemoryPressure: Checking to see if memory pressure is over. 03-16 13:30:24.669 204 689 I GonkMemoryPressure: Memory pressure is over. 03-16 13:30:24.669 1290 1295 I GonkMemoryPressure: Memory pressure is over. 03-16 13:30:24.679 1461 1466 I GonkMemoryPressure: Checking to see if memory pressure is over. 03-16 13:30:24.679 1461 1466 I GonkMemoryPressure: Memory pressure is over. 03-16 13:30:29.779 204 689 I GonkMemoryPressure: Checking to see if memory pressure is over. 03-16 13:30:29.779 204 689 I GonkMemoryPressure: Memory pressure is over. 03-16 13:30:29.779 1290 1295 I GonkMemoryPressure: Checking to see if memory pressure is over. 03-16 13:30:29.779 1290 1295 I GonkMemoryPressure: Memory pressure is over. 03-16 13:30:29.789 1461 1466 I GonkMemoryPressure: Checking to see if memory pressure is over. 03-16 13:30:29.789 1461 1466 I GonkMemoryPressure: Memory pressure is over. 03-16 13:30:37.999 204 689 I GonkMemoryPressure: Checking to see if memory pressure is over. 03-16 13:30:37.999 1290 1295 I GonkMemoryPressure: Checking to see if memory pressure is over. 03-16 13:30:38.009 204 689 I GonkMemoryPressure: Memory pressure is over. 03-16 13:30:38.009 1290 1295 I GonkMemoryPressure: Memory pressure is over. 03-16 13:30:38.009 1461 1466 I GonkMemoryPressure: Checking to see if memory pressure is over. 03-16 13:30:38.019 1461 1466 I GonkMemoryPressure: Memory pressure is over. 03-16 13:30:38.579 204 884 I Gecko : ###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv 03-16 13:30:38.589 204 884 I Gecko : ###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv 03-16 13:30:38.589 204 884 I Gecko : ###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv 03-16 13:30:38.589 204 884 I Gecko : ###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv 03-16 13:30:38.589 204 884 I Gecko : ###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv 03-16 13:30:38.589 204 884 I Gecko : ###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv 03-16 13:30:38.599 204 884 I Gecko : ###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv 03-16 13:30:38.599 204 884 I Gecko : ###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv 03-16 13:30:38.599 204 884 I Gecko : ###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv 03-16 13:30:38.599 204 884 I Gecko : ###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv
Flags: needinfo?(pchang)
The memory pressure messages are harmless. They are caused by the memory pressure watcher which is used to detect when we're low on memory and send memory pressure events to all applications. Applications will respond to these by trying to reduce their memory consumption. The following messages about IPC errors can be caused by an app having died due to the lack of memory.
Triage: based on Comment 28 and 30, remove nom.
blocking-b2g: 2.2+ → -
Dears - we've checked logcat you provided yet, and couldn't find valued info. from my view, if more stable in base image and hard to reproduce, how about you roll back to check patches in nightly build that may cause this problem. tks.
Flags: needinfo?(youlong.jiang)
Keywords: crash
[Tracking Requested - why for this release]: This still reproduces rather easily on v18D-3 on 319MB config flame, but i think it should be made clear that this page contains MASSIVE amount of image files stitched together. I can't repro this on aries, which renders the page quite fast compared to my android phone (Oneplus). (it takes about slightly less than a minute to completely load the site) I'm strongly suspecting that flame device with 319MB can't handle this load reliably, as it even often LMKs on some CNN websites. Although there is no way to reset the device other than pulling the battery out once whitescreen happens (which is pretty serious- the sorry message would've been much nicer), I'm moving it to backlog for now until we find the resource to take a look at issue, || similar bug happens in devices with higher memory config.

Closing bugs with b2g-master=affected as it is likely to be out dated.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: