The following 2 crashes occurred while browsing with Epiphany ( Gnome web ). There was a "Web process was crashed" message in Epiphany terminal, and a matching segfault line in "dmesg" output as below: Crash instance 1: Jan 13 09:36:35 unstable kernel: [68395.962630] WebKitWebProces[86384]: segfault at 0 ip 00007f6815ccc024 sp 00007fffec30dd50 error 4 in libwebkit2gtk-4.0.so.37.39.3[7f6815124000+2d43000] Jan 13 09:36:36 unstable kernel: [68395.962643] Code: 00 0f 84 7f 0d 00 00 49 8d 7e 08 e8 f6 3e 16 01 48 8d 35 6d 54 91 01 48 89 c7 e8 d7 b9 9d ff 48 8b 6b 38 0f b6 c0 89 44 24 14 <48> 8b 45 00 48 8b 40 10 48 89 44 24 08 49 8b 46 08 48 89 44 24 30 Crash instance 2: Jan 13 10:52:18 unstable kernel: [72938.450784] WebKitWebProces[95160]: segfault at 0 ip 00007f2ec4a87024 sp 00007ffe05d45a20 error 4 in libwebkit2gtk-4.0.so.37.39.3[7f2ec3edf000+2d43000] Jan 13 10:52:18 unstable kernel: [72938.450812] Code: 00 0f 84 7f 0d 00 00 49 8d 7e 08 e8 f6 3e 16 01 48 8d 35 6d 54 91 01 48 89 c7 e8 d7 b9 9d ff 48 8b 6b 38 0f b6 c0 89 44 24 14 <48> 8b 45 00 48 8b 40 10 48 89 44 24 08 49 8b 46 08 48 89 44 24 30
Both crashes are at the same spot in code sid@unstable:~/source/git/epiphany/build/src$ gdb ./epiphany $(pgrep epiphany) (gdb) info share From To Syms Read Shared Object Library 0x00007f0930f6ec70 0x00007f0932e8da7e Yes /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 (gdb) find /b 0x00007f0930f6ec70, 0x00007f0932e8da7e, 0x48, 0x8b, 0x45, 0x00, 0x48, 0x8b, 0x40, 0x10, 0x48, 0x89, 0x44, 0x24, 0x08, 0x49, 0x8b, 0x46, 0x08, 0x48, 0x89, 0x44, 0x24, 0x30, 0x7f093157f024 <<lambda()>::operator()(void) const+100> 1 pattern found. (gdb) info symbol 0x7f093157f024 webKitWebSrcMakeRequest(_GstBaseSrc*, bool)::{lambda()#1}::operator()() const + 100 in section .text of /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 (gdb) disassemble /r 0x7f093157f024,+10 Dump of assembler code from 0x7f093157f024 to 0x7f093157f02e: 0x00007f093157f024 <<lambda()>::operator()(void) const+100>: 48 8b 45 00 mov 0x0(%rbp),%rax <-------------------------------- 0x00007f093157f028 <<lambda()>::operator()(void) const+104>: 48 8b 40 10 mov 0x10(%rax),%rax 0x00007f093157f02c <<lambda()>::operator()(void) const+108>: 48 89 44 24 08 mov %rax,0x8(%rsp) End of assembler dump 0x0(%rbp) - NULL Pointer deference for the first member of the structure. There was no crash dump ( core file ). So, no backtrace. I am not sure why I don't get core dumps for WebKitWebProcess, though I've configured to capture all crashes which happen in the system. I've a lot of core files from other processes, but not from WebKitWebProcess. Ideas welcome !
It looks like this is happening when sending MainThreadSourceNotification::Start from the create() request. I can only imagine that between the time we perform a context check for priv->player at the start of webKitWebSrcMakeRequest, and the time our Start request runs on the main thread, that the player has been destroyed and the segfault occurs creating a resource loader in the !priv->loader condition (priv->player potentially being NULL). Speculative fix would be to guard on the existence of the player too in this condition. I'm going to guess this was happening whilst watching adaptive streams. There's some history to that. https://bugs.webkit.org/show_bug.cgi?id=144040 https://bugs.webkit.org/show_bug.cgi?id=159089 Perhaps these fixes don't fully protect us in the cases triggered here.
Since this bug was opened https://bugs.webkit.org/show_bug.cgi?id=210284 has been landed, which introduced many stability improvements on callbacks like this, therefore I'm closing the bug. I will note that the `player` field is guaranteed to be set to != nullptr before this callback is set. Therefore (and since it's a plain old pointer), if MediaPlayer was destroyed, it would still not be NULL, it would be a dangling pointer. But a dangling pointer access to `player` should not happen in the new code base because: 1) WebKitWebSrc is part of the GStreamer pipeline which is owned by MediaPlayerPrivateGStreamer. Tearing this pipeline down includes stopping the WebKitWebSrc streaming thread AND atomically cancelling callbacks using it (by taking the DataMutex lock and increasing the requestNumber, see webKitWebSrcStop() and webKitWebSrcUnLock()). 2) In order to access `player` from a callback in the new code base, the DataMutex has to be locked. Then the requestNumber is checked to make sure the task is still relevant, exiting early otherwise. All usages of `player` in the current codebase are done while this mutex is locked. Of course, if despite this analysis you end up finding a similar crash in a version of WebKit that includes the aforementioned commit, please post it in a new bug for investigation. *** This bug has been marked as a duplicate of bug 210284 ***