[browser] opening multiple tabs causing major system slowdown or crash

Bug #1542002 reported by Victor Tuson Palau
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Canonical Pocket Desktop
Critical
Unassigned
The Avila project
Undecided
Unassigned
webapps-sprint
High
David Barth
webbrowser-app (Ubuntu)
Critical
Olivier Tilloy

Bug Description

the default browser constantly seems to crash when set up as pocket desktop. For example when viewing this page:
http://www.digitaltrends.com/mobile/bq-aquaris-m10-ubuntu-edition-tablet-news

Also when using google docs, and even launch pad.

Changed in canonical-pocket-desktop:
importance: Undecided → Critical
Revision history for this message
Victor Tuson Palau (vtuson) wrote :
Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

I have 6 tabs open on a mako and on that site. I got a warning that the rendering process was closed due to low memory, Try closing unneeded tabs and reloading. Which I did.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Are there related crash files under /var/crash/ ?

Changed in webbrowser-app (Ubuntu):
status: New → Incomplete
Revision history for this message
Bill Filler (bfiller) wrote :

Is this browser specific or are many apps crashing? Suspecting an out of memory situation perhaps.

kevin gunn (kgunn72)
Changed in webbrowser-app (Ubuntu):
importance: Undecided → Critical
Changed in canonical-devices-system-image:
importance: Undecided → Critical
Changed in canonical-devices-system-image:
status: New → Incomplete
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Does anyone have a stacktrace yet?

Revision history for this message
Olivier Tilloy (osomon) wrote :

I have been stress-testing the browser on frieza this morning, opening multiple tabs with resource-hungry websites (google maps, google docs, youtube playing videos, …), and didn’t get a single crash. Using the browser felt slow-ish, but so did the rest of the UI, so it’s not a browser-specific problem.

summary: - browser chrashes a lot in Pocket Desktop
+ browser crashes a lot in Pocket Desktop
Revision history for this message
Olivier Tilloy (osomon) wrote : Re: browser crashes a lot in Pocket Desktop

@Victor: are you still seeing the crashes? Can you provide details on your test configuration (device, image, peripherals attached, …)? Thanks!

Revision history for this message
Olivier Tilloy (osomon) wrote :

I’ve been stress-testing the browser for a while with the latest image (#35) on frieza, and I’m seeing the system getting slower and slower as the number of open tabs increases, but the OOM killer never seems to kill rendering processes, which is unexpected.

The entire UI eventually completely freezes (last time while I was watching an HD video fullscreen in youtube), but the browser app doesn’t actually crash.

Revision history for this message
Bill Filler (bfiller) wrote : Re: opening multiple tabs causing major system slowdown or crash

@john mc
is there someone from your team who can help debug why OOM killer is never kicking in on the rendering processes?
That seems to be the root cause of the issue.

summary: - browser crashes a lot in Pocket Desktop
+ opening multiple tabs causing major system slowdown or crash
Changed in webbrowser-app (Ubuntu):
status: Incomplete → Confirmed
assignee: nobody → Olivier Tilloy (osomon)
Changed in canonical-devices-system-image:
status: Incomplete → Confirmed
assignee: nobody → John McAleely (john.mcaleely)
milestone: none → ww08-2016
summary: - opening multiple tabs causing major system slowdown or crash
+ [browser] opening multiple tabs causing major system slowdown or crash
Revision history for this message
John McAleely (john.mcaleely) wrote :

I've assigned it to chunsang, but his queue is quite long.

Changed in canonical-devices-system-image:
assignee: John McAleely (john.mcaleely) → David Barth (dbarth)
Changed in avila:
assignee: nobody → John McAleely (john.mcaleely)
assignee: John McAleely (john.mcaleely) → Chunsang Jeong (chunsang)
milestone: none → backlog
Changed in canonical-devices-system-image:
milestone: ww08-2016 → backlog
milestone: backlog → 11
Revision history for this message
Olivier Tilloy (osomon) wrote :

The reason why the OOM killer never kicks in is because of recent changes in the browser (https://bazaar.launchpad.net/~phablet-team/webbrowser-app/trunk/revision/1361, released with version 0.23+16.04.20160223-0ubuntu1) which automatically unload background tabs when it thinks the system is running low on memory.

A situation where the OOM killer would do its job is with only one tab open, and many other apps open consuming memory, but in that case it’s likely that it would kill background apps first, not the oxide renderer process.

Revision history for this message
Olivier Tilloy (osomon) wrote :

I did an experiment: I commented out the code that unloads background tabs in the browser, and opened a large number of tabs with memory-hungry websites (google maps, here maps, google docs, youtube, google plus, …).

The OOM killer eventually kicked in, but it didn’t kill oxide renderer processes, instead it killed the browser process directly (before that it had killed a number of background apps):

Mar 22 15:48:51 ubuntu-phablet kernel: [ 2527.530207] (0)[54:kswapd0]lowmemorykiller: Killing 'webbrowser-app' (7243), adj 1, score_adj 110,
Mar 22 15:48:51 ubuntu-phablet kernel: [ 2527.530207] to free 524140kB on behalf of 'kswapd0' (54) because
Mar 22 15:48:51 ubuntu-phablet kernel: [ 2527.530207] cache 65320kB is below limit 65536kB for oom_score_adj 12
Mar 22 15:48:51 ubuntu-phablet kernel: [ 2527.530207] Free memory is 0kB above reserved

I wonder if the OOM killer logic could be tuned to kill renderer processes first, and then the browser process as a last resort.

Note that the initial report said that the browser crashed, but it’s incorrect: the browser is being killed, which makes it instantly disappear, thus appearing to be a crash to the user, but there’s no crash file, the process was simply terminated by the system.

As for the major slowdown, not really sure what can be done about it: when out of memory, the system is bound to be slower. Note that the new browser mechanism to unload background tabs when low on memory should mitigate the issue.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Not sure there’s anything left to investigate on that one (aside from tuning the OOM killer to favour killing renderer processes over the browser process).

Changed in webbrowser-app (Ubuntu):
status: Confirmed → Invalid
David Barth (dbarth)
Changed in webapps-sprint:
assignee: nobody → Olivier Tilloy (osomon)
no longer affects: webapps-sprint
Changed in webapps-sprint:
assignee: nobody → David Barth (dbarth)
importance: Undecided → High
status: New → Incomplete
milestone: none → sprint-22
no longer affects: canonical-devices-system-image
Revision history for this message
Chunsang Jeong (chunsang) wrote :

Couldn't reproduce it with recent frieza image even with opening 10 tabs from browser. Mem usage decreased quickly when there wasn't activity and device didn't get slow when swiping.

current build number: 106
device name: frieza
channel: ubuntu-touch/rc-proposed/bq-aquaris-pd.en
last update: 2016-05-14 00:11:47
version version: 106
version ubuntu: 20160514
version device: 20160505.0
version custom: 20160511--40-9-vivid

Revision history for this message
Olivier Tilloy (osomon) wrote :

That’s most likely because the behaviour of the mechanism to unload background tabs when running low on memory has recently been tweaked (see bug #1576639).

David Barth (dbarth)
Changed in webapps-sprint:
milestone: sprint-22 → sprint-23
Changed in avila:
assignee: Chunsang Jeong (chunsang) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers