This must be an issue in qt5-qtwebengine-freeworld (i.e., really an RPM Fusion issue, but since I am the maintainer of qt5-qtwebengine-freeworld there anyway, it doesn't matter much). The thing is, F28 ships with FFmpeg 3.5, which is not supported by QtWebEngine yet. I backported the changes to make it build from Chromium master, but it looks like I missed something to also make it work at runtime.

Unfortunately, your backtrace is very sparse in information. Installing qt5-qtwebengine-freeworld-debuginfo might help (but it is pretty huge).

Just to clarify:
> F28 ships with FFmpeg 3.5
RPM Fusion for F28 ships with FFmpeg 3.5. Fedora itself does not ship FFmpeg.

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

I'm installing the debuginfo package from rpmfusion now. Is there anything else I should do to get more information for you, Kevin? (Qutebrowser has some sort of debug mode I think, to increase logging I think, so I'll try that).

Got this from falkon after installing debuginfo for both qtwebengine-freeworld, and falkon. It doesn't look any different, I'm afraid:

Apr 05 17:17:30 ankur.pc org.kde.falkon.desktop[4884]: Falkon: 1 extensions loaded
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: Received signal 11 SEGV_MAPERR 000000000000
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #0 0x7fb42d2b4b46 <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #1 0x7fb42d2b44b9 <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #2 0x7fb42d2b4acc <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #3 0x7fb429fcbfb0 <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #4 0x7fb420580fc4 av_buffer_get_opaque
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #5 0x7fb42c1051ab <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #6 0x7fb42c1052dc <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #7 0x7fb42c105751 <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #8 0x7fb42c0d48ca <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #9 0x7fb42c0d8422 <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #10 0x7fb42c0d8b44 <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #11 0x7fb42c0c7c65 <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #12 0x7fb42d335d0b <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #13 0x7fb42d2d08c0 <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #14 0x7fb42d2d0b3d <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #15 0x7fb42d2d1dee <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #16 0x7fb42d2d30a1 <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #17 0x7fb42d2f062d <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #18 0x7fb42d30adbf <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #19 0x7fb42d30649b <unknown>
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #20 0x7fb429fc1564 start_thread
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: #21 0x7fb4293b731f __GI___clone
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]:   r8: 00007fb3c8015660  r9: 0000000000000007 r10: 000000000000ac44 r11: 000000000000ac44
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]:  r12: 00007fb3c800a918 r13: 0000000000000000 r14: 00007fb3d9779e20 r15: 00007fb3d9779e10
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]:   di: 0000000000000000  si: 0000000000000002  bp: 0000000000000273  bx: 00007fb3c8007b70
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]:   dx: 0000000000000002  ax: 00007fb3c8008ec0  cx: 0000000000000006  sp: 00007fb3d9779dc8
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]:   ip: 00007fb420580fc4 efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000004
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]:  trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000000
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: [end of stack trace]
Apr 05 17:17:35 ankur.pc org.kde.falkon.desktop[4884]: Calling _exit(1). Core file will not be generated.

If you can manage to attach GDB to the renderer process (one of the "/usr/lib64/qt5/libexec/QtWebEngineProcess --type=renderer …" processes) with "gdb --pid …" before it crashes, that should give you a better backtrace.

GDB will complain about attaching to a sandboxed process from outside the sandbox, but last I tried it, it did not cause problems and I got a valid backtrace.

OK. I tried it. Does this look any good? That's all I could get it to say.

#0  0x00007f84b79aa8e8 in futex_reltimed_wait_cancelable (private=0, reltime=0x7ffddad53650, expected=0, futex_word=0x7ffddad537e8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:142
        __ret = -516
        oldtype = 0
        err = <optimized out>
        rt = Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7ffddad53650: 
#1  0x00007f84b79aa8e8 in __pthread_cond_wait_common (abstime=0x7ffddad536f0, mutex=0x7ffddad53798, cond=0x7ffddad537c0) at pthread_cond_wait.c:533
        rt = Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7ffddad53650: 
#2  0x00007f84b79aa8e8 in __pthread_cond_timedwait (cond=0x7ffddad537c0, mutex=0x7ffddad53798, abstime=0x7ffddad536f0) at pthread_cond_wait.c:667
#3  0x00007f84bad1e812 in base::ConditionVariable::TimedWait(base::TimeDelta const&) ()
    at ../../../../src/3rdparty/chromium/base/synchronization/condition_variable_posix.cc:117

You have either the wrong thread (try "thread apply all bt") or the wrong process altogether. This thread is just waiting.

Created attachment 1417970 [details]
Complete backtrace (hopefully)

Yeh, you're right. I wasn't getting the right process, since it would change PIDs the moment I hit "Go". I think I got it this time, though.

This is how I did it, and this is the text leading up to the bt in gdb. I only had the one tab in falkon running, so this was the only process:

(ins)[asinha@ankur  ~]$ gdb --pid $(pgrep -f -- "--type=render")
GNU gdb (GDB) Fedora 8.1-11.fc28
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 7932
[New LWP 7933]
[New LWP 7934]
[New LWP 7935]
[New LWP 7936]
[New LWP 7937]
[New LWP 7938]
[New LWP 7939]
[New LWP 7940]
[New LWP 7941]
[New LWP 7942]
[New LWP 7959]
[New LWP 7961]
[New LWP 7976]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /lib64/libavcodec.so.58
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/17/5dfa8fedace69f85ce57c94772292425591f9f.debug
Missing separate debuginfo for /lib64/libavformat.so.58
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/fa/d281bf360a2cfc8952c23ee3cc55c3829ef1a3.debug
Missing separate debuginfo for /lib64/libavutil.so.56
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/bb/5151d93284ad344204849279d82659da820ba2.debug

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments
Missing separate debuginfo for /lib64/libswresample.so.3
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/19/9bedd2be7b82dca65e0647602ba2ce32182eac.debug

warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable.  Connect to gdbserver inside the container.
futex_wait_cancelable (private=0, expected=0, futex_word=0x7ffd5ac68ff8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
88        int err = lll_futex_timed_wait (futex_word, expected, NULL, private);
Missing separate debuginfos, use: dnf debuginfo-install libidn2-2.0.4-6.fc28.x86_64 ocl-icd-2.2.12-1.fc28.x86_64 openssl-libs-1.1.0h-3.fc28.x86_64 pcre-8.42-1.fc28.x86_64 pcre2-10.31-4.fc28.x86_64 pcre2-utf16-10.31-4.fc28.x86_64 qt5-qtdeclarative-5.10.1-5.fc28.x86_64
(ins)(gdb) set logging file backtrace.log
(ins)(gdb) set logging on
Copying output to backtrace.log.
(ins)(gdb) thread apply all bt full


Is that OK? Cheers!

No, you're taking the backtrace as soon as you attached to the process instead of letting it crash.

You need to continue ("c" or "continue" command in GDB) and trigger the crash from the browser UI, then GDB should intercept the crash, and there you can then run "thread apply all bt".

Created attachment 1418024 [details]
New backtrace

Ah! Of course! *facepalm*. Is this any better? I hit "continue" until it segfaulted (line 19), then got the bt this time.

Yes, finally a usable backtrace, thanks a lot!

This is the relevant part:

Thread 14 (Thread 0x7f04edcbb700 (LWP 24598)):
#0  0x00007f052ff73fc4 in av_buffer_get_opaque () at /lib64/libavutil.so.56
#1  0x00007f053baf81ab in media::FFmpegAudioDecoder::FFmpegDecode(scoped_refptr<media::DecoderBuffer> const&, bool*) ()
    at ../../../../src/3rdparty/chromium/media/filters/ffmpeg_audio_decoder.cc:277
#2  0x00007f053baf82dc in media::FFmpegAudioDecoder::DecodeBuffer(scoped_refptr<media::DecoderBuffer> const&, base::Callback<void (media::DecodeStatus), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&) ()
    at ../../../../src/3rdparty/chromium/media/filters/ffmpeg_audio_decoder.cc:156
#3  0x00007f053baf8751 in media::FFmpegAudioDecoder::Decode(scoped_refptr<media::DecoderBuffer> const&, base::Callback<void (media::DecodeStatus), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&) ()
    at ../../../../src/3rdparty/chromium/media/filters/ffmpeg_audio_decoder.cc:124
#4  0x00007f053bac78ca in media::DecoderStream<(media::DemuxerStream::Type)1>::DecodeInternal(scoped_refptr<media::DecoderBuffer> const&) ()
    at ../../../../src/3rdparty/chromium/media/filters/decoder_stream.cc:397
#5  0x00007f053bacb422 in media::DecoderStream<(media::DemuxerStream::Type)1>::Decode(scoped_refptr<media::DecoderBuffer> const&) ()
    at ../../../../src/3rdparty/chromium/media/filters/decoder_stream.cc:369
#6  0x00007f053bacbb44 in media::DecoderStream<(media::DemuxerStream::Type)1>::OnBufferReady(media::DemuxerStream::Status, scoped_refptr<media::DecoderBuffer> const&) () at ../../../../src/3rdparty/chromium/media/filters/decoder_stream.cc:676
#7  0x00007f053babac65 in base::Callback<void (media::DemuxerStream::Status, scoped_refptr<media::DecoderBuffer> const&), (base::internal::CopyMode)1, (base::internal::RepeatMode)1>::Run(media::DemuxerStream::Status, scoped_refptr<media::DecoderBuffer> const&) && () at ../../../../src/3rdparty/chromium/base/callback.h:91
…

Hmmm, one more thing actually: Can you try with ffmpeg-debuginfo installed too? Then we would know where exactly in av_buffer_get_opaque it crashes, which might be a more precise indication what's going wrong.

(In reply to Kevin Kofler from comment #14)
> Hmmm, one more thing actually: Can you try with ffmpeg-debuginfo installed
> too? Then we would know where exactly in av_buffer_get_opaque it crashes,
> which might be a more precise indication what's going wrong.

I think I had the debuginfo installed already. I'll re-do it again when I get home in the evening. I don't have access to the F28 machine from here. :/

> I think I had the debuginfo installed already.

The backtrace looks as if only qt5-qtwebengine-freeworld-debuginfo was installed, but not ffmpeg-debuginfo.

> I'll re-do it again when I get home in the evening. I don't have access to the 
> F28 machine from here. :/

Thanks.

Created attachment 1418261 [details]
new backtrace, confirming that ffmpeg-debuginfo is installed

rpm -q ffmpeg{,-debuginfo}}
ffmpeg-3.5-0.6.20180305git.fc28.x86_64
ffmpeg-debuginfo-3.5-0.6.20180305git.fc28.x86_64

ffmpeg 4.0 has just appeared in testing repo - does this help or hinder this bug at all?

To be honest: I have no idea.

Hi,

I've rebuilt qt5-qtwebengine-freeworld against ffmpeg 4 with this patch from archlinux: https://git.archlinux.org/svntogit/packages.git/tree/trunk/qtwebengine-ffmpeg4.patch?h=packages/qt5-webengine

Playing youtube videos with qutebrowser and falkon doesn't crash anymore.

Thanks for the working patch (I'll also compare how it differs from my non-working one), I'm going to do builds with this ASAP.

This is interesting: the patch Arch Linux is using is a subset of mine. The main difference is that the patch I was using removes the "codec_context_->refcounted_frames = 1;" lines, which upstream Chromium removed when they did the port to FFmpeg 3.5/4.0, but Arch Linux keeps those lines. I guess they are still needed after all.

I'm trying to submit builds, but "rfpkg build" is hanging for some reason.

After renewing the RPM Fusion certificates as per the instructions on the mailing list, I was able to submit a build for Rawhide:
http://koji.rpmfusion.org/koji/taskinfo?taskID=227027

I will do a build for F28 once I have it building in Rawhide.

Sorry that this is going to take a while, but building this package is always very time-consuming (in wallclock time; my task is mostly just to wait).

New attempt with fixed paths in the patch:
http://koji.rpmfusion.org/koji/taskinfo?taskID=227034

The Rawhide build fails with an unrelated error on i686:

In file included from ../../../../src/3rdparty/chromium/mojo/public/c/system/buffer.h:14,
                 from ../../../../src/3rdparty/chromium/mojo/public/c/system/core.h:12,
                 from ../../../../src/3rdparty/chromium/mojo/public/c/system/thunks.h:13,
                 from ../../../../src/3rdparty/chromium/mojo/public/c/system/thunks.cc:5:
../../../../src/3rdparty/chromium/mojo/public/c/system/buffer.h:38:42: error: static assertion failed: int64_t has weird alignment
 MOJO_STATIC_ASSERT(MOJO_ALIGNOF(int64_t) == 8, "int64_t has weird alignment");
../../../../src/3rdparty/chromium/mojo/public/c/system/macros.h:15:53: note: in definition of macro 'MOJO_STATIC_ASSERT'
 #define MOJO_STATIC_ASSERT(expr, msg) static_assert(expr, msg)
                                                     ^~~~

It looks like GCC changed the alignment of int64_t on i686 and Chromium does not like that.

I am trying to build F28 first for now:
http://koji.rpmfusion.org/koji/taskinfo?taskID=227041

For Rawhide, it looks like I'll need this to fix the FTBFS:
https://src.fedoraproject.org/cgit/rpms/chromium.git/tree/chromium-66.0.3359.170-gcc8-alignof.patch

F28 also fails with the same error. Don't you love it when they change GCC on you AFTER the mass rebuild?

New Rawhide build attempt: http://koji.rpmfusion.org/koji/taskinfo?taskID=227048

This built, so now building for F28:
http://koji.rpmfusion.org/koji/taskinfo?taskID=227080
(This will take a few hours, too.)

Please report whether this works any better for you or not.

The F28 build is done now: http://koji.rpmfusion.org/koji/buildinfo?buildID=7578

Does that work any better?

Hi Kevin,

It seems to work! web.whatsapp.com no longer crashes for me, and videos + gifs on facebook + twitter etc play just fine!

qt5-qtwebengine-freeworld-5.10.1-5.fc28.x86_64
qutebrowser-1.3.0-1.fc28.noarch


Thanks much!

Just tested youtube and gifv on reddit. it all seems fine (CPU usage was a tad high, but I think that is down to lack of hardware acceleration in qtwebengine)

This is back after the latest qt5-qtwebengine update:

$ rpm -q qt5-qtwebengine
qt5-qtwebengine-5.11.1-4.fc28.x86_64
$ rpm -q qt5-qtwebengine-freeworld
qt5-qtwebengine-freeworld-5.11.1-1.fc28.x86_64

Ah, hrm, no---a reinstall fixed it somehow. Sorry for the noise :/

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Reportedly fixed by an update.