1397329 - Slack crashes Firefox ESR w/ gifs

Status: RESOLVED DUPLICATE of bug 523950

(Core :: Graphics, defect, P3)

Description

[cand]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:38.0) Gecko/20100101 Firefox/38.0

Steps to reproduce:

1. Go to a slack channel that has a large gif posted


Actual results:

Firefox crashes instantly. dmesg output:
Web Content[2100]: segfault at 0 ip b5cbcc50 sp bfb42e60 error 6 in libxul.so[b366a000+3df9000]
Web Content[2172]: segfault at 0 ip b5c07c50 sp bfcec750 error 6 in libxul.so[b35b5000+3df9000]
Web Content[2286]: segfault at 0 ip b5beac50 sp bfc33e20 error 6 in libxul.so[b3598000+3df9000]

This happened both in 52.0.1 and the latest ESR, 52.3.0.


Expected results:

Firefox should not crash

Comment 1

[Kohei Yoshino]

Please provide your crash report ID: https://support.mozilla.org/kb/mozillacrashreporter

Comment 2

[cand]

I do not get the crash reporter popup. about:crashes is empty.

Comment 3

[cand]

The platform is 32-bit TinyCore linux 7, and I'm using the ESR binary downloaded straight from Mozilla.

Comment 4

[cand]

Oh, the crash also happens in safe mode.

Comment 5

[cand]

Attachment: GDB backtrace

Since the crash reporter does not come up, here's a gdb backtrace.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

Lee, can you reproduce this, or get something out of the stack?

Comment 7

[Lee Salzman [:lsalzman]]

The crash stack unfortunately has no symbols in it, so there is not much we can do with this based on the information supplied.

cand, can you please attach one of the gifs that is causing Firefox to crash? It would help more if we could at least know that we have some reliable way to reproduce it, or at least attempt to reproduce it.

Andrew or Timothy, does this bug look like anything we might have fixed in the past somewhere after 52?

Comment 8

[Timothy Nikkel (:tnikkel)]

I can't think of any gifs in the wild crashes that would be in 52 (or any supported release really).

Can you try a newer release of firefox to see if it crashes?

Are they actually gifs? I lot of "gifs" nowadays are html video elements.

Comment 9

[cand]

I cannot give you the gif in question for two reasons:
1) It is confidential to my employer
2) I cannot get at it, because Firefox crashes immediately, and I refuse to install Chrome. Alternative Webkit browsers I have available fail to load slack.

It is likely Slack does some processing to large gifs, perhaps converting them to a html5 video indeed. They do autoplay like a a gif, and do not have video controls, but I'm aware those can be hidden.

I can test the latest firefox later today.

> The crash stack unfortunately has no symbols in it, so there is not much we can do with this based on the information supplied.
How so? Reading your help pages, they say you keep the symbols for official builds on your servers, and that's how you can interpret the traces. Is that information out of date?

Comment 10

[cand]

Also, the previous ESR, 38, did not crash even in slack channels with large gifs, but I had to stop using it when Slack stopped working in it.

Comment 11

[cand]

Firefox 55.0.3 crashes when logging in to slack, before I can even try to open the channel with the gif.

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

Is running mozregression [1] an option to get us to pinpoint when this started happening?

[1] http://mozilla.github.io/mozregression/install.html, http://mozilla.github.io/mozregression/quickstart.html

Comment 13

[Lee Salzman [:lsalzman]]

cand, could you maybe find us some public domain gif that would trigger the crash, so that it can be safely posted here and thus give us a way to reproduce? It would be greatly appreciated.

Comment 14

[cand]

I don't think mozregression will work, as slack does not allow old Firefox versions, it pops a page saying you must upgrade to use it. I doubt spoofing the useragent would help, as they likely do feature tests too.

It will be hard to find any public domain gif, especially if slack converts them to html5. I only use Firefox for slack, doing everything else in my webkit browser.

Comment 15

[Romain Testard [:RT]]

Cand, are you still experiencing this issue?

Comment 16

[cand]

It stopped happening when I added a GB of RAM to my VM (1 to 2 GB). So I believe it's due to FF using a massive amount of RAM to show the gifs -> malloc fails -> FF does not test the pointer and crashes.

At no point were there OOM killer messages in dmesg, so FF must have tried to allocate so much more that Linux straight up said no. The VM did have swap, but a very small amount of it, around 100mb.

Comment 17

[Lee Salzman [:lsalzman]]

(In reply to cand from comment #16)

It stopped happening when I added a GB of RAM to my VM (1 to 2 GB). So I believe it's due to FF using a massive amount of RAM to show the gifs -> malloc fails -> FF does not test the pointer and crashes.

At no point were there OOM killer messages in dmesg, so FF must have tried to allocate so much more that Linux straight up said no. The VM did have swap, but a very small amount of it, around 100mb.

That sounds more like Linux overcommit behavior. You have more virtual memory than physical memory, which Linux will happily allocate. Then when that memory is actually touched, Linux then triggers the fault on it because it fails to back it. It's not a malloc behavior per se, but a Linux behavior.

It's also possible for a failed malloc to occur somewhere in our code, but most places should either trigger an assertion if that occurred, or be resilient to that situation and fail gracefully. However, the stack trace posted doesn't give us enough to go on to say one way or another.

Thus, I am not sure this bug is actionable at this point.

Comment 18

[Andrew Osmond [:aosmond] (he/him)]

We stopped trying to decode every frame in advance with bug 523950 (and some followups). I wouldn't expect to see this anymore.