Closed Bug 877495 Opened 11 years ago Closed 11 years ago

[B2G] [Browser] Crash upon attempt to display 3D images

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

(blocking-b2g:leo+, b2g18 verified)

VERIFIED FIXED
blocking-b2g leo+
Tracking Status
b2g18 --- verified

People

(Reporter: dsubramanian, Assigned: sotaro)

Details

(Keywords: crash, reproducible, Whiteboard: [b2g-crash], leorun3, leorun4)

Crash Data

Attachments

(5 files, 1 obsolete file)

Attached file Logcat for Inari
Description: When the user taps on the molecule links, the browser crashes (Crash report links provided in the notes). Repro Steps: 1. Updated to Leo Build ID: 20130529070208 2. Launch Browser app 3. Go to http://bit.ly/css3d-mol 4. Select any of the links at the bottom of the page (Caffine, Salt, Buckyball or Graphite) Expected: Browser displays 3D images of the molecule Actual: Browser Crashes Environmental Variables: Device : Leo Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/6ca32ed2bbc6 Gaia: 8f5ab7bfd4a2921aab4e2de11e0d79a29c1bb062 Also tested on, Inari Build ID: 20130528070209 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/611d727390a4 Gaia: 5f499ab1e4a274d3d28e20139c9cdc546dc4fc69 Notes: Repro frequency: 100% See attached: logcat and crash reports. Crash report links: LEO: https://crash-stats.mozilla.com/report/index/6d813581-32c3-461f-8042-78ce32130529 INARI: https://crash-stats.mozilla.com/report/index/ba3937f9-b134-40cc-adb5-000c52130529
Attached file Logcat for LEO
status-b2g18: --- → ?
Component: Gaia::Browser → Canvas: WebGL
Product: Boot2Gecko → Core
Version: unspecified → Trunk
In the log, there is the following log. So it failed because of "Too many open files". Though current num of fd limit is 4096. It seem that num of fd did not hit 4096. Hmm. > E/memalloc(135): /dev/pmem: Failed to initialize pmem sub-heap: -1 > W/memalloc(135): Falling back to ashmem > E/memalloc(135): couldn't create ashmem (Too many open files) > E/msm7627a.gralloc(135): gralloc failed err=Too many open files > W/GraphicBufferAllocator(135): alloc(64, 57, 1, 00000133, ...) failed -24 (Too many open files) > E/memalloc(1684): /dev/pmem: Failed to map buffer size:11972608 offset:11956224 fd:1656 Error: Out of memory
Looks like a Shadow Layers crash.
Component: Canvas: WebGL → Graphics: Layers
Keywords: crash, reproducible
Severity: normal → critical
blocking-b2g: --- → leo?
By using following command, I confirmed that b2g process's fd number becomes more than 4096 :-( > watch --interval=1 "adb shell ls /proc/144/fd | wc -w"
I applied attachment 755771 [details] [diff] [review] to buri and leo device. Results are following. I see the problem because of file descriptor limit. 8192 is enough for the site, I think. - buri: no crash happend - leo: app crash happend because of out of memory.
The crash happened on leo after applying attachment 755771 [details] [diff] [review]. The crash is not related to file descriptor limit. Just becomes out of memory.
(In reply to Sotaro Ikeda [:sotaro] from comment #5) > Created attachment 755771 [details] [diff] [review] > patch - change file descriptor's limit to 8192 attachment 755771 [details] [diff] [review] is enough to fix file descriptor limit problem.
Comment on attachment 755771 [details] [diff] [review] patch - change file descriptor's limit to 8192 mwu, can you review the patch?
Attachment #755771 - Flags: review?(mwu)
Assignee: nobody → sotaro.ikeda.g
Comment on attachment 755771 [details] [diff] [review] patch - change file descriptor's limit to 8192 Is there a bug open for limiting the maximum number of layers?
Attachment #755771 - Flags: review?(mwu) → review+
(In reply to Michael Wu [:mwu] from comment #10) > Comment on attachment 755771 [details] [diff] [review] > patch - change file descriptor's limit to 8192 > > Is there a bug open for limiting the maximum number of layers? There is no actual bug for it. I am going to create it.
(In reply to Sotaro Ikeda [:sotaro] from comment #11) > > > > Is there a bug open for limiting the maximum number of layers? > > There is no actual bug for it. I am going to create it. Bug 877557 created.
change to use only one "ulimit".
Attachment #755771 - Attachment is obsolete: true
I misunderstood about "ulimit" in android. The default "ulimit" try to set both soft limit and hard limit. I am not sure why "ulimit -n 8192" did not change hard limit :-( http://androidxref.com/4.0.4/xref/system/core/sh/miscbltin.c#344
I confirmed attachment 755805 [details] [diff] [review] on buri and leo device.
Comment on attachment 755805 [details] [diff] [review] patch v2 - change file descriptor's limit to 8192 mwu, can you review the patch again?
Attachment #755805 - Flags: review?(mwu)
Crash Signature: [@ mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | nsTArray_base<nsTArrayInfallibleAllocator>::EnsureCapacity | mozilla::layers::ShadowLayerForwarder::EndTransaction ] [@ mozalloc_abort | NS_DebugBreak_P | mozilla::layers::PLayersChild::SendPGralloc…
Whiteboard: [b2g-crash]
Attachment #755805 - Flags: review?(mwu) → review+
Crash Signature: [@ mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | nsTArray_base<nsTArrayInfallibleAllocator>::EnsureCapacity | mozilla::layers::ShadowLayerForwarder::EndTransaction ] [@ mozalloc_abort | NS_DebugBreak_P | mozilla::layers::PLayersChild::SendPGralloc… → [@ mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | nsTArray_base<nsTArrayInfallibleAllocator>::EnsureCapacity | mozilla::layers::ShadowLayerForwarder::EndTransaction ] [@ mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | std::vector<mozilla::laye…
Component: Graphics: Layers → General
Product: Core → Boot2Gecko
Version: Trunk → unspecified
blocking-b2g: leo? → leo+
Attached file link to pull request
Pull request was merged.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Flags: in-moztrap?
Added Browser Suite Test Case #8524 [Browser] The Browser App displays 3D images on websites without crashing
Flags: in-moztrap? → in-moztrap+
The browsers crashes when the user taps on the Graphite /YBCO superconductor/ buckyball. This issue is appearing on found on leo build. Leo Build ID: 20130610070206 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/8e3f39363c54 Gaia: ce3b99781d182ad550a325206990c249b0dbcf0e Platform Version: 18.0
Whiteboard: [b2g-crash] → [b2g-crash], leorun3
The browser still crashes when the user taps on the any of the molecules present in the last row (Graphite /YBCO superconductor/ buckyball). This issue is appearing on found on leo build. Leo Build ID: Build ID: 20130625070217 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/29933d1937db Gaia: 1436e2778b90bd74635b0b94d1cf8ccb0d71b60c Platform Version: 18.1 RIL Version: 01.01.00.019.138
(In reply to Deepa Subramanian from comment #22) > The browser still crashes when the user taps on the any of the molecules > present in the last row (Graphite /YBCO superconductor/ buckyball). > > This issue is appearing on found on leo build. > > Leo Build ID: > Build ID: 20130625070217 > Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/29933d1937db > Gaia: 1436e2778b90bd74635b0b94d1cf8ccb0d71b60c > Platform Version: 18.1 > RIL Version: 01.01.00.019.138 Can you get the logcat of the crash?
I checked the crash on leo device. The crash happened because of out of memory. It is a different problem from the file descriptor limit that solved in this bug.
Created Bug 889966 for the crash because of out of memory.
Bug 889957 is created to gather bugs related to http://threejs.org/examples/css3d_molecules.html performance problems
Whiteboard: [b2g-crash], leorun3 → [b2g-crash], leorun3, leorun4
Crash is resolved: Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/282b5c37cf8d Gaia e2ef782119b7e79fc62c48d36f0c36909d982988 BuildID 20130712070210 Version 18.0
Status: RESOLVED → VERIFIED
Blocks: 894037
No longer blocks: 894037
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: