On Tue, Oct 15, 2013 at 08:19:53AM -0000, James Hunt wrote:
> Once again, the biggest offender by a huge margin is dbus:
> ==15329== 1,153,679,208 bytes in 12,025 blocks are still reachable in loss record 208 of 208
> ==15329== at 0x402BB88: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==15329== by 0x408E778: dbus_realloc (dbus-memory.c:678)
> ==15329== by 0x408F08C: reallocate_for_length (dbus-string.c:349)
> ==15329== by 0x408F12B: set_length (dbus-string.c:390)
> ==15329== by 0x408F1A9: open_gap (dbus-string.c:411)
> ==15329== by 0x408FA67: copy (dbus-string.c:1198)
> ==15329== by 0x408FCCE: _dbus_string_copy_len (dbus-string.c:1368)
> ==15329== by 0x408DCF8: marshal_len_followed_by_bytes (dbus-marshal-basic.c:726)
> ==15329== by 0x408DD95: marshal_string (dbus-marshal-basic.c:758)
> ==15329== by 0x408DF60: _dbus_marshal_write_basic (dbus-marshal-basic.c:840)
> ==15329== by 0x4075CD7: _dbus_type_writer_write_basic_no_typecode (dbus-marshal-recursive.c:1601)
> ==15329== by 0x40768BB: _dbus_type_writer_write_basic (dbus-marshal-recursive.c:2323)
Yet this backtrace is still deep in the dbus internals and shows us nothing
about who the actual caller is that's causing the leak. Can you please run
this with --num-callers=20 so we can see why these strings are actually
being allocated?
On Tue, Oct 15, 2013 at 08:19:53AM -0000, James Hunt wrote:
> Once again, the biggest offender by a huge margin is dbus:
> ==15329== 1,153,679,208 bytes in 12,025 blocks are still reachable in loss record 208 of 208 valgrind/ vgpreload_ memcheck- x86-linux. so) for_length (dbus-string.c:349) c:1198) copy_len (dbus-string. c:1368) len_followed_ by_bytes (dbus-marshal- basic.c: 726) basic.c: 758) write_basic (dbus-marshal- basic.c: 840) writer_ write_basic_ no_typecode (dbus-marshal- recursive. c:1601) writer_ write_basic (dbus-marshal- recursive. c:2323)
> ==15329== at 0x402BB88: realloc (in /usr/lib/
> ==15329== by 0x408E778: dbus_realloc (dbus-memory.c:678)
> ==15329== by 0x408F08C: reallocate_
> ==15329== by 0x408F12B: set_length (dbus-string.c:390)
> ==15329== by 0x408F1A9: open_gap (dbus-string.c:411)
> ==15329== by 0x408FA67: copy (dbus-string.
> ==15329== by 0x408FCCE: _dbus_string_
> ==15329== by 0x408DCF8: marshal_
> ==15329== by 0x408DD95: marshal_string (dbus-marshal-
> ==15329== by 0x408DF60: _dbus_marshal_
> ==15329== by 0x4075CD7: _dbus_type_
> ==15329== by 0x40768BB: _dbus_type_
Yet this backtrace is still deep in the dbus internals and shows us nothing
about who the actual caller is that's causing the leak. Can you please run
this with --num-callers=20 so we can see why these strings are actually
being allocated?