GNOME Bugzilla – Bug 696594
Leak when sending responses from the SoupCache
Last modified: 2013-03-26 16:17:05 UTC
Seems to be fairy large too: ==29102== 85,809 (4,864 direct, 80,945 indirect) bytes in 32 blocks are definitely lost in loss record 8,704 of 8,709 ==29102== at 0x4A0887C: malloc (vg_replace_malloc.c:270) ==29102== by 0x7D8B75E: g_malloc (gmem.c:159) ==29102== by 0x7DA4005: g_slice_alloc (gslice.c:1003) ==29102== by 0x7DA4045: g_slice_alloc0 (gslice.c:1029) ==29102== by 0x7D0D864: g_type_create_instance (gtype.c:1892) ==29102== by 0x7CF3EE5: g_object_constructor (gobject.c:1855) ==29102== by 0x7CF36FD: g_object_newv (gobject.c:1719) ==29102== by 0x7CF3E76: g_object_new_valist (gobject.c:1836) ==29102== by 0x7CF3111: g_object_new (gobject.c:1551) ==29102== by 0x7AB218A: soup_content_sniffer_content_processor_wrap_input (soup-content-sniffer.c:53) ==29102== by 0x7AB1F37: soup_content_processor_wrap_input (soup-content-processor.c:42) ==29102== by 0x7AC85A0: soup_message_setup_body_istream (soup-message-io.c:261) ==29102== by 0x7AAAD09: soup_cache_send_response (soup-cache.c:715) ==29102== by 0x7ADC697: async_respond_from_cache (soup-session.c:3925) ==29102== by 0x7ADCAA1: soup_session_send_async (soup-session.c:4035) ==29102== by 0x7AD0E74: soup_request_http_send_async (soup-request-http.c:143) ==29102== by 0x7ACFA0F: soup_request_send_async (soup-request.c:244) ==29102== by 0x65435D5: WebCore::ResourceHandle::start() (in /home/xan/gnome/lib64/libwebkit2gtk-3.0.so.22.2.0) ==29102== by 0x6533A13: WebCore::ResourceHandle::create(WebCore::NetworkingContext*, WebCore::ResourceRequest const&, WebCore::ResourceH$ ==29102== by 0x5D35CC3: WebCore::ResourceLoader::start() (in /home/xan/gnome/lib64/libwebkit2gtk-3.0.so.22.2.0)
I believe the leak comes from: We attach a stream as object data to the GTask (soup-session.c:3930), but later we steal that data so that the destroy function (g_object_unref) will never run (soup-session.c:3902). Then async_return_from_cache adds an extra reference to the stream (now we are at two), and when we finally return the result in async_send_request_return_result we always do just one unref (either in the error path or the normal one). So the stream always stays at one reference, and is leaked.
Created attachment 239873 [details] [review] 0001-soup-session-fix-memory-leak.patch Something like this seems to work.
Comment on attachment 239873 [details] [review] 0001-soup-session-fix-memory-leak.patch yes, looks right
Thanks, pushed to master.