Description of problem: tried to show web page Version-Release number of selected component: webkitgtk4-2.7.1-5.fc22 Additional info: reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: /usr/libexec/webkit2gtk-4.0/WebKitWebProcess 18 crash_function: llint_entry executable: /usr/libexec/webkit2gtk-4.0/WebKitWebProcess kernel: 3.18.0-0.rc5.git0.2.fc22.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 llint_entry at /lib64/libjavascriptcoregtk-4.0.so.18 #3 vmEntryToJavaScript at /lib64/libjavascriptcoregtk-4.0.so.18 #4 JSC::JITCode::execute at /usr/src/debug/webkitgtk-2.7.1/Source/JavaScriptCore/jit/JITCode.cpp:77 #5 JSC::Interpreter::execute at /usr/src/debug/webkitgtk-2.7.1/Source/JavaScriptCore/interpreter/Interpreter.cpp:914 #6 JSC::evaluate at /usr/src/debug/webkitgtk-2.7.1/Source/JavaScriptCore/runtime/Completion.cpp:82 #7 evaluate at /usr/src/debug/webkitgtk-2.7.1/Source/WebCore/bindings/js/JSMainThreadExecState.h:62 #8 WebCore::ScriptController::evaluateInWorld at /usr/src/debug/webkitgtk-2.7.1/Source/WebCore/bindings/js/ScriptController.cpp:152 #9 WebCore::ScriptController::evaluate at /usr/src/debug/webkitgtk-2.7.1/Source/WebCore/bindings/js/ScriptController.cpp:168 #10 WebCore::ScriptElement::executeScript at /usr/src/debug/webkitgtk-2.7.1/Source/WebCore/dom/ScriptElement.cpp:301 #11 WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent at /usr/src/debug/webkitgtk-2.7.1/Source/WebCore/html/parser/HTMLScriptRunner.cpp:144
Created attachment 960167 [details] File: backtrace
Created attachment 960168 [details] File: cgroup
Created attachment 960169 [details] File: core_backtrace
Created attachment 960170 [details] File: dso_list
Created attachment 960171 [details] File: environ
Created attachment 960172 [details] File: exploitable
Created attachment 960173 [details] File: limits
Created attachment 960174 [details] File: maps
Created attachment 960175 [details] File: open_fds
Created attachment 960176 [details] File: proc_pid_status
Created attachment 960177 [details] File: var_log_messages
Crash occurs when opening http://www.google.de in epiphany. Installed packages: - epiphany-3.15.1-1.fc22 - webkitgtk4-2.7.2-3.fc22
This crash actually occurs when trying to load just about *any* page in Epiphany at all (nirik says it's any page with Javascript) on current Rawhide, and has done for several weeks. Epiphany is entirely unusable on Rawhide (F22).
So, here's the deal. I cannot reproduce this on Fedora 21 with my development copies of WebKitGTK+ and Epiphany. So something else in the stack must have changed. I've tried several ways to install rawhide on a VM, but the farthest I've come is GNOME's "Oh no! Something has gone wrong" screen. I got rawhide installed on a laptop but I can't get an Internet connection for some reason, so no way to download Epiphany let alone test it. As a last ditch attempt I am going to try to install GNOME:Factory from openSUSE on the laptop (I also failed to install that on a VM) and see if I can reproduce there, but if not then we're stuck for now. If someone can get a good backtrace by compiling WebKit manually with -DCMAKE_BUILD_TYPE=Debug then we can report upstream.
"I've tried several ways to install rawhide on a VM, but the farthest I've come is GNOME's "Oh no! Something has gone wrong" screen." That'll be https://bugzilla.redhat.com/show_bug.cgi?id=1185811 ; I backported the mutter patch that should fix it yesterday, so the next successful nightly should not have that bug any more. "I got rawhide installed on a laptop but I can't get an Internet connection for some reason" That could be https://bugzilla.redhat.com/show_bug.cgi?id=1185195 ; try setenforce Permissive (and restart NM).
> That could be https://bugzilla.redhat.com/show_bug.cgi?id=1185195 ; try > setenforce Permissive (and restart NM). Probably not. setroubleshoot does not complain about anything. And unfortunately the same bug (or another bug with identical symptoms) was introduced when I upgraded my laptop from openSUSE 13.1 to GNOME:Next. No selinux there. Anyway, not related to this bug. (In reply to Adam Williamson (Red Hat) from comment #15) > That'll be https://bugzilla.redhat.com/show_bug.cgi?id=1185811 ; I > backported the mutter patch that should fix it yesterday, so the next > successful nightly should not have that bug any more. OK, I will try again the next time I notice a successful nightly.
well, that bug is definitely breaking networking in current Rawhide on clean systems, it's pretty well known. I built an ISO from 02-03 Rawhide plus the qemu and libvirt rebuilds necessary to avoid dep issues; it works fine when booted with enforcing=0 , no network when booted without it. I'll send you that ISO if tonight's nightly fails somehow, but it should be OK I think.
Small update: I can reproduce this on a rawhide VM when I build the Fedora RPM, but I can't reproduce with a debug build from the tarball.
Created attachment 989869 [details] stack trace with debug info
(In reply to Michael Catanzaro from comment #14) > So, here's the deal. I cannot reproduce this on Fedora 21 with my > development copies of WebKitGTK+ and Epiphany. So something else in the > stack must have changed. But I also cannot reproduce this on rawhide with my development copy of WebKitGTK+, it only happens when I build our RPM with mock. I tried disabling hardened build but that didn't help. I also tried building with -DENABLE_JIT=OFF and -DENABLE_LLINT_C_LOOP=ON (as we do for non-x86) out of desperation, but that didn't help either (and the stack trace looks the same). I tried compiling with -DCMAKE_C_FLAGS='-O0 -g' and -DCMAKE_CXX_FLAGS='-O0 -g' to make see if our compiler flags are to blame, but that didn't help. It's surely not a compiler issue because it started before we switched to GCC 5.0. So I'm kind of out of ideas as to why the bug only occurs when installed from one of our RPMs. I'm trying now with all of our patches disabled, but I doubt that will make any difference. This will be very hard to move forward with unfortunately, since JSC is difficult to debug unless you are a JSC developer.
OK I have a build that works. That is very good news. But I changed many things at once, so it will take some time to pinpoint what fixed this.
(In reply to Michael Catanzaro from comment #20) > I tried compiling with -DCMAKE_C_FLAGS='-O0 -g' and > -DCMAKE_CXX_FLAGS='-O0 -g' to make see if our compiler flags are to blame, > but that didn't help. For the record, this just resulted in those flags being prepended(!) to the build, it didn't remove the Fedora-specific CXXFLAGS like I was expecting, but those aren't the problem.
OK, this is caused by one of our downstream patches. I think the cloop patch, since everything else looks so innocent, but I am not sure of that yet.
Should be fixed in webkitgtk4-2.7.4-6.fc23 and webkitgtk4-2.7.4-6.fc22.
Just a note there with that patch disabled the JSC will be crashing on secondary arches (I will take care of updating that patch).
And another note, the fixed builds are blocked by bug #1191695