Closed Bug 1112371 Opened 10 years ago Closed 9 years ago

crash in mozilla::layers::SharedPlanarYCbCrImage::SetDataNoCopy

Categories

(Core :: Audio/Video: Playback, defect, P2)

Product:
Core
Component:
Audio/Video: Playback
Version:
34 Branch
Platform:
All
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox40 + wontfix
firefox41 + wontfix
firefox42 + wontfix
firefox43 + wontfix

People

(Reporter: mathew.hodson, Unassigned)

References

Details

(Keywords: crash, topcrash-linux)

Crash Data

Attachments

(1 file)

crash.txt
7.78 KB, text/plain
Details 
This bug was filed from the Socorro interface and is 
report bp-5d205a13-873b-42ad-90d6-2b9152141216.
=============================================================
Keywords: crash
Have the same issue (same backtrace) while playing any youtube playlist (using html5, not flash).
After updating to Firefox 35 I haven't this problem.
Hi, I still get this in 36.0. It usually happens when using Youtube with NO flash plugins, just like Ilya Gordeev says.

If I open youtube pages in new tabs, even from an external program (e.g. a feed reader) the crash seems to happen _at_least_ once a day.

It's quite annoying, can any developer replicate this?

Thanks,
   Antonio
I'm also having this problem in 37.0.1 on Ubuntu 14.04. It seems to be happening on YouTube a lot where I'm using the HTML5 player.

I experience this crash many times a day which makes Firefox almost unusable. I checked my last 10 crash reports and they all happened in mozilla::layers::SharedPlanarYCbCrImage::SetDataNoCopy.

Here is my latest crash report:
https://crash-stats.mozilla.com/report/index/b3b8f639-7eea-49d5-a29a-147432150419

Is there anything I could do to help debug this issue?
I tried setting media.gstreamer.enabled to false in about:config after submitting my previous comment one week ago, and haven't had any Firefox crashes since. Obviously, functionality is reduced and I now have to activate Flash more often to play videos online.
This is also happening with the latest version (38) in ubunutu
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have been having trouble with crashes and runaway CPU usage for a long time in Firefox, but these issues seem to have disappeared after uninstalling the totem-mozilla package from Ubuntu. 

I have also tried Linux Mint 17.1 (x64) on another computer and have again had similar troubles with Firefox (37.0.2). I have again uninstalled totem-mozilla and have not had any misbehavior since. I also can't seem to find any case of reduced functionality caused by uninstalling this package.
Attached file crash.txt — 
I Opened Firefox with terminal and it crashed while playing Youtube Video. I have added the Error log in the attachment as I got from the Terminal. I think the cause is as following:

[NPAPI 4545] ###!!! ABORT: Aborting on channel error.: file /build/buildd/firefox-38.0+build3/ipc/glue/MessageChannel.cpp, line 1584
As this seems to be related to totem-mozilla, which apparently undermines the intentional limit of video formats supported on the web, I wonder if we could blacklist this software in some form.
OK, totem-mozilla is no longer maintained, and that's even more reason to blacklist it somehow - but Safwam and his crash in comment #10 doesn't even have it, so it must be something else there.
Ok, I might have mixed up two unrelated issues then. I think originally I was having trouble with both crashes and high CPU usage. On closer recollection, maybe uninstalling libtotem-mozilla only solved the CPU usage issue. Maybe it's related to this:

https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1304351

Checking my crashes page, it doesn't show anything for my Linux Mint installation, so it might only have been the CPU usage issue I had.

On the Ubuntu system were I experienced crashes I managed to stop it from crashing by changing Firefox settings. I had already tried disabling hardware acceleration which didn't seem to help, but then I saw on the about:support page that my old Intel graphics processor was blacklisted. It might have been that I changed the settings and forced hardware acceleration on that solved my issues.

