Comment 64 for bug 1235649

I can now recreate the memory bloat using a basic NIH D-Bus server program and associated client program.

1) Run the server as:

        $ ./test_nih_dbus_server unix:abstract=/com/hunt/james/foo com.hunt.james.Foo /com/hunt/james/Foo

2) Run the client as:

        $ ./test_nih_dbus_client unix:abstract=/com/hunt/james/foo com.hunt.james.Foo

3) Run the updated spammer as:

        $ ./spam_dbus_server.sh

4) Run top and watch the memory used by test_nih_dbus_server creep up.

The problem seems to be caused by the call to notify_clients() - this sends a signal to every connected client every time the spam_dbus_server.sh sends its data to the server. Commenting out the call to notify_clients() stop the memory bloating issue.

The function echo_handled() that is called by notify_clients() is analogous to control_emit_event_emitted() in Upstart parlance.

Again, running valgrind on the server shows the same stack traces as above:

==30015== 91,750,175 bytes in 7,617 blocks are still reachable in loss record 164 of 164
==30015== at 0x402BB88: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==30015== by 0x408E778: dbus_realloc (dbus-memory.c:678)
==30015== by 0x408F08C: reallocate_for_length (dbus-string.c:349)
==30015== by 0x408F12B: set_length (dbus-string.c:390)
==30015== by 0x408F1A9: open_gap (dbus-string.c:411)
==30015== by 0x408FA67: copy (dbus-string.c:1198)
==30015== by 0x408FCCE: _dbus_string_copy_len (dbus-string.c:1368)
==30015== by 0x408DCF8: marshal_len_followed_by_bytes (dbus-marshal-basic.c:726)
==30015== by 0x408DD95: marshal_string (dbus-marshal-basic.c:758)
==30015== by 0x408DF60: _dbus_marshal_write_basic (dbus-marshal-basic.c:840)
==30015== by 0x4075CD7: _dbus_type_writer_write_basic_no_typecode (dbus-marshal-recursive.c:1601)
==30015== by 0x40768BB: _dbus_type_writer_write_basic (dbus-marshal-recursive.c:2323)