WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
118788
[GTK] WebKitDOM objects leaking
https://bugs.webkit.org/show_bug.cgi?id=118788
Summary
[GTK] WebKitDOM objects leaking
Tomas Popela
Reported
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
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
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Martin Robinson
Comment 1
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?
Tomas Popela
Comment 2
2013-07-18 01:21:41 PDT
No, it does not help.
Sergio Villar Senin
Comment 3
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.
Zan Dobersek
Comment 4
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
Milan Crha
Comment 5
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).
Carlos Garcia Campos
Comment 6
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 :-(
Carlos Garcia Campos
Comment 7
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.
Carlos Garcia Campos
Comment 8
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.
Milan Crha
Comment 9
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.
Milan Crha
Comment 10
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.
Milan Crha
Comment 11
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.
Carlos Garcia Campos
Comment 12
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.
Carlos Garcia Campos
Comment 13
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.
Carlos Garcia Campos
Comment 14
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
Milan Crha
Comment 15
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.
Carlos Garcia Campos
Comment 16
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.
Milan Crha
Comment 17
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.
Carlos Garcia Campos
Comment 18
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.
Carlos Garcia Campos
Comment 19
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.
Sergio Villar Senin
Comment 20
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?
Carlos Garcia Campos
Comment 21
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.
Carlos Garcia Campos
Comment 22
2015-03-17 04:10:57 PDT
Committed
r181631
: <
http://trac.webkit.org/changeset/181631
>
Carlos Garcia Campos
Comment 23
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.
Carlos Garcia Campos
Comment 24
2015-04-07 10:54:01 PDT
Created
attachment 250277
[details]
Fix test case This is the patch required for wk-leaks.c, FWIW.
Milan Crha
Comment 25
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/
Milan Crha
Comment 26
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.
Michael Catanzaro
Comment 27
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
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug