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

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.

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

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

Does anyone have a stacktrace yet?

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.

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

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.

@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.

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

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.

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.

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).

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

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).