After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 696594 - Leak when sending responses from the SoupCache
Leak when sending responses from the SoupCache
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: HTTP Transport
2.39.x
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2013-03-25 22:08 UTC by Xan Lopez
Modified: 2013-03-26 16:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-soup-session-fix-memory-leak.patch (891 bytes, patch)
2013-03-26 15:23 UTC, Xan Lopez
committed Details | Review

Description Xan Lopez 2013-03-25 22:08:09 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)
Comment 1 Xan Lopez 2013-03-26 15:12:32 UTC
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.
Comment 2 Xan Lopez 2013-03-26 15:23:43 UTC
Created attachment 239873 [details] [review]
0001-soup-session-fix-memory-leak.patch

Something like this seems to work.
Comment 3 Dan Winship 2013-03-26 16:15:13 UTC
Comment on attachment 239873 [details] [review]
0001-soup-session-fix-memory-leak.patch

yes, looks right
Comment 4 Xan Lopez 2013-03-26 16:17:02 UTC
Thanks, pushed to master.