This bug has been created based on an anonymous crash report requested by the package maintainer. Report URL: https://retrace.fedoraproject.org/faf/reports/bthash/8641daad10c45303257386d161ddfd537833f6f4/
webkitgtk4-2.8.3-2.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/webkitgtk4-2.8.3-2.fc22
Package webkitgtk4-2.8.3-2.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing webkitgtk4-2.8.3-2.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-9137/webkitgtk4-2.8.3-2.fc22 then log in and leave karma (feedback).
webkitgtk4-2.8.3-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Problem still exists in webkitgtk4-2.8.3-2.fc22. However, the backtrace shows a little different. { "crash_thread": true , "frames": [ { "address": 3042941392 , "build_id": "246ade931c3a291d85d581516d77db1c03174b2f" , "build_id_offset": 7170512 , "function_name": "bmalloc::Heap::allocateXLarge(std::lock_guard<bmalloc::StaticMutex>&, unsigned int, unsigned int)" , "file_name": "/lib/libjavascriptcoregtk-4.0.so.18" } , { "address": 3042941460 , "build_id": "246ade931c3a291d85d581516d77db1c03174b2f" , "build_id_offset": 7170580 , "function_name": "bmalloc::Heap::allocateXLarge(std::lock_guard<bmalloc::StaticMutex>&, unsigned int)" , "file_name": "/lib/libjavascriptcoregtk-4.0.so.18" } , { "address": 3042929992 , "build_id": "246ade931c3a291d85d581516d77db1c03174b2f" , "build_id_offset": 7159112 , "function_name": "bmalloc::Allocator::allocateXLarge(unsigned int)" , "file_name": "/lib/libjavascriptcoregtk-4.0.so.18" } , { "address": 3042930125 , "build_id": "246ade931c3a291d85d581516d77db1c03174b2f" , "build_id_offset": 7159245 , "function_name": "bmalloc::Allocator::allocateSlowCase(unsigned int)" , "file_name": "/lib/libjavascriptcoregtk-4.0.so.18" } , { "address": 3042721632 , "build_id": "246ade931c3a291d85d581516d77db1c03174b2f" , "build_id_offset": 6950752 , "function_name": "WTF::fastMalloc(unsigned int)" , "file_name": "/lib/libjavascriptcoregtk-4.0.so.18" } , { "address": 3046303444 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 2172628 , "function_name": "WTF::Vector<WebCore::FloatRect, 0u, WTF::CrashOnOverflow>::expandCapacity(unsigned int)" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3056969668 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 12838852 , "function_name": "WebCore::TextureMapperTiledBackingStore::createOrDestroyTilesIfNeeded(WebCore::FloatSize const&, WebCore::IntSize const&, bool)" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3056972035 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 12841219 , "function_name": "WebCore::TextureMapperTiledBackingStore::updateContents(WebCore::TextureMapper*, WebCore::GraphicsLayer*, WebCore::FloatSize const&, WebCore::IntRect const&, WebCore::BitmapTexture::UpdateContentsFlag)" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3062502740 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 18371924 , "function_name": "WebCore::GraphicsLayerTextureMapper::updateBackingStoreIfNeeded()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3062502962 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 18372146 , "function_name": "WebCore::GraphicsLayerTextureMapper::updateBackingStoreIncludingSubLayers()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3062503037 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 18372221 , "function_name": "WebCore::GraphicsLayerTextureMapper::updateBackingStoreIncludingSubLayers()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3062503037 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 18372221 , "function_name": "WebCore::GraphicsLayerTextureMapper::updateBackingStoreIncludingSubLayers()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3062503037 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 18372221 , "function_name": "WebCore::GraphicsLayerTextureMapper::updateBackingStoreIncludingSubLayers()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3062503037 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 18372221 , "function_name": "WebCore::GraphicsLayerTextureMapper::updateBackingStoreIncludingSubLayers()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3062503037 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 18372221 , "function_name": "WebCore::GraphicsLayerTextureMapper::updateBackingStoreIncludingSubLayers()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3062503037 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 18372221 , "function_name": "WebCore::GraphicsLayerTextureMapper::updateBackingStoreIncludingSubLayers()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3062503037 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 18372221 , "function_name": "WebCore::GraphicsLayerTextureMapper::updateBackingStoreIncludingSubLayers()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3062503037 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 18372221 , "function_name": "WebCore::GraphicsLayerTextureMapper::updateBackingStoreIncludingSubLayers()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3048573735 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 4442919 , "function_name": "WebKit::LayerTreeHostGtk::flushPendingLayerChanges()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3048574604 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 4443788 , "function_name": "WebKit::LayerTreeHostGtk::flushAndRenderLayers()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3048574764 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 4443948 , "function_name": "WebKit::LayerTreeHostGtk::layerFlushTimerFired()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3048576674 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 4445858 , "function_name": "std::_Function_handler<void (), std::_Bind<std::_Mem_fn<void (WebKit::LayerTreeHostGtk::*)()> (WebKit::LayerTreeHostGtk*)> >::_M_invoke(std::_Any_data const&)" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3042924701 , "build_id": "246ade931c3a291d85d581516d77db1c03174b2f" , "build_id_offset": 7153821 , "function_name": "WTF::GMainLoopSource::voidCallback()" , "file_name": "/lib/libjavascriptcoregtk-4.0.so.18" } , { "address": 3042909024 , "build_id": "246ade931c3a291d85d581516d77db1c03174b2f" , "build_id_offset": 7138144 , "function_name": "WTF::GMainLoopSource::voidSourceCallback(WTF::GMainLoopSource*)" , "file_name": "/lib/libjavascriptcoregtk-4.0.so.18" } , { "address": 3024803073 , "build_id": "dc8973e74484b71421b1f3617032d5168ea78d81" , "build_id_offset": 283905 , "function_name": "g_idle_dispatch" , "file_name": "/lib/libglib-2.0.so.0" } , { "address": 3024817475 , "build_id": "dc8973e74484b71421b1f3617032d5168ea78d81" , "build_id_offset": 298307 , "function_name": "g_main_context_dispatch" , "file_name": "/lib/libglib-2.0.so.0" } , { "address": 3024818469 , "build_id": "dc8973e74484b71421b1f3617032d5168ea78d81" , "build_id_offset": 299301 , "function_name": "g_main_context_iterate.isra.29" , "file_name": "/lib/libglib-2.0.so.0" } , { "address": 3024819377 , "build_id": "dc8973e74484b71421b1f3617032d5168ea78d81" , "build_id_offset": 300209 , "function_name": "g_main_loop_run" , "file_name": "/lib/libglib-2.0.so.0" } , { "address": 3069488104 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 25357288 , "function_name": "WTF::RunLoop::run()" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3048566954 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 4436138 , "function_name": "int WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**)" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3048566276 , "build_id": "d8a23a4c1d5d1de287f818918e031e7829bcdb34" , "build_id_offset": 4435460 , "function_name": "WebProcessMainUnix" , "file_name": "/lib/libwebkit2gtk-4.0.so.37" } , { "address": 3078371816 , "build_id": "e4bcd3a36b31940dcf028dd015ab4a25fadc2c35" , "build_id_offset": 2536 , "function_name": "main" , "file_name": "/usr/libexec/webkit2gtk-4.0/WebKitWebProcess" } ] }
(In reply to zwpwjwtz from comment #4) > Problem still exists in webkitgtk4-2.8.3-2.fc22. I see 105 new reports of this in FAF.
(In reply to zwpwjwtz from comment #4) > Problem still exists in webkitgtk4-2.8.3-2.fc22. However, the backtrace > shows a little different. Do you still have the crash report? Could you please post the contents of the file "backtrace," not "core_backtrace" that you posted (which isn't as useful). In this case, I'm afraid that creating a bug report based on the anonymous crash report was a mistake, because now we have automatically prevented ABRT from creating a proper bug report with a full backtrace, since it will detect this bug as a duplicate and decide there's no need to post the backtrace. :(
By the way, can you confirm that this was a random crash, not something that occurs every time you try to use the browser?
This is not a random crash. Every time I open this URL(a page from of Tmall, a Chinese electronic mall): http://crucial.tmall.com/category-988709636.htm?utm_source=baidu&utm_medium=ppc&utm_term=6.18&utm_content=general&utm_campaign=s_mx100 Konqueror as well as Epiphany will crash. I've reported this bug in KDE bugtracking system(https://bugzilla.redhat.com/show_bug.cgi?id=1225733), however there's no response yet. Further information: Firefox, Google Chrome won't crash when loading the same URL. If I'm using Ubuntu 15.04, Epiphany won't crash. (In reply to Michael Catanzaro from comment #7) > By the way, can you confirm that this was a random crash, not something that > occurs every time you try to use the browser?
Sorry, it's https://bugs.kde.org/show_bug.cgi?id=349089. (In reply to zwpwjwtz from comment #8) > This is not a random crash. Every time I open this URL(a page from of Tmall, > a Chinese electronic mall): > > http://crucial.tmall.com/category-988709636. > htm?utm_source=baidu&utm_medium=ppc&utm_term=6. > 18&utm_content=general&utm_campaign=s_mx100 > Konqueror as well as Epiphany will crash. > > I've reported this bug in KDE bugtracking > system(https://bugzilla.redhat.com/show_bug.cgi?id=1225733), however there's > no response yet. > > Further information: Firefox, Google Chrome won't crash when loading the > same URL. If I'm using Ubuntu 15.04, Epiphany won't crash. > > (In reply to Michael Catanzaro from comment #7) > > By the way, can you confirm that this was a random crash, not something that > > occurs every time you try to use the browser?
I can't find the file named "backtrace". The file list of ABRT data directory: =================================================================== -rw-r-----. 1 root abrt 5 Jul 2 13:36 abrt_version -rw-r-----. 1 root abrt 9 Jul 2 13:36 analyzer -rw-r-----. 1 root abrt 4 Jul 2 13:36 architecture -rw-r-----. 1 root abrt 177 Jul 2 13:36 cgroup -rw-r-----. 1 root abrt 47 Jul 2 13:36 cmdline -rw-r-----. 1 root abrt 10 Jul 2 13:36 component -rw-r-----. 1 root abrt 36166 Jul 2 13:36 core_backtrace -rw-r-----. 1 root abrt 735731712 Jul 2 13:36 coredump -rw-r-----. 1 root abrt 1 Jul 2 13:36 count -rw-r-----. 1 root abrt 13872 Jul 2 13:36 dso_list -rw-r-----. 1 root abrt 1432 Jul 2 13:36 environ -rw-r-----. 1 root abrt 44 Jul 2 13:36 executable -rw-r-----. 1 root abrt 4 Jul 2 13:36 global_pid -rw-r-----. 1 root abrt 21 Jul 2 13:36 hostname -rw-r-----. 1 root abrt 19 Jul 2 13:36 kernel -rw-r-----. 1 root abrt 10 Jul 2 13:35 last_occurrence -rw-r-----. 1 root abrt 1323 Jul 2 13:36 limits -rw-r-----. 1 root abrt 54488 Jul 2 13:36 maps -rw-r-----. 1 root abrt 3265 Jul 2 13:36 mountinfo -rw-r-----. 1 root abrt 85 Jul 2 13:36 namespaces -rw-r-----. 1 root abrt 1401 Jul 2 13:36 open_fds -rw-r-----. 1 root abrt 447 Jul 2 13:36 os_info -rw-r-----. 1 root abrt 30 Jul 2 13:36 os_release -rw-r-----. 1 root abrt 23 Jul 2 13:36 package -rw-r-----. 1 root abrt 4 Jul 2 13:36 pid -rw-r-----. 1 root abrt 4 Jul 2 13:36 pkg_arch -rw-r-----. 1 root abrt 1 Jul 2 13:36 pkg_epoch -rw-r-----. 1 root abrt 10 Jul 2 13:36 pkg_name -rw-r-----. 1 root abrt 6 Jul 2 13:36 pkg_release -rw-r-----. 1 root abrt 5 Jul 2 13:36 pkg_version -rw-r-----. 1 root abrt 820 Jul 2 13:36 proc_pid_status -rw-r-----. 1 root abrt 10 Jul 2 13:36 pwd -rw-r-----. 1 root abrt 34 Jul 2 13:36 reason -rw-r-----. 1 root abrt 4 Jul 2 13:36 runlevel -rw-r-----. 1 root abrt 10 Jul 2 13:35 time -rw-r-----. 1 root abrt 4 Jul 2 13:36 type -rw-r-----. 1 root abrt 4 Jul 2 13:36 uid -rw-r-----. 1 root abrt 5 Jul 2 13:36 username -rw-r-----. 1 root abrt 40 Jul 2 13:36 uuid =================================================================== Which one should I upload? (In reply to Michael Catanzaro from comment #6) > (In reply to zwpwjwtz from comment #4) > > Problem still exists in webkitgtk4-2.8.3-2.fc22. However, the backtrace > > shows a little different. > > Do you still have the crash report? Could you please post the contents of > the file "backtrace," not "core_backtrace" that you posted (which isn't as > useful). > > In this case, I'm afraid that creating a bug report based on the anonymous > crash report was a mistake, because now we have automatically prevented ABRT > from creating a proper bug report with a full backtrace, since it will > detect this bug as a duplicate and decide there's no need to post the > backtrace. :(
After quite some insane week debugging and investigating this issue, I finally found out that building WebKit with -fno-tree-sra would prevent this crash from happening for my use cases (I was seeing this crash reliably too), see the full report of this work here: https://bugs.webkit.org/show_bug.cgi?id=146440 So, now I just tested this URL you provided with MiniBrowser and I'm happy to report that, even though I can reproduce the crash too with MiniBrowser in my system with the normal package of WebKit, I can't reproduce it anymore if I build it passing -fno-tree-sra. Perhaps you could try the same thing? Btw, for now I simply built all WebKit passing this flag but I'd be happier if I could remove this optimization just for bmalloc. I'm building a new package now to test this option, will report here back once I have some results.
(In reply to zwpwjwtz from comment #8) > This is not a random crash. Every time I open this URL(a page from of Tmall, > a Chinese electronic mall): > > http://crucial.tmall.com/category-988709636. > htm?utm_source=baidu&utm_medium=ppc&utm_term=6. > 18&utm_content=general&utm_campaign=s_mx100 > Konqueror as well as Epiphany will crash. OK, thanks a bunch. In the future, remember that posting details about how to reproduce a crash is a great way to get your bug looked at, since otherwise it's much more difficult to fix. Anyway, thanks to all the time Mario spent testing this, let's try a test build with -fno-tree-sra. > I've reported this bug in KDE bugtracking > system(https://bugzilla.redhat.com/show_bug.cgi?id=1225733), however there's > no response yet. That's a completely different bug that just happens to occur on the same site. Since QtWebKit was development ended about three years ago, I have no clue if anyone will look at that bug or fix it.
(In reply to Michael Catanzaro from comment #12) > [...] > Anyway, thanks to all the time Mario spent testing this, let's try a test > build with -fno-tree-sra. > Hey Michael, if you want to hold on a bit that build, I might have some additional info by the end of today that might be worth a shot. Basically, I'm trying to reduce the scope of the -fno-tree-sra parameter by applying it only to the part(s) that are strictly needed instead of everything. So far I tried bmalloc, WTF and JSC, but the crash did not go away. Now re-building WebCore to see how it works, will report back later.
I already started the build, using -fno-tree-sra for i686 only. I'm not really too concerned about performance on that architecture; more important to avoid the crash. I will CC a GCC developer, since there is good potential this is a GCC bug, maybe already a known one.
Sounds good. FTR, as I mentioned in the upstream bug, in the end the crash can be avoided by disabling this optimization from Webcore only. See my last comment in the bug here: https://bugs.webkit.org/show_bug.cgi?id=146440#c11 Thanks for CCing a GCC dev, btw. After all I went through this week, I also think there's a chance it could be a bug in there.
If you want me to look at it, create small self-contained testcase (start with running valgrind, trying -fsanitize=undefined, -fsanitize=address, bisect which compilation unit is a problem, try some compiler options (-fno-inline, -fno-strict-aliasing, -fno-aggressive-loop-optimizations, etc.), and provide as many details as possible why do you think there is a GCC bug.
webkitgtk4-2.8.3-5.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/webkitgtk4-2.8.3-5.fc22
(In reply to Jakub Jelinek from comment #16) > If you want me to look at it, create small self-contained testcase (start > with running valgrind, trying -fsanitize=undefined, -fsanitize=address, > bisect which compilation unit is a problem, try some compiler options > (-fno-inline, -fno-strict-aliasing, -fno-aggressive-loop-optimizations, > etc.), and provide as many details as possible why do you think there is a > GCC bug. This is going to be very tricky, as it's still unclear what exactly is causing the crash in WebKit, which works fine anyway in many other situations. My initial guessing was that this could be a problem in the implementation of the bmalloc memory allocator, but I've tried building WebKit passing -fno-tree-sra while building that subcomponent only and that did not get rid of the crash. I then tried selectively building other parts of WebKit passing that -fno-tree-sra flag and neither doing it in the WTF (Web Template Framework) or JSC got rid of the crash, so I ended up passing it when building WebCore (the main component) and that made the crash go away again. So, my current theory is that the problem with this flag is actually not caused by bmalloc's implementation, but by something else inside WebCore, which gets exposed via the bmalloc xLarge memory allocation. Now, WebCore is huge so what that "something else" actually could be is hard to tell, which thus makes quite difficult to write a minimal and self-contained test case, as I'm not sure what exactly should be checked. Any chance that you, or anyone else, could give a try to this by loading the following URL with a WebKit2-based browser in a 32bit Intel system? http://crucial.tmall.com/category-988709636.htm?utm_source=baidu&utm_medium=ppc&utm_term=6.18&utm_content=general&utm_campaign=s_mx100 I think that could help, but understand if that was a "too generic" request :)
Package webkitgtk4-2.8.3-5.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing webkitgtk4-2.8.3-5.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-11060/webkitgtk4-2.8.3-5.fc22 then log in and leave karma (feedback).
It works fine with Epiphany. Much thanks. (In reply to Michael Catanzaro from comment #12) > That's a completely different bug that just happens to occur on the same > site. Since QtWebKit was development ended about three years ago, I have no > clue if anyone will look at that bug or fix it. I hope the bug presented in Konqueror can be soon fixed. (In reply to Mario Sanchez Prada from comment #18) > I then tried selectively building other parts of WebKit passing that > -fno-tree-sra flag and neither doing it in the WTF (Web Template Framework) > or JSC got rid of the crash, so I ended up passing it when building WebCore > (the main component) and that made the crash go away again. > > So, my current theory is that the problem with this flag is actually not > caused by bmalloc's implementation, but by something else inside WebCore, > which gets exposed via the bmalloc xLarge memory allocation. > > Now, WebCore is huge so what that "something else" actually could be is hard > to tell, which thus makes quite difficult to write a minimal and > self-contained test case, as I'm not sure what exactly should be checked. Could someone figure out what happens in Webcore by examing this backtrace: https://bugs.kde.org/show_bug.cgi?id=349089 I notice that call stack from "Thread 1" has something to do with prototype function.
To be clear, your Konqueror issue is a completely unrelated crash, and the QtWebKit maintainer(s?) are a completely different group of people. Konqueror uses QtWebKit, an obsolete port of WebKit that was deleted from the upstream WebKit project a couple years ago when its maintainers announced they would no longer continue to develop it. Epiphany uses WebKitGTK+, which is actively maintained upstream. This crash occurred in code that was added last year, but I think the latest version of QtWebKit is based on a version of WebKit from 2012.
webkitgtk4-2.8.4-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/webkitgtk4-2.8.4-1.fc22
webkitgtk4-2.8.4-2.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/webkitgtk4-2.8.4-2.fc22
webkitgtk4-2.8.4-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.