Bug 118788 - [GTK] WebKitDOM objects leaking
Summary: [GTK] WebKitDOM objects leaking
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-17 04:18 PDT by Tomas Popela
Modified: 2015-04-08 07:12 PDT (History)
7 users (show)

See Also:


Attachments
wk-leaks.c (9.84 KB, text/plain)
2015-02-13 04:50 PST, Milan Crha
no flags Details
wk-leaks.c ][ (12.15 KB, text/plain)
2015-02-18 09:21 PST, Milan Crha
no flags Details
wk-leaks.c ]I[ (12.05 KB, text/plain)
2015-02-18 09:40 PST, Milan Crha
no flags Details
Patch (4.86 KB, patch)
2015-03-11 10:11 PDT, Carlos Garcia Campos
no flags Details | Formatted Diff | Diff
Updated patch (4.95 KB, patch)
2015-03-11 10:20 PDT, Carlos Garcia Campos
darin: review+
Details | Formatted Diff | Diff
New patch (6.12 KB, patch)
2015-03-14 01:56 PDT, Carlos Garcia Campos
svillar: review+
Details | Formatted Diff | Diff
Fix test case (567 bytes, text/plain)
2015-04-07 10:54 PDT, Carlos Garcia Campos
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Popela 2013-07-17 04:18:38 PDT
On recent trunk I noticed that we are leaking some WebKitDOM objects like Range or Node. 

tpopela  ~/dev/webkitgtk3/webkitgtk-2.0.3/Programs/unittests  >  13:09  [f19]  
$ ./testdomnode 
/webkit/domnode/test_hierarchy_navigation: OK
/webkit/domnode/test_insertion: OK

tpopela  ~/dev/WebKit/WebKitBuild/Debug/Programs/unittests  >  13:06  [master]  
$ ./testdomnode 
/webkit/domnode/test_hierarchy_navigation: OK
/webkit/domnode/test_insertion: OK
LEAK: 5 WebCoreNode

It is even bigger, when testing WebKit based composer for Evolution (4 lines email written in composer):

tpopela  ~/dev/evolution/build/test/bin  >  13:04   
$ ./evolution 
LEAK: 20 CachedResource
LEAK: 7191 Range
LEAK: 4155 WebCoreNode
Comment 1 Martin Robinson 2013-07-17 08:16:18 PDT
DOM nodes are cached and released after a short timeout. Can you verify that after spinning the main loop for a while this doesn't happen automatically?
Comment 2 Tomas Popela 2013-07-18 01:21:41 PDT
No, it does not help.
Comment 3 Sergio Villar Senin 2013-07-18 01:54:13 PDT
(In reply to comment #0)

> tpopela  ~/dev/evolution/build/test/bin  >  13:04   
> $ ./evolution 
> LEAK: 20 CachedResource
> LEAK: 7191 Range
> LEAK: 4155 WebCoreNode

Don't know exactly about DOM objects, but note that the "leaks" in CachedResources are not really leaks. WebKit does not free cached resources on program exit on purpose, because the program is actually finishing so they'll be eventually released anyway and we're speeding up the exit process.
Comment 4 Zan Dobersek 2013-07-18 07:38:09 PDT
(In reply to comment #3)
> (In reply to comment #0)
> 
> > tpopela  ~/dev/evolution/build/test/bin  >  13:04   
> > $ ./evolution 
> > LEAK: 20 CachedResource
> > LEAK: 7191 Range
> > LEAK: 4155 WebCoreNode
> 
> Don't know exactly about DOM objects, but note that the "leaks" in CachedResources are not really leaks. WebKit does not free cached resources on program exit on purpose, because the program is actually finishing so they'll be eventually released anyway and we're speeding up the exit process.

This number might be lower after r152340.
http://trac.webkit.org/changeset/152340
Comment 5 Milan Crha 2015-02-13 04:50:02 PST
Created attachment 246517 [details]
wk-leaks.c

Test application (first line shows how to compile & run it), which makes it easier to reproduce the leaks. Similar code (update_styles()) is used in Evolution and called to quite few times on various occasions.

The thing is that objects like WebKitDOMCSSRuleList (returned from webkit_dom_css_style_sheet_get_css_rules()) and WebKitDOMCSSRule (returned from webkit_dom_css_rule_list_item()) are not freed on frame reload, but a new objects are returned anyway.

The reason is that DOMObjectCache::clearByFrame() is called with a valid frame, but these objkects (and many other DOM objects) are stored in the cache with NULL data->frame.

My opinion: It won't work to always remove objects which has data->frame == NULL in the cache on any frame cleanup, because that would influence (invalidate) GObject-s from other web views (if there are more instances).
Comment 6 Carlos Garcia Campos 2015-02-16 06:37:37 PST
(In reply to comment #5)
> Created attachment 246517 [details]
> wk-leaks.c
> 
> Test application (first line shows how to compile & run it), which makes it
> easier to reproduce the leaks. Similar code (update_styles()) is used in
> Evolution and called to quite few times on various occasions.
> 
> The thing is that objects like WebKitDOMCSSRuleList (returned from
> webkit_dom_css_style_sheet_get_css_rules()) and WebKitDOMCSSRule (returned
> from webkit_dom_css_rule_list_item()) are not freed on frame reload, but a
> new objects are returned anyway.
> 
> The reason is that DOMObjectCache::clearByFrame() is called with a valid
> frame, but these objkects (and many other DOM objects) are stored in the
> cache with NULL data->frame.
> 
> My opinion: It won't work to always remove objects which has data->frame ==
> NULL in the cache on any frame cleanup, because that would influence
> (invalidate) GObject-s from other web views (if there are more instances).

I think the actual bug are the gtk-doc tags used, because not all GObject DOM bindings are supposed to be returned as transfer-none. See the original bug #40302 and the commits message:

"Manual management (calling g_object_unref on them) is also allowed, and is required for objects that are not in the DOM tree (eg NodeLists)."

I forgot about those when I added the transfer annotations to the gtk-doc :-(
Comment 7 Carlos Garcia Campos 2015-02-16 09:51:30 PST
(In reply to comment #6)
> (In reply to comment #5)
> > Created attachment 246517 [details]
> > wk-leaks.c
> > 
> > Test application (first line shows how to compile & run it), which makes it
> > easier to reproduce the leaks. Similar code (update_styles()) is used in
> > Evolution and called to quite few times on various occasions.
> > 
> > The thing is that objects like WebKitDOMCSSRuleList (returned from
> > webkit_dom_css_style_sheet_get_css_rules()) and WebKitDOMCSSRule (returned
> > from webkit_dom_css_rule_list_item()) are not freed on frame reload, but a
> > new objects are returned anyway.
> > 
> > The reason is that DOMObjectCache::clearByFrame() is called with a valid
> > frame, but these objkects (and many other DOM objects) are stored in the
> > cache with NULL data->frame.
> > 
> > My opinion: It won't work to always remove objects which has data->frame ==
> > NULL in the cache on any frame cleanup, because that would influence
> > (invalidate) GObject-s from other web views (if there are more instances).
> 
> I think the actual bug are the gtk-doc tags used, because not all GObject
> DOM bindings are supposed to be returned as transfer-none. See the original
> bug #40302 and the commits message:
> 
> "Manual management (calling g_object_unref on them) is also allowed, and is
> required for objects that are not in the DOM tree (eg NodeLists)."
> 
> I forgot about those when I added the transfer annotations to the gtk-doc :-(

But there's still a problem. A lot of DOM objects are initially created and then added to a container, so they are not initially in document and we don't track their frame. I wonder if we should simply remove the inDocument check and always track the frame.
Comment 8 Carlos Garcia Campos 2015-02-16 11:29:17 PST
I have reworked the DOMObjectCache in bug #141558, removing the inDocument condition and it seems to work for all the WebKit2 unit tests.
Comment 9 Milan Crha 2015-02-18 09:21:47 PST
Created attachment 246821 [details]
wk-leaks.c ][

Updated test program. It also checks when the returned pointers are freed and which are eventually leaked and prints that on console. The memory-related lines start with "\t#" in the debug output.
Comment 10 Milan Crha 2015-02-18 09:40:38 PST
Created attachment 246823 [details]
wk-leaks.c ]I[

I'm sorry, one mo update, to not leak the object in the code as such, at the end of add_css_rule_into_style_sheet(). Tomas pointed it out on IRC.
Comment 11 Milan Crha 2015-02-26 23:24:01 PST
Few more observations found (by Tomas). When using
   webkit_dom_event_target_add_event_listener()
on a webkit GObject, then this object cannot be unreffed, because that will cause the listener die as well. That's pretty unfortunate. I know the idea is to have the object alive as long as the associated frame is alive, and keep all the memory management fully up to the WebKit, but that doesn't work in Evolution, where we have one WebView for a whole lifetime of the application.

I know there is an option to destroy & create the WebView whenever a new message is selected or such, but it has UI impact, which I'd like to avoid (UI flickering is not good).

Thus, apart of fixing the DOMObjecCache, could you add also a function for webkit_web_view to cleanup all objects from the DOMObjectCache associated for that WebView (its frame)? If would be like if the WebView's frame was destroyed, except it will not. That will mean than any GObject-s created for that view will be invalidated. It'll help to keep the memory usage low without constant recreation of the widgets.
Comment 12 Carlos Garcia Campos 2015-02-28 02:46:53 PST
(In reply to comment #11)
> Few more observations found (by Tomas). When using
>    webkit_dom_event_target_add_event_listener()
> on a webkit GObject, then this object cannot be unreffed, because that will
> cause the listener die as well. That's pretty unfortunate.

The thing is that the event listener object doesn't exist in DOM bindings, it's an internal object that is created on demand, and destroyed when the target object is destroyed, or when the event listener is removed.

> I know the idea
> is to have the object alive as long as the associated frame is alive, and
> keep all the memory management fully up to the WebKit, but that doesn't work
> in Evolution, where we have one WebView for a whole lifetime of the
> application.
> 
> I know there is an option to destroy & create the WebView whenever a new
> message is selected or such, but it has UI impact, which I'd like to avoid
> (UI flickering is not good).

Yes, I agree that's not an option, it doesn't make sense to destroiy and create web views for this. I think the problem is that we have always made the DOM objects depend on its frame, when what we should probably be monitoring is the document instead of (or in addition to) the frame.

> Thus, apart of fixing the DOMObjecCache, could you add also a function for
> webkit_web_view to cleanup all objects from the DOMObjectCache associated
> for that WebView (its frame)? If would be like if the WebView's frame was
> destroyed, except it will not. That will mean than any GObject-s created for
> that view will be invalidated. It'll help to keep the memory usage low
> without constant recreation of the widgets.

We are not going to add new API to WebKit1, but I think it can be fixed internally without any new API, by clearing the objects when the document is detached from the frame or when the document is destroyed or the render tree is destroyed, I don't know exactly how to do it yet, but it could be something in that direction.
Comment 13 Carlos Garcia Campos 2015-03-11 10:11:09 PDT
Created attachment 248428 [details]
Patch

I think this patch solves the problems Milan is having. It also clears the DOM objects when the document is detached from the frame.
Comment 14 Carlos Garcia Campos 2015-03-11 10:20:57 PDT
Created attachment 248431 [details]
Updated patch

Made a mistake in the unit test, it should be fine now
Comment 15 Milan Crha 2015-03-12 01:24:42 PDT
(In reply to comment #13)
> I think this patch solves the problems Milan is having. It also clears the
> DOM objects when the document is detached from the frame.

This is not for WebKit1, or the 2.4.8 misses some changeset, because there is no DOMObjectCacheFrameObserver. My problem is currently with WebKit1, thus I cannot test this change to know whether it'll really fix my issue or not.
Comment 16 Carlos Garcia Campos 2015-03-12 01:42:27 PDT
(In reply to comment #15)
> (In reply to comment #13)
> > I think this patch solves the problems Milan is having. It also clears the
> > DOM objects when the document is detached from the frame.
> 
> This is not for WebKit1, or the 2.4.8 misses some changeset, because there
> is no DOMObjectCacheFrameObserver. My problem is currently with WebKit1,
> thus I cannot test this change to know whether it'll really fix my issue or
> not.

Yes, I know, I'll backport this and the other patches to 2.4 branch as soon as I find the time.
Comment 17 Milan Crha 2015-03-12 05:46:59 PDT
(In reply to comment #16)
> Yes, I know, I'll backport this and the other patches to 2.4 branch as soon
> as I find the time.

Thanks. Once you have it done, and give me the pointers to relevant changes, I'll be able to test it in the "real life" of the Evolution use case.
Comment 18 Carlos Garcia Campos 2015-03-14 01:51:55 PDT
I've realized the patch doesn't always work. It only works the first time the document is detached from the frame, but when a new document is created we no longer track its DOM Window. We need to use a different class for the DOM Window observer.
Comment 19 Carlos Garcia Campos 2015-03-14 01:56:39 PDT
Created attachment 248646 [details]
New patch

Instead of making DOMObjectCacheFrameObserver inherit from DOMWindowProperty, use a helper class DOMWindowObserver used as a member of DOMObjectCacheFrameObserver and created/destroyed on demand to track the document when it's detached form the frame, but also when a new document is created. I've updated the unit test to run 3 times, because when run twice, the first time objects were correctly cleared when the document was detached from frame, but the second time it was the frame destruction what caused the objects to be cleared.
Comment 20 Sergio Villar Senin 2015-03-17 02:26:16 PDT
Comment on attachment 248646 [details]
New patch

View in context: https://bugs.webkit.org/attachment.cgi?id=248646&action=review

Looks good

> Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestDOMNode.cpp:73
> +    }

I think it's worth also to try to load some external resource and reload it multiple times as the code paths are different that starting new loads.

> Tools/TestWebKitAPI/Tests/WebKit2Gtk/WebProcessTest.cpp:67
> +    // Test /WebKitDOMNode/dom-cache is an exception, because it's called twice, so

trice right?
Comment 21 Carlos Garcia Campos 2015-03-17 04:09:30 PDT
(In reply to comment #20)
> Comment on attachment 248646 [details]
> New patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=248646&action=review
> 
> Looks good

Thanks.

> > Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestDOMNode.cpp:73
> > +    }
> 
> I think it's worth also to try to load some external resource and reload it
> multiple times as the code paths are different that starting new loads.

Not easy in this case, but even if the code path is not exactly the same, the global object is detached from frame on reload as well, so there's no difference.

> > Tools/TestWebKitAPI/Tests/WebKit2Gtk/WebProcessTest.cpp:67
> > +    // Test /WebKitDOMNode/dom-cache is an exception, because it's called twice, so
> 
> trice right?

Right.
Comment 22 Carlos Garcia Campos 2015-03-17 04:10:57 PDT
Committed r181631: <http://trac.webkit.org/changeset/181631>
Comment 23 Carlos Garcia Campos 2015-04-07 10:46:12 PDT
Milan, I've just backported this to 2.4 branch, see http://trac.webkit.org/changeset/182479. With a slightly modified version of your test case (manually unreffing the transfer full objects) I get no leaks:

# dump_leaked_pointers: leaked 0 pointers

Please, try it out to confirm it works as expected for you in evolution.
Comment 24 Carlos Garcia Campos 2015-04-07 10:54:01 PDT
Created attachment 250277 [details]
Fix test case

This is the patch required for wk-leaks.c, FWIW.
Comment 25 Milan Crha 2015-04-08 02:30:07 PDT
Thanks. I've got webkitgtk3 2.4.8 as patched in Fedora [1] and applied on top of it your changeset. When I run cvurrent git master of evolution (at git commit 6668154), then it crashes with this backtrace: 

#0  0x00007ffff1018668 in g_type_check_instance_is_fundamentally_a (type_instance=0x5337f20, fundamental_type=80) at gtype.c:4029
#1  0x00007ffff0ffebc4 in g_object_unref (_object=0x5337f20) at gobject.c:3067
#2  0x00007ffff4ad3de8 in WebKit::DOMObjectCacheFrameObserver::DOMWindowObserver::willDetachGlobalObjectFromFrame() () from /build/local/lib/libwebkitgtk-3.0.so.0
#3  0x00007ffff42e1db2 in WebCore::DOMWindow::willDetachDocumentFromFrame() () from /build/local/lib/libwebkitgtk-3.0.so.0
#4  0x00007ffff3ef307e in WebCore::Document::prepareForDestruction() () from /build/local/lib/libwebkitgtk-3.0.so.0
#5  0x00007ffff43021cd in WebCore::Frame::setView(WTF::PassRefPtr<WebCore::FrameView>) () from /build/local/lib/libwebkitgtk-3.0.so.0
#6  0x00007ffff4304fdb in WebCore::Frame::createView(WebCore::IntSize const&, WebCore::Color const&, bool, WebCore::IntSize const&, WebCore::IntRect const&, bool, WebCore::ScrollbarMode, bool, WebCore::ScrollbarMode, bool) ()
   from /build/local/lib/libwebkitgtk-3.0.so.0
#7  0x00007ffff3bccf81 in WebKit::FrameLoaderClient::transitionToCommittedForNewPage() () from /build/local/lib/libwebkitgtk-3.0.so.0
#8  0x00007ffff4261359 in WebCore::FrameLoader::transitionToCommitted(WebCore::CachedPage*) () from /build/local/lib/libwebkitgtk-3.0.so.0
#9  0x00007ffff4262ee7 in WebCore::FrameLoader::commitProvisionalLoad() () from /build/local/lib/libwebkitgtk-3.0.so.0
#10 0x00007ffff424a75a in WebCore::DocumentLoader::commitLoad(char const*, int) () from /build/local/lib/libwebkitgtk-3.0.so.0
#11 0x00007ffff424b810 in WebCore::DocumentLoader::continueAfterContentPolicy(WebCore::PolicyAction) () from /build/local/lib/libwebkitgtk-3.0.so.0
#12 0x00007ffff424ea07 in WebCore::DocumentLoader::responseReceived(WebCore::CachedResource*, WebCore::ResourceResponse const&) () from /build/local/lib/libwebkitgtk-3.0.so.0
#13 0x00007ffff4247ed7 in WebCore::DocumentLoader::handleSubstituteDataLoadNow(WebCore::Timer<WebCore::DocumentLoader>*) () from /build/local/lib/libwebkitgtk-3.0.so.0
#14 0x00007ffff3cd8a09 in WebCore::ThreadTimers::sharedTimerFiredInternal() () from /build/local/lib/libwebkitgtk-3.0.so.0
#15 0x00007ffff3cf8682 in WebCore::sharedTimerTimeoutCallback(void*) () from /build/local/lib/libwebkitgtk-3.0.so.0
#16 0x00007ffff0cd5451 in g_timeout_dispatch (source=0x575bce0, callback=0x7ffff3cf8670 <WebCore::sharedTimerTimeoutCallback(void*)>, user_data=0x0) at gmain.c:4545
#17 0x00007ffff0cd3656 in g_main_dispatch (context=0x674460) at gmain.c:3122
#18 0x00007ffff0cd4491 in g_main_context_dispatch (context=0x674460) at gmain.c:3737
#19 0x00007ffff0cd4676 in g_main_context_iterate (context=0x674460, block=1, dispatch=1, self=0x6746d0) at gmain.c:3808
#20 0x00007ffff0cd4a9d in g_main_loop_run (loop=0x4b087f0) at gmain.c:4002
#21 0x00007ffff252cd4c in gtk_main () at gtkmain.c:1219
#22 0x0000000000404f14 in main (argc=1, argv=0x7fffffffdd88) at main.c:638

It also prints runtime warnings right after start at the very same place. We made some leak-hunting fixes on WebKit objects, as it used to be safe to unref (almost) any webkit-returned object and it took care of the DOMObjectCache properly, but it doesn't seem to be related to this crash, because when I involve valgrind, I get this:

==15478== Invalid read of size 4
==15478==    at 0x86C5DE8: WebKit::DOMObjectCacheFrameObserver::DOMWindowObserver::willDetachGlobalObjectFromFrame() (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7ED3DB1: WebCore::DOMWindow::willDetachDocumentFromFrame() (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7AE507D: WebCore::Document::prepareForDestruction() (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7EF41CC: WebCore::Frame::setView(WTF::PassRefPtr<WebCore::FrameView>) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7EF6FDA: WebCore::Frame::createView(WebCore::IntSize const&, WebCore::Color const&, bool, WebCore::IntSize const&, WebCore::IntRect const&, bool, WebCore::ScrollbarMode, bool, WebCore::ScrollbarMode, bool) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x77BEF80: WebKit::FrameLoaderClient::transitionToCommittedForNewPage() (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7E53358: WebCore::FrameLoader::transitionToCommitted(WebCore::CachedPage*) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7E54EE6: WebCore::FrameLoader::commitProvisionalLoad() (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7E3C759: WebCore::DocumentLoader::commitLoad(char const*, int) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7E3D80F: WebCore::DocumentLoader::continueAfterContentPolicy(WebCore::PolicyAction) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7E40A06: WebCore::DocumentLoader::responseReceived(WebCore::CachedResource*, WebCore::ResourceResponse const&) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7E39ED6: WebCore::DocumentLoader::handleSubstituteDataLoadNow(WebCore::Timer<WebCore::DocumentLoader>*) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==  Address 0x150c63f8 is 8 bytes inside a block of size 16 free'd
==15478==    at 0x4A08103: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==15478==    by 0x86C4538: WebKit::DOMObjectCache::forget(void*) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x875CD24: webkit_dom_node_finalize(_GObject*) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0xB9EFE87: g_object_unref (gobject.c:3170)
==15478==    by 0x86C5DE7: WebKit::DOMObjectCacheFrameObserver::DOMWindowObserver::willDetachGlobalObjectFromFrame() (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7ED3DB1: WebCore::DOMWindow::willDetachDocumentFromFrame() (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7AE507D: WebCore::Document::prepareForDestruction() (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7EF41CC: WebCore::Frame::setView(WTF::PassRefPtr<WebCore::FrameView>) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7EF6FDA: WebCore::Frame::createView(WebCore::IntSize const&, WebCore::Color const&, bool, WebCore::IntSize const&, WebCore::IntRect const&, bool, WebCore::ScrollbarMode, bool, WebCore::ScrollbarMode, bool) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x77BEF80: WebKit::FrameLoaderClient::transitionToCommittedForNewPage() (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7E53358: WebCore::FrameLoader::transitionToCommitted(WebCore::CachedPage*) (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)
==15478==    by 0x7E54EE6: WebCore::FrameLoader::commitProvisionalLoad() (in /build/local/lib/libwebkitgtk-3.0.so.0.22.14)

From that I guess I need more than just that single changeset to get "working webkit1" here. Is there a way I can get a pre-release tarball or anything like that, with all the applied fixes, please?

[1] http://pkgs.fedoraproject.org/cgit/webkitgtk3.git/tree/
Comment 26 Milan Crha 2015-04-08 02:37:44 PDT
(In reply to comment #24)
> This is the patch required for wk-leaks.c, FWIW.

The patched wk-leaks.c works fine, it's only the evolution, which crashes and shows the critical warnings as stated in the previous comment.
Comment 27 Michael Catanzaro 2015-04-08 07:12:33 PDT
(In reply to comment #25)
> Thanks. I've got webkitgtk3 2.4.8 as patched in Fedora [1] and applied on
> top of it your changeset. When I run cvurrent git master of evolution (at
> git commit 6668154), then it crashes with this backtrace: 

See bug #143521