2011/12/20 Guillaume Friloux <[email protected]>: > Hello e people. > > > I think i got a memory leak using e_connman. > Everytime i plug/unplug a network cable on one of my network cards, dbus > sends messages about it. > But everytime its done, it seems to leak some bytes. > > How to reproduce : > - go to trunk/e_dbus/src/bin/ > - run e_dbus_connman0_7x_test > - Plug/Unplug multiple times your network card > > Here is what valgrind tells me : > kuri[@]Jetdail(15:41:02)[~/Apps/e17/e_dbus/src/bin] > $ valgrind --leak-check=full --trace-children=yes ./e_dbus_connman0_7x_test > ---------------------- Cutted useless info ---------------------- > ^CDBG: clean exit. > ==14947== > ==14947== HEAP SUMMARY: > ==14947== in use at exit: 25,641 bytes in 159 blocks > ==14947== total heap usage: 7,095 allocs, 6,201 frees, 2,282,863 bytes > allocated > ==14947== > ==14947== 144 bytes in 1 blocks are definitely lost in loss record 38 of 61 > ==14947== at 0x4C27024: calloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==14947== by 0x5267BE4: _ecore_signal_call (ecore_signal.c:325) > ==14947== by 0x5268134: _ecore_signal_received_process (ecore_signal.c:127) > ==14947== by 0x5261916: _ecore_main_loop_iterate_internal > (ecore_main.c:1842) > ==14947== by 0x5261D9E: ecore_main_loop_begin (ecore_main.c:887) > ==14947== by 0x402F41: main (e_dbus_connman0_7x_test.c:1714) > ==14947==
if this part is a bug, likely not from e_dbus/e_connman. Likely the signal was not dispatched by ecore and ecore_signal_shutdown() does not seem to clean it. however it added an ecore_event, and _ecore_event_shutdown(), if called, should delete all events. last but not least, this ecore_signal.c uses _ecore_event_add() with free_func=NULL, while this turns into _ecore_event_generic_free (free()) for ecore_event_add(), for this underscore version it does not. So who added it would need to check why, svn says that line (333) was changed in http://trac.enlightenment.org/e/changeset/61851 so I'd talk to mike_m. > ==14947== 2,304 (864 direct, 1,440 indirect) bytes in 12 blocks are > definitely lost in loss record 56 of 61 > ==14947== at 0x4C27024: calloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==14947== by 0x5B69956: _dbus_pending_call_new_unlocked > (dbus-pending-call.c:109) > ==14947== by 0x5B5A4EE: dbus_connection_send_with_reply > (dbus-connection.c:3379) > ==14947== by 0x4E34A1B: e_dbus_message_send (e_dbus_message.c:67) > ==14947== by 0x5042C13: e_connman_element_message_send > (e_connman_element.c:1159) > ==14947== by 0x5042EE0: e_connman_element_call_full > (e_connman_element.c:1189) > ==14947== by 0x5042FF1: e_connman_element_sync_properties_full > (e_connman_element.c:1396) > ==14947== by 0x504571E: _e_connman_element_item_register > (e_connman_element.c:469) > ==14947== by 0x5045954: _e_connman_element_iter_get_array > (e_connman_element.c:1261) > ==14947== by 0x5046879: _e_connman_element_property_changed_callback > (e_connman_element.c:2318) > ==14947== by 0x4E3762D: cb_signal_dispatcher (e_dbus_signal.c:272) > ==14947== by 0x4E33593: e_dbus_filter (e_dbus.c:419) ... > So the problem seems to be that in “e_dbus_message_send()”, “pending” > gets allocated, and ends up getting queued in > element->_pending.properties_get by > “e_connman_element_sync_properties_full” in “e_connman_element.c” and > then it is never freed. > > I don't know if the problem is e_connman, or the test program because i > lack knowledge to understand the situation. > same as above, seems a termination/shutdown problem, not runtime leak. as you said e_dbus_message_send() gets added to the list "*pending" that is element->_pending.properties_get. if the function returns from DBus, then e_connman_element_call_dispatch_and_free() is called and it will remove from list and get the memory from data->pending, freeing it at the end. if it's not, then on e_connman_element_unref() it will call e_connman_element_free() and it will call e_connman_element_pending_cancel_and_free(&element->_pending.properties_get); This will call the dispatch_and_free() with an error for every pending call. Then likely the refcount does not get to zero for some reason. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