Is it possible to see from the crash reports whether hardware acceleration is on? Safwam's system also seems to have Intel graphics when looking at the report. (but not as old as my Ubuntu machine)
(In reply to Joakim from comment #13)
> Is it possible to see from the crash reports whether hardware acceleration
> is on? Safwam's system also seems to have Intel graphics when looking at the
> report. (but not as old as my Ubuntu machine)

I had crash while turning On Hardware accelerator. Then I turn it off and face the same crash. So I think turning off Hardware accelerator does not have any deal with this
Well, the crash seems to have to do with GStreamer, I don't see that it obviously has to do with the Intel driver or chipset. But I see that you both have GStreamer 1.0 loaded, and I think we don't officially support that right now, it's only a compile option (which your packages might have on), see also bug 1112371. That said, work is going on to switch to it by default - which might also expose everyone to those crashes. :(

Edwin, I see you commenting on that other bug I mentioned, is the crash here a general thing with GStreamer 1.0? Do we have someone in the team to look at what's going on here? This is the top crash on Linux on 37 and 38 at least.
Flags: needinfo?(edwin)
Hi Safwan,

What does the "GPU Accelerated Windows"	line on the about:support say? I found that even if I enabled hardware acceleration in the settings dialog, it wasn't enabled because my card was blacklisted.
Hi Joakim,
It says 	0/1 Basic 
Here is the screenshot http://i.imgur.com/HLHyASV.png
Hi,
This crash seems to be happen while the Youtube Video is changing from one to another. Does this only happens to me or other also facing the same?
There were changes made to SetDataNoCopy in bug 928806. Maybe there are some clues in that changeset.
Blocks: 947287
Component: Audio/Video → Audio/Video: Playback
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #15)
> Edwin, I see you commenting on that other bug I mentioned, is the crash here
> a general thing with GStreamer 1.0? Do we have someone in the team to look
> at what's going on here? This is the top crash on Linux on 37 and 38 at
> least.

It's not so much that we don't support gstreamer-1.0 more that our build servers need to be upgraded. Ralph - can you look at this to see if it is anything obvious?
Flags: needinfo?(edwin) → needinfo?(giles)
status-firefox40: --- → ?
Keywords: topcrash-linux
This is a top crash on linux.
tracking-firefox40: --- → ?
It looks like this is specific to gstreamer-1.0, Ubuntu or both. This bug was first filed against Firefox 34, but there's been a huge spike with the 40 release. And yet, there are no crash reports from 39 or 40 prior to release, and no crashes in 39 or 40 with a build id matching any of our official releases. This is consistent with the issue being specific to the gstreamer-1.0 code path, since our official builds are against gstreamer-0.10 for these releases.

99.3% of the reported crashes also have Ubuntu in their uname. If this were a general Linux issue, I'd expect at least a few other distro kernels in there. Chris Coulson pushed the Firefox 40 package on August 4th, less than a week before this was marked a top crasher. The corresponding gstreamer update in Ubuntu 14.04 was in February.

The Ubuntu package references the FIREFOX_40_0_BUILD4 tag, but we actually released BUILD5, so that's another possible difference. The relevant change would be bug 1137580. Chris, do you have any ideas on this? Is it worth pushing an Ubuntu update with this patch applied, or with something more recent like 40.0.2 and seeing if this goes down?

Thanks to Anthony Hughes for doing the crash stats analysis.

As for the actual crash, it's on the YCbCrImageDataSerializer contructor call. mTextureClient->GetBuffer() and ->GetBufferSize() could crash if e10s is enabled and we're using the Shared version, but that's unlikely in these releases. In the normal Memory implementation they don't dereference. That suggests mTextureClient is itself null. There's MOZ_ASSERT for this at the top of SetDataNoCopy() but that only affects debug builds.

Matt Woodrow pointed out moz_gfx_memory_reset() doesn’t check the return value of AllocateAndGetNewBuffer(), which is fallible, and this could leave us with a null mTextureClientBuffer under memory pressure. 60% or so of the crashes are on 32-bit, which makes memory pressure a more likely factor.

The gst_video_frame_unmap() right after SetDataNoCopy() is fine; this uses our own allocator for the GstBuffer where unmap() is a no-op.
Assignee: nobody → giles
Flags: needinfo?(giles) → needinfo?(chrisccoulson)
We didn't ship BUILD5 because we'd already validated BUILD4 and it looked like the extra change (bug 1137580) was to fix a specific issue with an extension on Windows. In fact, it looks like the code touched by that is inside an #ifdef MOZ_MEMORY_WINDOWS
Flags: needinfo?(chrisccoulson)
Right you are, that's unlikely to make a difference. What about the point releases?
It looks like the changes between 40.0 and 40.0.2 are all Windows-specific too
Priority: -- → P2
(In reply to Ralph Giles (:rillian) from comment #22)
> It looks like this is specific to gstreamer-1.0, Ubuntu or both. This bug
> was first filed against Firefox 34, but there's been a huge spike with the
> 40 release.

I think the reason that there was a spike with Firefox 40 is that YouTube started providing the HTML5 player by default with that version. When I first reported the crash, it was caused by YouTube's HTML5 video player, and that is still what triggers it for me.
40.0.3 has a gstreamer fix (bug 1145230). Maybe this helps.

> We didn't ship BUILD5 because we'd already validated BUILD4 and it looked like the extra change (bug
> 1137580) was to fix a specific issue with an extension on Windows.
"Good" to know you are not shipping the official Firefox releases sometimes :/
(even if, here, I agree there is no impact on Linux).

Anyway, too late for 40... Maybe ritu wants to track it.
status-firefox40: ? → wontfix
status-firefox41: --- → affected
tracking-firefox40: ? → +
tracking-firefox41: --- → ?
Bug 1145230 looks like a separate issue, unfortunately. Not that ubuntu shouldn't push it anyway.
[Tracking Requested - why for this release]:

Nominating for 42:? tracking instead as the crash-stats page does not indicate this crash being hit in FF41 at all from what I see. 

I do not see a reason to track it in FF41 as there are no crash hits in FF41 with this signature.
status-firefox42: --- → ?
tracking-firefox41: ? → -
tracking-firefox42: --- → ?
crash-stats only shows crashes for Firefox 41 from Mozilla builds, which are built with gstreamer-0.10, so that's not surprising.
[Tracking Requested - why for this release]: incorrect analysis of the impact for 41
status-firefox42: ? → affected
tracking-firefox41: - → ?
OK, sounds like we need to track for 41 then. I'm not sure if 43 is also affected.  
rillian if you come up with a fix, please request uplift! Thanks.
status-firefox43: --- → ?
tracking-firefox41: ? → +
tracking-firefox42: ? → +
tracking-firefox43: --- → +
(In reply to Kevin Brosnan from comment #31)
> [Tracking Requested - why for this release]: incorrect analysis of the
> impact for 41

Kevin, I looked again and when I look at the signature summary and product info for past 7 days, 14 days and 28 days, I do not see FF41 in there. Could you please add a link if you see any differently? If not, I would still like to untrack for 41.
Flags: needinfo?(kbrosnan)
Re tracking. Note that we've only seen crash reports from Ubuntu's build, not from any of ours, which explains why we've only seen release crashes: they haven't distributed 41 builds. We may or may not see more of these when 41 goes to release.
See Also: → 1061025
See Also: → 1198884
On crash-stats.mozilla.com, I don't see this signature anymore under Firefox 40.0.3. It has been replaced with the crash signature libxul.so@0xeb7f6d | libxul.so@0x16db418 | libgstvideo-1.0.so.0.204.0@0x242b07 that happens under the same circumstances.

The new signature is tracked in bug 1198884.
Too late to fix for 41. Should we be tracking bug 1198884 instead of this one? KaiRo?
status-firefox41: affected → wontfix
Flags: needinfo?(kairo)
(In reply to Ritu Kothari (:ritu) from comment #36)
> Too late to fix for 41. Should we be tracking bug 1198884 instead of this
> one? KaiRo?

Probably not. The signature in the other bug is mostly only there because of missing symbols. I hope it will go back to the signature here once the symbols work correctly.
Flags: needinfo?(kairo)
Ralph, I still see signature of 41 Ubuntu packages in bug 1198884. As the bug seems related, any chance you could work around the bug?  If not, we should check for the gstreamer version in the configure to make sure that we block, or at least warning, that we don't support version 1.0.

Or should we check with Chris Coulson to force the usage of a supported version of gstreamer ?
Flags: needinfo?(giles)
Flags: needinfo?(chrisccoulson)
Here are the error reports from Ubuntu.

https://errors.ubuntu.com/problem/df38709ccfa96c4d166ef8915522345585015116
I'm not able to work on this at the moment. I'm afraid we're at patches-welcome for gstreamer bugs. :/
Flags: needinfo?(giles)
Assignee: giles → nobody
OK, this is a wontfix for 42 then.
status-firefox42: affected → wontfix
status-firefox43: ? → affected
FFMpeg support coming in 43 may help with this crash but we won't be able to tell until 43 goes to release. 
 
I don't think we're taking any direct action here for 43 though, so I'm wontfixing this bug for now.
status-firefox43: affected → wontfix
status-firefox44: --- → ?
That crash is a null pointer error, but the stack trace is missing links to the source code.
gstreamer is going in bug 1234092
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(kbrosnan)
Flags: needinfo?(chrisccoulson)
status-firefox44: ? → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: