Can you please test it without flash plugin? It looks like flash dies and Firefox fails to reload plugin-container.

I set the flash plugin to disabled in about:addons, but I still get the crash.
Note that it was set to "Ask to Activate" before.

I moved the .so file of the flash player to another directory and about:plugins confirmed it's not there - but even without flash the crash is still reproducible.

https://crash-stats.mozilla.com/report/index/d4adace5-c603-4f68-b97e-f7bc92140610 - without plugin
https://crash-stats.mozilla.com/report/index/e2bbd5b6-f350-49db-80e0-531972140610 - with plugin set to "Disabled"

Note that these crashes were not observed by ABRT, but the Mozilla crashreporter did see them. So I assume the flash crash (which is the limited plugin-container backtrace above) is a side effect of the actual browser crash.

Also, setting media.gstreamer.enabled to False makes the crash go away. Since it's gstreamer related and crashes way more often in Firefox 30, I'd say it's a residue of the move to gstreamer1. gstreamer1 also tries to use libva by default, perhaps this somehow conflicts with Firefox (gstreamer 0.10 didn't use libva unless you explicitly told it to).

Okay...let's move it to gstreamer for further investigation.

I still think this is a firefox bug, because other gstreamer1 apps works well without crashing.

I managed to get a proper backtrace from gdb, I hope it helps:

libva info: VA-API version 0.35.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: va_openDriver() returns -1

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffa2e30700 (LWP 5872)]
0x00007fffa078cb52 in va_TraceEnd () from /lib64/libva.so.1

(gdb) bt
#0  0x00007fffa2b2ab52 in va_TraceEnd () at /lib64/libva.so.1
#1  0x00007fffa2b2868f in vaTerminate () at /lib64/libva.so.1
#2  0x00007fffa28ccd7d in gst_vaapi_display_finalize (display=0x7fffbf6c4da0) at gstvaapidisplay.c:848
#3  0x00007fffa28ccd7d in gst_vaapi_display_finalize (display=0x7fffbf6c4da0) at gstvaapidisplay.c:978
#4  0x00007fffa28d37cf in gst_vaapi_mini_object_unref (object=0x7fffbf6c4da0) at gstvaapiminiobject.c:34
#5  0x00007fffa28d37cf in gst_vaapi_mini_object_unref (object=0x7fffbf6c4da0) at gstvaapiminiobject.c:137
#6  0x00007fffa28ce0f8 in gst_vaapi_display_new (klass=0x7fffb8264b00, init_type=3449644848, init_value=0x0) at gstvaapidisplay.c:1096
#7  0x00007fffa37676c0 in gst_vaapi_ensure_display (display_type=<optimized out>) at gstvaapipluginutil.c:102
#8  0x00007fffa37676c0 in gst_vaapi_ensure_display (element=element@entry=0x7fffb6c4f980, type=GST_VAAPI_DISPLAY_TYPE_ANY) at gstvaapipluginutil.c:129
#9  0x00007fffa3766ed6 in gst_vaapi_plugin_base_ensure_display (plugin=0x7fffb6c4f980) at gstvaapipluginbase.c:232
#10 0x00007fffa3765758 in gst_vaapidecode_query (decode=<optimized out>) at gstvaapidecode.c:596
#11 0x00007fffa3765758 in gst_vaapidecode_query (decode=<optimized out>) at gstvaapidecode.c:897
#12 0x00007fffa3765758 in gst_vaapidecode_query (pad=<optimized out>) at gstvaapidecode.c:952
#13 0x00007fffa3765758 in gst_vaapidecode_query (pad=0x7fffb6c4f980 [GstVaapiDecode], parent=0x7fffb6c4f980 [GstVaapiDecode], query=0x7fffaa942770) at gstvaapidecode.c:976
#14 0x00007fffa7d5cc5e in gst_pad_query (pad=0x7fffb96e80e0 [GstPad], query=0x7fffaa942770) at gstpad.c:3511
#15 0x00007fffa7d8c8b2 in gst_pad_query_caps (pad=0x7fffb96e80e0 [GstPad], filter=0x0) at gstutils.c:2764
#16 0x00007fffa7d5487c in gst_pad_link_prepare (flags=<optimized out>, sink=<optimized out>, src=<optimized out>) at gstpad.c:2002
#17 0x00007fffa7d5487c in gst_pad_link_prepare (srcpad=0x7fffb84b4bf0 [GstPad], sinkpad=0x7fffb96e80e0 [GstPad], flags=2861835904) at gstpad.c:2139
#18 0x00007fffa7d5f5bb in gst_pad_link_full (srcpad=0x7fffb84b4bf0 [GstPad], sinkpad=0x7fffb96e80e0 [GstPad], flags=GST_PAD_LINK_CHECK_DEFAULT) at gstpad.c:2264
#19 0x00007fffa6979f0e in analyze_new_pad (chain=<optimized out>, factories=<optimized out>, caps=<optimized out>, pad=<optimized out>, dpad=<optimized out>, src=<optimized out>, dbin=<optimized out>)
    at gstdecodebin2.c:2074
#20 0x00007fffa6979f0e in analyze_new_pad (dbin=0x7fffb8428ca0 [GstDecodeBin], src=0x7fffa4fe9dd0, pad=0x7fffb6c4f980 [GstVaapiDecode], caps=0x7fffbd45fbd0, chain=0x7fffbb644800) at gstdecodebin2.c:1740
#21 0x00007fffa697b655 in pad_added_cb (element=0x7fffb8426d90 [GstCapsFilter], pad=0x7fffb84b4bf0 [GstPad], chain=0x7fffbb644800) at gstdecodebin2.c:2553
#22 0x00007fffa697b9d6 in caps_notify_cb (pad=0x7fffb84b4bf0 [GstPad], unused=<optimized out>, chain=0x7fffbb644800) at gstdecodebin2.c:2669
#26 0x00007fffee9f9e2f in <emit signal notify:caps on instance 0x7fffb84b4bf0 [GstPad]> (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3363
    #23 0x00007fffee9de085 in g_closure_invoke (closure=0x7fffb82643f0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffa4fea050, invocation_hint=invocation_hint@entry=0x7fffa4fe9ff0) at gclosure.c:768
    #24 0x00007fffee9f0d12 in signal_emit_unlocked_R (node=node@entry=0x7ffff6cbe140, detail=detail@entry=1385, instance=instance@entry=0x7fffb84b4bf0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffa4fea050) at gsignal.c:3551
    #25 0x00007fffee9f9bf2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffa4fea1e0) at gsignal.c:3307
#27 0x00007fffee9e2825 in g_object_dispatch_properties_changed (object=0x7fffb8264b00, n_pspecs=0, pspecs=0x7ffff7ecc048) at gobject.c:1053
#28 0x00007fffa7d1f854 in gst_object_dispatch_properties_changed (object=0x7fffb84b4bf0 [GstPad], n_pspecs=1, pspecs=0x7fffa4fea350) at gstobject.c:438
#29 0x00007fffee9e52b9 in g_object_notify_by_pspec (pspec=<optimized out>, object=0x7fffb84b4bf0 [GstPad]) at gobject.c:1146
#30 0x00007fffee9e52b9 in g_object_notify_by_pspec (object=0x7fffb84b4bf0 [GstPad], pspec=<optimized out>) at gobject.c:1256
#31 0x00007fffa7d55013 in store_sticky_event (pad=0x7fffb84b4bf0 [GstPad], event=0x7fffd48f1640) at gstpad.c:4578
#32 0x00007fffa7d5eceb in gst_pad_push_event (pad=0x7fffb84b4bf0 [GstPad], event=0x7fffd48f1640) at gstpad.c:4837
#33 0x00007fffa78c1d12 in gst_base_transform_setcaps (caps=<optimized out>, pad=<optimized out>) at ../../../gst/gstcompat.h:55
#34 0x00007fffa78c1d12 in gst_base_transform_setcaps (trans=0x7fffb8426d90 [GstCapsFilter], pad=0x7fffa9adcc00, incaps=0x0) at gstbasetransform.c:1348
#35 0x00007fffa78c2ced in gst_base_transform_sink_eventfunc (trans=0x7fffb8426d90 [GstCapsFilter], event=0x7fffd48f15e0) at gstbasetransform.c:1860
#36 0x00007fffa7d55d0f in gst_pad_send_event_unchecked (pad=0x7fffb84b49c0 [GstPad], event=0x7fffd48f15e0, type=3091361168) at gstpad.c:5036
#37 0x00007fffa7d565fb in gst_pad_push_event_unchecked (pad=0x7fffb84b4790 [GstPad], event=0x7fffd48f15e0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:4731
#38 0x00007fffa7d56a20 in push_sticky (pad=0x7fffb84b4790 [GstPad], ev=0x7fffa4fea720, user_data=0x7fffa4fea780) at gstpad.c:3370
#39 0x00007fffa7d54bdd in events_foreach (pad=0x7fffb84b4790 [GstPad], func=0x7fffa7d568d0 <push_sticky>, user_data=0x7fffa4fea780) at gstpad.c:530
#40 0x00007fffa7d5ed90 in gst_pad_push_event (event=<optimized out>, pad=<optimized out>) at gstpad.c:3426
#41 0x00007fffa7d5ed90 in gst_pad_push_event (pad=0x7fffb84b4790 [GstPad], event=0x7fffd48f15e0) at gstpad.c:4849
#42 0x00007fffa45d4900 in gst_h264_parse_update_src_caps () at /usr/lib64/gstreamer-1.0/libgstvideoparsersbad.so
#43 0x00007fffa45d705f in gst_h264_parse_set_caps () at /usr/lib64/gstreamer-1.0/libgstvideoparsersbad.so
#44 0x00007fffa78a60fa in gst_base_parse_sink_event_default (parse=0x7fffb824f230 [GstH264Parse], event=0x7fffd48f3860) at gstbaseparse.c:997
#45 0x00007fffa45d2633 in gst_h264_parse_event () at /usr/lib64/gstreamer-1.0/libgstvideoparsersbad.so
#46 0x00007fffa7d55d0f in gst_pad_send_event_unchecked (pad=0x7fffb84b4560 [GstPad], event=0x7fffd48f3860, type=3089429040) at gstpad.c:5036
#47 0x00007fffa7d565fb in gst_pad_push_event_unchecked (pad=0x7fffb84b4330 [GstPad], event=0x7fffd48f3860, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:4731
#48 0x00007fffa7d56a20 in push_sticky (pad=0x7fffb84b4330 [GstPad], ev=0x7fffa4fead00, user_data=0x7fffa4fead60) at gstpad.c:3370
#49 0x00007fffa7d54bdd in events_foreach (pad=0x7fffb84b4330 [GstPad], func=0x7fffa7d568d0 <push_sticky>, user_data=0x7fffa4fead60) at gstpad.c:530
---Type <return> to continue, or q <return> to quit---
#50 0x00007fffa7d5ed90 in gst_pad_push_event (event=<optimized out>, pad=<optimized out>) at gstpad.c:3426
#51 0x00007fffa7d5ed90 in gst_pad_push_event (pad=0x7fffb84b4330 [GstPad], event=0x7fffd48f3860) at gstpad.c:4849
#52 0x00007fffa6090c97 in gst_multi_queue_loop (object=<optimized out>, sq=<optimized out>, mq=<optimized out>) at gstmultiqueue.c:1112
#53 0x00007fffa6090c97 in gst_multi_queue_loop (pad=0x7fffb8264b00) at gstmultiqueue.c:1338
#54 0x00007fffa7d85167 in gst_task_func (task=0x7fffd9b0e290 [GstTask]) at gsttask.c:316
#55 0x00007fffee70a628 in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307
#56 0x00007fffee709c95 in g_thread_proxy (data=0x7fffb845d1e0) at gthread.c:764
#57 0x00007ffff7bc456a in start_thread (arg=0x7fffa4feb700) at pthread_create.c:310
#58 0x00007ffff6ec9dad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

See https://bugzilla.mozilla.org/show_bug.cgi?id=1024125

Thanks for the pointer.

Tried with Fedora 20 GStreamer and with latest master GStreamer packages, I can see va_openDriver() returns -1 but that's ok, it falls back to software rendering without crashing.

*** Bug 1110488 has been marked as a duplicate of this bug. ***

According to a comment in the upstream bug, this is a libva bug fixed by this patch 
http://cgit.freedesktop.org/libva/commit/va/va.c?h=staging&id=d4988142a3f2256e38c5c5cdcdfc1b4f5f3c1ea9

I made a scratch build with this patch, it should be available in few minutes. I built the rpm with the same patch locally and can confirm it fixes this issue.

http://koji.fedoraproject.org/koji/taskinfo?taskID=7062309

@Elad Alfassa
The patch in c#10 is from 2013 but the libva version is more recent than that.
So it was either reverted then or you've failed to apply ? Can you please attach a full patch from the fedora package, so anything can be reviewed. (I cannot grab your scratch build src.rpm)

In either case, can anyone open a bug in libva upstream. 

FYI I will not be able to do any test until next week.

Unrelated but still, I don't understand why gstreamer default to vaapi over vdpau.
Vdpau is backed by FOSS drivers (vaapi only native backend for intel is provided by RPM Fusion)

Created attachment 910855 [details]
Patch for the fedora package

The gstreamer vdpau plugin is not maintained AFAIK, and the vaapi vdpau backend is broken on many devices.

Anyway, the commit I linked to seems to have been made in a "staging" branch upstream and not in master. Reading the libva master branch commit log, it seems that it was never in master. The patch applies cleanly to the most recent master.

I filed a bug against libva upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=80299

The attached patch is what I made the scratch build from (it differs from the scratch build a bit, I added the bug number to the changelog entry and fixed the release tag from 3.1 in the scratch build to 3 in the patch).

For me, it fixes that crash, and the upstream patch looks sensible enough. I'm not sure if it should be applied in Fedora before we get a response from upstream about why it wasn't committed to their master branch.

kwizart: it's only very recently that any F/OSS driver support for VDPAU has shown up, isn't it? It used to be only any use with the proprietary NVIDIA driver. VAAPI you could at least use with entirely F/OSS software (only patent issues).

Is the patch coming to F20(In reply to Elad Alfassa from comment #11)
> I made a scratch build with this patch, it should be available in few
> minutes. I built the rpm with the same patch locally and can confirm it
> fixes this issue.
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=7062309

What about F20? Guess we have to wait for FF31.

(In reply to quickbooks.office from comment #16)
> Is the patch coming to F20(In reply to Elad Alfassa from comment #11)
> > I made a scratch build with this patch, it should be available in few
> > minutes. I built the rpm with the same patch locally and can confirm it
> > fixes this issue.
> > 
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=7062309
> 
> What about F20? Guess we have to wait for FF31.

It's a scratch build to let people test this patch. I could make one for F20 too if you want. FF31 will probably not change anything with regarding to this specific issue as it is a libva bug.

I don't want many people to install this scratch build, to be honest, because if it's a proper solution it should be pushed to the updates repo, and if it isn't it should not be installed by the public.

We haven't heard from upstream regarding this patch and kwizart (the Fedora libva maintainer) did not have a chance to test it yet, so please wait patiently until we figure out if this is the right solution to the crash.

(In reply to Elad Alfassa from comment #17)
> (In reply to quickbooks.office from comment #16)
> > Is the patch coming to F20(In reply to Elad Alfassa from comment #11)
> > > I made a scratch build with this patch, it should be available in few
> > > minutes. I built the rpm with the same patch locally and can confirm it
> > > fixes this issue.
> > > 
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=7062309
> > 
> > What about F20? Guess we have to wait for FF31.
> 
> It's a scratch build to let people test this patch. I could make one for F20
> too if you want. FF31 will probably not change anything with regarding to
> this specific issue as it is a libva bug.
> 
> I don't want many people to install this scratch build, to be honest,
> because if it's a proper solution it should be pushed to the updates repo,
> and if it isn't it should not be installed by the public.
> 
> We haven't heard from upstream regarding this patch and kwizart (the Fedora
> libva maintainer) did not have a chance to test it yet, so please wait
> patiently until we figure out if this is the right solution to the crash.

Sure can you make scratch build on koji for F20.

Right now if I use F20's Firefox it crashes always on https://www.paypal.com or https://www.youtube.com/html5

Another workaround might be to install the "native" vdpau acceleration
(if not done already)
yum install gstreamer1-plugins-bad-free mesa-vdpau-drivers vdpauinfo
This will install libgstvdpau.so (at least in F-20), but I miss the name of the libva gst plugin in case it need to be disabled

@Elad Alfassa  if you can submit a patch on top of libva in F-20. I don't think F-19 is affected at all (since gst might not have libva enabled).

(In reply to Nicolas Chauvet (kwizart) from comment #19)
> Another workaround might be to install the "native" vdpau acceleration
> (if not done already)
> yum install gstreamer1-plugins-bad-free mesa-vdpau-drivers vdpauinfo
> This will install libgstvdpau.so (at least in F-20), but I miss the name of
> the libva gst plugin in case it need to be disabled
> 
> @Elad Alfassa  if you can submit a patch on top of libva in F-20. I don't
> think F-19 is affected at all (since gst might not have libva enabled).

gstreamer1-vaapi isn't built for Fedora 19; I have no plans to do this, either.

*** Bug 1057814 has been marked as a duplicate of this bug. ***

*** Bug 1111777 has been marked as a duplicate of this bug. ***

The same story with libva-1.3.1-2

(In reply to Nicolas Chauvet (kwizart) from comment #19)
> Another workaround might be to install the "native" vdpau acceleration
> (if not done already)
> yum install gstreamer1-plugins-bad-free mesa-vdpau-drivers vdpauinfo
> This will install libgstvdpau.so (at least in F-20), but I miss the name of
> the libva gst plugin in case it need to be disabled
> 

1) There's no gstreamer VDPAU plugin in Rawhide.
2) The mesa vdpau drivers are severely broken, at least on my hardware.

Created attachment 911817 [details]
UNTESTED patch for f20

Here you go, patch for the f20 branch. Note that I did NOT test this. I don't know if it compiles and I don't know if it fixes the crash.

It's on your hands now. For the Rawhide branch, my other patch is tested and works as expected. For f20, you'd have to do the testing yourself.

I've installed fc21 build in fc20 (it is fairly independent package). The patch does not fix the problem for me. As I mentioned in my original bugreport, the SD video playback works OK.

(In reply to Mykola Dvornik from comment #26)
> I've installed fc21 build in fc20 (it is fairly independent package). The
> patch does not fix the problem for me. As I mentioned in my original
> bugreport, the SD video playback works OK.

So maybe it's not the same crash. Just because it crashes on video it doesn't mean it's the exact same crash. Got a backtrace?

have not got backtrace so far. But it does not crash every single time. For me the most probable scenario is when the video playback stops at some point, but the audio continues. It happens for every single HD video with hw accelerated playback. Fore me it crashes only in roughly 2-3 cases out of 10.

(In reply to Mykola Dvornik from comment #28)
> have not got backtrace so far. But it does not crash every single time. For
> me the most probable scenario is when the video playback stops at some
> point, but the audio continues. It happens for every single HD video with hw
> accelerated playback. Fore me it crashes only in roughly 2-3 cases out of 10.

In that case, it's a different crash for which a different bug should be filed.

in fact it has been, see https://bugzilla.redhat.com/show_bug.cgi?id=1111777. End up being marked as a duplicate of this one.

Please get a backtrace, or submit the crash report to mozilla and get the crash ID from the about:crashes page so we can tell for sure. The symptoms are different, so I don't think it's the same crash.

Another user experienced a similar problem:

started the firefox password store. flash-plugin stopped working a few days before.

reporter:       libreport-2.2.2
backtrace_rating: 3
cmdline:        /usr/lib64/firefox/plugin-container /usr/lib64/flash-plugin/libflashplayer.so -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 3387 true plugin
crash_function: mozalloc_abort
executable:     /usr/lib64/firefox/plugin-container
kernel:         3.14.7-200.fc20.x86_64
package:        firefox-30.0-4.fc20
reason:         plugin-container killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

Created attachment 911843 [details]
File: backtrace

(In reply to David Kaufmann from comment #33)
> Created attachment 911843 [details]
> File: backtrace

> Core was generated by `/usr/lib64/firefox/plugin-container /usr/lib64/flash-plugin/libflashplayer.so -'.

Implies that this was the flash process crashing, and not likely related to this crash. If the browser also crashed at this time, it's definitely worth filing a bug, but the crash report/stack from the browser process would be needed.

Also, where are these crash-reporter-disabled firefox builds coming from? Ideally, they would be built with crash reporter and symbols pushed to us, which would allow the crashes to show up in about:crashes

Old Firefox builds in Fedora used to be built without a crash reporter, but it's not the case anymore. Right now, it seems, both ABRT (the Fedora crash reporting app) and the Mozilla crash reporter will report each crash.

Interestingly Firefox itself crashed (reproduceable, at least three times) on opening the Password-Manager-Dialog. Flash-player itself did crash on every video since a few days, but i didn't care because I use a different browser to watch videos.
I use tabs quite heavily (~180 open tabs at all times, automatically reopen last pages on firefox start) so there probably have been a few crashed flash-plugin-instances in the background already. Opening the Password-Manager-Dialog seems to have propagated these plugin-crashes to the Main process and consequently the Firefox-process crashed.

(In reply to David Kaufmann from comment #36)
> Interestingly Firefox itself crashed (reproduceable, at least three times)
> on opening the Password-Manager-Dialog. Flash-player itself did crash on
> every video since a few days, but i didn't care because I use a different
> browser to watch videos.
> I use tabs quite heavily (~180 open tabs at all times, automatically reopen
> last pages on firefox start) so there probably have been a few crashed
> flash-plugin-instances in the background already. Opening the
> Password-Manager-Dialog seems to have propagated these plugin-crashes to the
> Main process and consequently the Firefox-process crashed.

I'm sorry, but this is completely unrelated to this bug. Please file a different bug.

This bug is not a generic "firefox just crashed" bug, it's a very specific bug on a very specific crash that happens with a very specific subset of video drivers.

I don't reproduce on F-20 i686 with pinetrail intel adapter (so no vaapi backend)
And gstream1-vaapi is installed;
-----------------------------
libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i915_drv_video.so
libva info: va_openDriver() returns -1
libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i915_drv_video.so
libva info: va_openDriver() returns -1
libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns 1
libva error: va_getDriverName() failed with operation failed,driver_name=i965
-----------------------------
Which mean libva properly fails

@Eled,
Are you sure that you were previously using libva from our repository ?
Can you still reproduce the crash with the "previous" libva just to be sure something else could have fixed the issue in your case ?

Still no input from libva upstream...

Try on Rawhide. I don't know weather or not this bug affects F20 as I don't use F20 on hardware which doesn't have libva.

And of course I'm sure I was using libva from Fedora repositories. I just downgraded now to prove a point and it indeed crashes. Installed the patched version again and it doesn't crash.

Note that libva on F20 seems to be a different version than libva on Rawhide, so it might only affect the Rawhide version. Again let me emphasize that this is a *rawhide* bug, not a F20 bug.

I don't know if it affects F20, or how it affects F20, or if this patch is right for F20, but it IS right for Rawhide.

(In reply to Elad Alfassa from comment #39)
> Try on Rawhide. I don't know weather or not this bug affects F20 as I don't
> use F20 on hardware which doesn't have libva.
Ok, so as I won't have time to reproduce on rawhide anytime soon, I'm applying the patch for now.
But I hope to have an answear from upstream about this. (or the patch to be merged back into the next libva)

Thx for the patch and patience on this report.
Hopefully this will fix for all gstreamer1-vaapi users without an intel adapter.

The bug that got marked duplicate of this one was for F20. I still see this bug on F20 as well. Should I open a separate bug report? (Crashes from abrt get redirected here).

I am using nouveau, BTW.

FWIW, I'm using nouveau on Rawhide and my Firefox is definitely a hell of a lot crashier than it used to be. Haven't caught a trace to double check it's this problem, but it wouldn't surprise me.

(In reply to Elad Alfassa from comment #31)
> Please get a backtrace, or submit the crash report to mozilla and get the
> crash ID from the about:crashes page so we can tell for sure. The symptoms
> are different, so I don't think it's the same crash.

https://crash-stats.mozilla.com/report/index/7a6f8107-7ee8-402f-9a63-6c4e42140626

>Hopefully this will fix for all gstreamer1-vaapi users without an intel adapter. 
So please state the following:
- Do you have installed or is the gstreamer1-vaapi (or gstreamer-vaapi) was installed by default on your system ?
- Which libva version release is there ? (output of rpm -q libva)
- Which gpu hardware do you have ? (This bug in only when the appropriate vaapi backend is missing).

- gstreamer1-vaapi-0.5.9-0.1
- libva-1.3.0-20
- intel gpu (SB)

(In reply to Mykola Dvornik from comment #45)
> - gstreamer1-vaapi-0.5.9-0.1
> - libva-1.3.0-20
This libva version isn't provided by us on F-20 (but a newer version is available in F-21) also the bug originally described is when you don't have a vaapi backend whereas you might actually have one for your device. So this is clearly a separate issue.
Can you report it into bugzilla.freedesktop.org directly ?

Another user experienced a similar problem:

I was installing gnome-extensions then I saw crashed message but still firefox was working.. 

reporter:       libreport-2.2.2
backtrace_rating: 4
cmdline:        /usr/lib64/firefox/plugin-container /usr/lib64/mozilla/plugins/libgnome-shell-browser-plugin.so -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 1256 true plugin
crash_function: mozalloc_abort
executable:     /usr/lib64/firefox/plugin-container
kernel:         3.14.8-200.fc20.x86_64
package:        firefox-30.0-4.fc20
reason:         plugin-container killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

Created attachment 912589 [details]
File: backtrace

I have this problem on F20 and this is my libva version:
ame        : libva
Arch        : x86_64
Version     : 1.2.1
Release     : 2.fc20
Size        : 176 k
Repo        : installed
From repo   : fedora
Summary     : Video Acceleration (VA) API for Linux
URL         : http://freedesktop.org/wiki/Software/vaapi
License     : MIT
Description : Libva is a library providing the VA API video acceleration API.

(In reply to Elad Alfassa from comment #25)
> Created attachment 911817 [details]
> UNTESTED patch for f20
> 
> Here you go, patch for the f20 branch. Note that I did NOT test this. I
> don't know if it compiles and I don't know if it fixes the crash.
> 
> It's on your hands now. For the Rawhide branch, my other patch is tested and
> works as expected. For f20, you'd have to do the testing yourself.

I don't see it for F20: https://koji.fedoraproject.org/koji/packageinfo?packageID=11490

Do I need some special privileges on Koji to create a build for F20?

This package should fix Fedora 20 users using firefox 30 with no libva backend but with gstreamer1-libva installed:

If you are not in this case, please submit another bug or unlink your initial report from this one.

If you are in this case, please state if the following build fix for your case in fedora 20:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7091920
This is the package that is planned to be submited for update.

Thx

libva-1.2.1-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libva-1.2.1-3.fc20

Another user experienced a similar problem:

left pc running with X, xfce-terminal(x3), deluge-gtk, and Firefox
upon return Firefox wouldn't respond and seemed to have taken over the desktop as nothing else would respond
I was able to launch a new terminal and killed Firefox with xkill

reporter:       libreport-2.2.2
backtrace_rating: 4
cmdline:        /usr/lib64/firefox/plugin-container /opt/google/talkplugin/libnpgoogletalk.so -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 2651 true plugin
crash_function: mozalloc_abort
executable:     /usr/lib64/firefox/plugin-container
kernel:         3.14.8-200.fc20.x86_64
package:        firefox-30.0-4.fc20
reason:         plugin-container killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

Package libva-1.2.1-3.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libva-1.2.1-3.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-7946/libva-1.2.1-3.fc20
then log in and leave karma (feedback).

Another user experienced a similar problem:

Operating program normally. I'm not a geek so I've no idea. 

reporter:       libreport-2.2.2
backtrace_rating: 3
cmdline:        /usr/lib64/firefox/plugin-container /usr/lib64/flash-plugin/libflashplayer.so -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 5379 true plugin
crash_function: mozalloc_abort
executable:     /usr/lib64/firefox/plugin-container
kernel:         3.14.7-200.fc20.x86_64
package:        firefox-30.0-4.fc20
reason:         plugin-container killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

libva-1.2.1-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

I'm still getting this crash, says it's a dup of this bug.  I'm running the mentioned version of libva:

$ rpm -qa |grep libva
libva-1.2.1-3.fc20.x86_64

(In reply to Jason Herring from comment #57)
> I'm still getting this crash, says it's a dup of this bug.  I'm running the
> mentioned version of libva:
> 
> $ rpm -qa |grep libva
> libva-1.2.1-3.fc20.x86_64

It crashes for me too.

Best to update gstreamer to 1.4.x in F20 (the same gstreamer version that is in F21)

(In reply to quickbooks.office from comment #58)
> (In reply to Jason Herring from comment #57)
> > I'm still getting this crash, says it's a dup of this bug.  I'm running the
> > mentioned version of libva:
> > 
> > $ rpm -qa |grep libva
> > libva-1.2.1-3.fc20.x86_64
> 
> It crashes for me too.
> 
> Best to update gstreamer to 1.4.x in F20 (the same gstreamer version that is
> in F21)

That would be against our updates policy as it might break the world. If it does crash on F20 then backporting whatever fixed it in 1.4.x would be a better idea.

(In reply to Elad Alfassa from comment #59)
> (In reply to quickbooks.office from comment #58)
> > (In reply to Jason Herring from comment #57)
> > > I'm still getting this crash, says it's a dup of this bug.  I'm running the
> > > mentioned version of libva:
> > > 
> > > $ rpm -qa |grep libva
> > > libva-1.2.1-3.fc20.x86_64
> > 
> > It crashes for me too.
> > 
> > Best to update gstreamer to 1.4.x in F20 (the same gstreamer version that is
> > in F21)
> 
> That would be against our updates policy as it might break the world. If it
> does crash on F20 then backporting whatever fixed it in 1.4.x would be a
> better idea.

Here is the crash I am getting:

[test@h ~]$ firefox

(process:14598): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(firefox:14598): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(firefox:14598): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(firefox:14598): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(firefox:14598): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
p11-kit: 'node != NULL' not true at lookup_extension
p11-kit: 'node != NULL' not true at lookup_extension
p11-kit: 'node != NULL' not true at lookup_extension
p11-kit: 'node != NULL' not true at lookup_extension
p11-kit: 'node != NULL' not true at lookup_extension
p11-kit: 'node != NULL' not true at lookup_extension
p11-kit: 'node != NULL' not true at lookup_extension
p11-kit: 'node != NULL' not true at lookup_extension
DtsGetHWFeatures: Create File Failed
DtsGetHWFeatures: Create File Failed
Running DIL (3.22.0) Version
DtsDeviceOpen: Opening HW in mode 0
DtsDeviceOpen: Create File Failed
libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_0_34
libva info: va_openDriver() returns 0
Segmentation fault (core dumped)
[test@h ~]$ 

https://retrace.fedoraproject.org/faf/reports/bthash/3ff62dc85e395b8d5513f432b5a05b498cbb1115

Abrt does not let me report to Redhat's Bugzilla.

about:crashes does not show any crashes (not caught by Firefox' crash reporter).

Attaching backtrace.

Created attachment 932561 [details]
backtrace

Another user experienced a similar problem:

My foedoar box is giving weird problems after upgrade of systemd.
Also many services are not running, which I have to start manually and system start up and shut down is taking a lot of time.

reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        /usr/lib/firefox/plugin-container /usr/lib/flash-plugin/libflashplayer.so -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 7536 true plugin
crash_function: mozalloc_abort
executable:     /usr/lib/firefox/plugin-container
kernel:         3.15.8-200.fc20.i686+PAE
package:        firefox-31.0-2.fc20
reason:         plugin-container killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

(In reply to quickbooks.office from comment #61)
> Created attachment 932561 [details]
> backtrace

this backtrace has been generated with libvdpau_nvidia.so loaded. This file comes from the nvidia binary driver and is not in Fedora. I suggest you report this issue to nvidia.

This specific issue has been fixed on Fedora 21 and Rawhide for the cases against which it has been originally reported. If you have a different crash, report a different bug.