GNOME Bugzilla – Bug 169826
leak in http-neon-method
Last modified: 2008-11-08 23:01:34 UTC
Valgrind reports this leak from gweather: ==17270== 19232 (32 direct, 19200 indirect) bytes in 2 blocks are definitely lost in loss record 195 of 233 ==17270== at 0x1B909292: malloc (vg_replace_malloc.c:130) ==17270== by 0x1CB78754: ne_calloc (ne_alloc.c:64) ==17270== by 0x1CB7421B: ne_add_response_header_handler (ne_request.c:629) ==17270== by 0x1CB74389: ne_request_create (ne_request.c:532) ==17270== by 0x1CB71E93: http_transfer_start (http-neon-method.c:2210) ==17270== by 0x1CB72196: do_open (http-neon-method.c:2360) ==17270== by 0x1BE6FF9E: gnome_vfs_open_uri_cancellable (gnome-vfs-cancellable-ops.c:57) ==17270== by 0x1BE7CE1D: _gnome_vfs_job_execute (gnome-vfs-job.c:964) ==17270== by 0x1BE7B52B: thread_routine (gnome-vfs-job-slave.c:64) ==17270== by 0x1BE8B573: thread_entry (gnome-vfs-thread-pool.c:186) ==17270== by 0x1C227C13: g_thread_create_proxy (gthread.c:561) ==17270== by 0xD8BB16: start_thread (in /lib/tls/libpthread-2.3.4.so) ==17270== by 0xCD8D7D: clone (in /lib/tls/libc-2.3.4.so)
Attaching a patch for comments. I don't think the patch resolves this exact leak, but it tries to plug the same kind of leaks in the rest of the file. This one is special it seems since it hands on the request to the caller.
Created attachment 38714 [details] [review] patch for leaks
Comment on attachment 38714 [details] [review] patch for leaks Commiting after review by Christian. Tested with gtik applet and gweather applet with no regressions. Leaving report open since the original leak is still not fixed.
{"davs", TRUE, "https", TRUE}, - {NULL, FALSE, FALSE} + {NULL, FALSE, NULL} Shouldn't the last line be changed to NULL, FALSE, NULL, FALSE ? This last statement looks ugly in one form or the other ;)
Ok thanks again Kjartan. This should be fixed in cvs HEAD now. It would be great if you could test/verify it though. If you see this fixed and no regressions we could apply this to gnome-2-10 too.
Compiled gnome-vfs HEAD now and ran it with a 2.10.x setup from CVS. gweather still yields this leak in the neon stuff: ==19398== 19232 (360 direct, 18872 indirect) bytes in 2 blocks are definitely lost in loss record 134 of 202 ==19398== at 0x3414E222: malloc (vg_replace_malloc.c:130) ==19398== by 0x353A9B44: ne_calloc (ne_alloc.c:64) ==19398== by 0x353ABB04: ah_create (ne_auth.c:1007) ==19398== by 0x353A5E16: ne_request_create (ne_request.c:554) ==19398== by 0x353A2FE3: http_transfer_start (http-neon-method.c:2236) ==19398== by 0x353A3306: do_open (http-neon-method.c:2386) ==19398== by 0x346AF2AE: gnome_vfs_open_uri_cancellable (gnome-vfs-cancellable-ops.c:57) ==19398== by 0x346BB97E: _gnome_vfs_job_execute (gnome-vfs-job.c:964) ==19398== by 0x346BAAC3: thread_routine (gnome-vfs-job-slave.c:64) ==19398== by 0x346CB430: thread_entry (gnome-vfs-thread-pool.c:186) ==19398== by 0x34A72F63: g_thread_create_proxy (gthread.c:561) ==19398== by 0x420B36: start_thread (in /lib/libpthread-2.3.4.so) ==19398== by 0x29563D: clone (in /lib/libc-2.3.4.so)
Pretty much the same as the first one except line 3 from the top is changed...
==5004== 19232 (32 direct, 19200 indirect) bytes in 2 blocks are definitely lost in loss record 6395 of 6754 ==5004== at 0x1B901862: malloc (vg_replace_malloc.c:149) ==5004== by 0x1D1C6A3C: ne_calloc (ne_alloc.c:64) ==5004== by 0x1D1C2B0B: ne_add_response_header_handler (ne_request.c:629) ==5004== by 0x1D1C2CA0: ne_request_create (ne_request.c:532) ==5004== by 0x1D1BFF0F: http_transfer_start (http-neon-method.c:2236) ==5004== by 0x1D1C0222: do_open (http-neon-method.c:2389) ==5004== by 0x1C1696AA: gnome_vfs_open_uri_cancellable (gnome-vfs-cancellable-ops.c:57) ==5004== by 0x1C1735CE: _gnome_vfs_job_execute (gnome-vfs-job.c:964) ==5004== by 0x1C172716: thread_routine (gnome-vfs-job-slave.c:64) ==5004== by 0x1C1820D1: thread_entry (gnome-vfs-thread-pool.c:186) ==5004== by 0x1C7A2D63: g_thread_create_proxy (gthread.c:564) ==5004== by 0x1C757B88: start_thread (in /lib/libpthread-2.3.90.so) ==5004== by 0x1C8AF21D: clone (in /lib/libc-2.3.90.so)
*** Bug 313868 has been marked as a duplicate of this bug. ***
And it's still here: ==7939== 18,956 (344 direct, 18,612 indirect) bytes in 2 blocks are definitely lost in loss record 144 of 217 ==7939== at 0x4004F52: malloc (vg_replace_malloc.c:149) ==7939== by 0x5E4C381: ne_calloc (ne_alloc.c:64) ==7939== by 0x5E4F97B: ah_create (ne_auth.c:1148) ==7939== by 0x5E4801C: ne_request_create (ne_request.c:536) ==7939== by 0x5E459FD: http_transfer_start (http-neon-method.c:2218) ==7939== by 0x5E4608B: do_open (http-neon-method.c:2368) ==7939== by 0x4672458: gnome_vfs_open_uri_cancellable (gnome-vfs-cancellable-ops.c:57) ==7939== by 0x467BAA6: _gnome_vfs_job_execute (gnome-vfs-job.c:963) ==7939== by 0x467B02D: thread_entry_point (gnome-vfs-job-queue.c:66) ==7939== by 0x4A78BCB: g_thread_pool_thread_proxy (gthreadpool.c:158) ==7939== by 0x4A771BE: g_thread_create_proxy (gthread.c:582) ==7939== by 0x6AB275: start_thread (in /lib/libpthread-2.3.90.so) ==7939== by 0x4E206D: clone (in /lib/libc-2.3.90.so) Upping severity since this has been bugging us for several releases now.
Tried again and I still see this in 2.17.5
And with 2.19.92
Closing old stuff as WONTFIX.