796644 - [browser] Browser failed to render a page due to OOM

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[GH to BZ]

[GitHub issue by dhylands on 2012-09-14T06:57:00Z, https://github.com/mozilla-b2g/gaia/issues/4720]
I tried to navigate to http://www.weblocal.ca/shuswap-chefs-salmon-arm-bc.html in the browser on my otoro. It started to render, but after a short while it was replaced with a :( screen.

Comment 1

[GH to BZ]

[GitHub comment by benfrancis on 2012-09-14T11:34:47Z]
This is almost certainly a platform bug, would you mind filing a bug on Bugzilla?

Comment 2

[Al Tsai [:atsai]]

Same Case when visit http://tw.yahoo.com

Comment 3

[John Shih]

Seems like a platform bug, change tag to general

Comment 4

[Andrew Overholt [:overholt]]

Can we get stack traces?  Are these crashing for the same reason?

Comment 5

[Dave Hylands [:dhylands]]

So I tried it today, using today's build and that particular page renders fine.

At the time I reported the problem, I was dogfooding the phone and there was no computer around to see if something crashed or not.

Comment 6

[John Shih]

I can easily reproduce it with just load a sequence of websites (e.g web1 -> web2 -> web3)
It usually happens on web2 or web3

Comment 7

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

I guess this is related to oom. I reproduced this bug. The "Well, this is embarrassing :(" message is shown when remote browser is crashed (or killed). I got following message from dmesg when remote browser receives sigkill (pid of remote browser is 619):

<4>[10-12 03:44:43.683] [25: kswapd0]select 619 (Browser), adj 1, size 17241, to kill
<4>[10-12 03:44:43.683] [25: kswapd0]send sigkill to 619 (Browser), adj 1, size 17241
<3>[10-12 03:45:03.092] [73: kworker/0:2]TAOS: lux_timep->saturation=8100 hi=641 lo=385

Comment 8

[Shian-Yow Wu [:swu]]

Base on comment 7, make it depend on bug 798002.

Comment 9

[Andrew Overholt [:overholt]]

If this is easily reproducible, it seems bad enough that we should fix it.

Assigning to you, Patrick, since it appears you're working on it.  If that's not the case or if you don't have time, feel free to re-assign to nobody.

Comment 10

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

(In reply to Andrew Overholt [:overholt] from comment #9)
> If this is easily reproducible, it seems bad enough that we should fix it.
> 
> Assigning to you, Patrick, since it appears you're working on it.  If that's
> not the case or if you don't have time, feel free to re-assign to nobody.

Hi Andrew,

I can reproduce this bug when system is running out of memory and get
the dmesg. If it is really caused by oom, I think this problem will be fixed
after shrinking memory is done. I will keep following this bug, but currently
I don't have an idea of fixing this. Should I keep being assigned to or just
assign to nobody?

Thanks

Comment 11

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Hi Alex, can you raise this up to a P1 Crit issue please?  This happens way too much esp for e.me apps.

Comment 12

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

(In reply to Naoki Hirata :nhirata from comment #11)
> Hi Alex, can you raise this up to a P1 Crit issue please?  This happens way
> too much esp for e.me apps.

Hi, if you are talking about bug 799651, maybe it were different kind of bug. According to bug 799651 comment 6, it seems that browser isn't actually crashed, but there is some error message when loading page of e.me apps.

Comment 13

[Ben Francis [:benfrancis]]

I don't think there's any actionable work here for Patrick to do.

The sad face errors experienced in the browser are most likely caused by running out of memory, we have project slimfast for that.

Sad face errors you see in e.me are completely different. They're not caused by running out of memory (that would crash the entire homescreen), they're just 404s and other network errors. You can file separate bugs for those but fixing them is probably going to be out of our control.

I suggest closing this bug as invalid, not because it isn't a real problem but because it's a known problem that's being tracked in many other places.

Comment 14

[Alex Keybl [:akeybl]]

(In reply to Naoki Hirata :nhirata from comment #11)
> Hi Alex, can you raise this up to a P1 Crit issue please?  This happens way
> too much esp for e.me apps.

Can you file a separate bug for the e.me 404s and blocking-basecamp:? it? I think somebody should follow up on that, even if it is an external issue.

(In reply to Ben Francis [:benfrancis] from comment #13)
> I don't think there's any actionable work here for Patrick to do.

Can this bug track methods of recovering from OOM situations? Or is that impossible or a waste of time?

Comment 15

[Ben Francis [:benfrancis]]

(In reply to Alex Keybl [:akeybl] from comment #14)
> Can this bug track methods of recovering from OOM situations? Or is that
> impossible or a waste of time?

The only way to recover from a fatal error caused by running out of memory is to start again (reload the tab), that's why it's called a fatal error :)

Comment 16

[Alex Keybl [:akeybl]]

(In reply to Ben Francis [:benfrancis] from comment #15)
> (In reply to Alex Keybl [:akeybl] from comment #14)
> > Can this bug track methods of recovering from OOM situations? Or is that
> > impossible or a waste of time?
> 
> The only way to recover from a fatal error caused by running out of memory
> is to start again (reload the tab), that's why it's called a fatal error :)

OK - if we don't think it makes sense to automatically try to recover, we should re-nominate this for blocking-basecamp review since there wouldn't be anything still actionable in this bug.

Comment 17

[Ben Francis [:benfrancis]]

It's already been decided that we don't try and automatically recover from browser tab crashes if the browser app is currently visible, but if it's in the background when the crash occurs we will automatically reload the tab when the user brings it into focus. This has already been implemented in https://github.com/mozilla-b2g/gaia/pull/5166

There's nothing we can do to recover from network errors in third party content except provide the option for the user to reload or quit, which is being done in bug 796750

Crashes caused by running out memory can only really be solved by reducing memory usage, which is tracked in bug 797189

So as it seems there's no other work for this bug to cover, I'm going to close it as WONTFIX. Please re-open if you think otherwise.