On Wed, 2010-05-19 at 17:01 +0200, Nikola Pajkovsky wrote:
Do same stuff as before. On Wed, 2010-05-19 at 14:55 +0200, Nikola Pajkovsky wrote:
run abrtd -dvvv run gui click on report choose bugzilla plugin try to Refresh all information close gui kill abrtd with ctrl+c
Good to know that SEGV is gone.
I'm looking at leaked data, starting from biggest.
==11292== 7,136 bytes in 1 blocks are possibly lost in loss record 1,000 of 1,003 ==11292== at 0x4A05255: realloc (vg_replace_malloc.c:476) ==11292== by 0x364E828DB9: set_length (dbus-string.c:364) ==11292== by 0x364E82908E: open_gap (dbus-string.c:426) ==11292== by 0x364E829439: copy (dbus-string.c:1456) ==11292== by 0x364E82789A: marshal_len_followed_by_bytes (dbus-marshal-basic.c:741) ==11292== by 0x364E827B63: _dbus_marshal_write_basic (dbus-marshal-basic.c:773) ==11292== by 0x364E814F30: _dbus_type_writer_write_basic (dbus-marshal-recursive.c:1588) ==11292== by 0x364E819735: dbus_message_iter_append_basic (dbus-message.c:2284) ==11292== by 0x4C2CEC0: store_string(DBusMessageIter*, char const*) (abrt_dbus.cpp:154) ==11292== by 0x4147E5: void store_map<std::string, std::string>(DBusMessageIter*, std::map<std::string, std::string, std::lessstd::string, std::allocator<std::pair<std::s ==11292== by 0x41497D: void store_map<std::string, std::map<std::string, std::string, std::lessstd::string, std::allocator<std::pair<std::string const, std::string> > > > ==11292== by 0x41686D: message_received(DBusConnection*, DBusMessage*, void*) (abrt_dbus.h:164)
Three such blocks. "void store_map" part tells that this allocation is part of dbus return value of map type. Need to determine where do we have an unfreed message and whether this is a problem.
==11292== 4,080 bytes in 1 blocks are possibly lost in loss record 993 of 1,003 ==11292== at 0x4A04360: memalign (vg_replace_malloc.c:532) ==11292== by 0x4A043B9: posix_memalign (vg_replace_malloc.c:660) ==11292== by 0x364DC55F57: ??? (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x364DC567DB: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x364DC568F5: g_slice_alloc0 (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x364E42BF6A: g_type_create_instance (in /lib64/libgobject-2.0.so.0.2200.5) ==11292== by 0x364E410D9B: ??? (in /lib64/libgobject-2.0.so.0.2200.5) ==11292== by 0x364E411D80: g_object_newv (in /lib64/libgobject-2.0.so.0.2200.5) ==11292== by 0x364E412808: g_object_new_valist (in /lib64/libgobject-2.0.so.0.2200.5) ==11292== by 0x364E412A4B: g_object_new (in /lib64/libgobject-2.0.so.0.2200.5) ==11292== by 0x365F41DABE: egg_dbus_connection_new_message_for_method_call (in /usr/lib64/libeggdbus-1.so.0.0.0) ==11292== by 0x365F419A62: egg_dbus_bus_add_match (in /usr/lib64/libeggdbus-1.so.0.0.0)
libeggdbus has quite a number of these.
==11292== 1,586 bytes in 42 blocks are possibly lost in loss record 977 of 1,003 ==11292== at 0x4A05974: operator new(unsigned long) (vg_replace_malloc.c:220) ==11292== by 0x365809C2B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.13) ==11292== by 0x365809D09A: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (in /usr/lib64/libstdc++.so.6.0.13) ==11292== by 0x365809D4DB: std::string::reserve(unsigned long) (in /usr/lib64/libstdc++.so.6.0.13) ==11292== by 0x4E48BA2: LoadPluginSettings(char const*, std::map<std::string, std::string, std::lessstd::string, std::allocator<std::pair<std::string const, std::string> ==11292== by 0x406D96: CPluginManager::LoadPlugin(char const*, bool) (PluginManager.cpp:163) ==11292== by 0x408DCC: CPluginManager::LoadPlugins() (PluginManager.cpp:129) ==11292== by 0x417E47: main (Daemon.cpp:824) ==11292== ==11292== 1,646 bytes in 42 blocks are possibly lost in loss record 979 of 1,003 ==11292== at 0x4A05974: operator new(unsigned long) (vg_replace_malloc.c:220) ==11292== by 0x365809C2B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.13) ==11292== by 0x365809D09A: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (in /usr/lib64/libstdc++.so.6.0.13) ==11292== by 0x365809D4DB: std::string::reserve(unsigned long) (in /usr/lib64/libstdc++.so.6.0.13) ==11292== by 0x4E48C49: LoadPluginSettings(char const*, std::map<std::string, std::string, std::lessstd::string, std::allocator<std::pair<std::string const, std::string> ==11292== by 0x406D96: CPluginManager::LoadPlugin(char const*, bool) (PluginManager.cpp:163) ==11292== by 0x408DCC: CPluginManager::LoadPlugins() (PluginManager.cpp:129) ==11292== by 0x417E47: main (Daemon.cpp:824)
Apparently a string object not destroyed. This is somewhat strange, since static object destructors should have freed those. Any thoughts what is can be?
==11292== 1,488 bytes in 3 blocks are possibly lost in loss record 975 of 1,003 ==11292== at 0x4A04360: memalign (vg_replace_malloc.c:532) ==11292== by 0x4A043B9: posix_memalign (vg_replace_malloc.c:660) ==11292== by 0x364DC55F57: ??? (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x364DC56811: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x364DC568F5: g_slice_alloc0 (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x364E42BF6A: g_type_create_instance (in /lib64/libgobject-2.0.so.0.2200.5) ==11292== by 0x364E410D9B: ??? (in /lib64/libgobject-2.0.so.0.2200.5) ==11292== by 0x364E411D80: g_object_newv (in /lib64/libgobject-2.0.so.0.2200.5) ==11292== by 0x364E412808: g_object_new_valist (in /lib64/libgobject-2.0.so.0.2200.5) ==11292== by 0x364E412A4B: g_object_new (in /lib64/libgobject-2.0.so.0.2200.5) ==11292== by 0x365F00AF71: polkit_unix_process_new (in /usr/lib64/libpolkit-gobject-1.so.0.0.0) ==11292== by 0x4E49A9E: polkit_check_authorization(int, char const*) (Polkit.cpp:100)
Similar to libeggdbus, this time it is libpolkit
==11292== 1,488 bytes in 3 blocks are possibly lost in loss record 974 of 1,003 ==11292== at 0x4A04360: memalign (vg_replace_malloc.c:532) ==11292== by 0x4A043B9: posix_memalign (vg_replace_malloc.c:660) ==11292== by 0x364DC55F57: ??? (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x364DC56811: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x364DC13F60: g_ptr_array_sized_new (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x364DC39B2A: g_main_context_new (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x364DC39D1C: g_main_context_default (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x364DC3A664: g_main_loop_new (in /lib64/libglib-2.0.so.0.2200.5) ==11292== by 0x417D6E: main (Daemon.cpp:810)
This is strange. We do this:
GMainLoop* pMainloop = NULL; ... pMainloop = g_main_loop_new(NULL, FALSE); ... run_main_loop(pMainloop); ... if (pMainloop) g_main_loop_unref(pMainloop);
so it should not be happening.
I got curious whether we reached exit cleanly. I look for "exiting" string in the log and I don't see it. This is not good.
I think in order to make this sort of logs more reliable, this needs to be done. First, abrtd should be killed with "killall abrtd', not ^C - I am not sure valgrind handles it correctly.
Second, and more importantly: not every unfreed data is a leak. Example:
const char* printable_string(const char *str) { static char *saved[4]; static unsigned cur_saved = 0; char *dst = unicode_conv_to_printable(str); free(saved[cur_saved]); saved[cur_saved] = dst; cur_saved = (cur_saved + 1) & (ARRAY_SIZE(saved)-1); return dst; }
This function after a few calls always keeps 4 last strings in saved[] array. This is obviously (read the code) not a leak, yet on exit valgrind will complain.
Therefore, in order to find real leaks, you need to perform potentially leaking operation *many times*, and watch for unfreed things which increase linearly.
Therefore, we need two logs:
valgrind --leak-check=full abrtd -dvvv 2>&1 | tee LOG1 (is there an option to save valgrind log to a file?) run gui, click on report, choose bugzilla plugin, press Refresh, close gui killall abrtd
this will be a baseline for comparison, and
valgrind --leak-check=full abrtd -dvvv 2>&1 | tee LOG_MANY run gui, click on report, choose bugzilla plugin, press Refresh, close gui run gui, click on report, choose bugzilla plugin, press Refresh, close gui run gui, click on report, choose bugzilla plugin, press Refresh, close gui run gui, click on report, choose bugzilla plugin, press Refresh, close gui run gui, click on report, choose bugzilla plugin, press Refresh, close gui run gui, click on report, choose bugzilla plugin, press Refresh, close gui run gui, click on report, choose bugzilla plugin, press Refresh, close gui run gui, click on report, choose bugzilla plugin, press Refresh, close gui run gui, click on report, choose bugzilla plugin, press Refresh, close gui run gui, click on report, choose bugzilla plugin, press Refresh, close gui (more repeats - better leak detection resolution) killall abrtd
Now we can compare the logs, and if some thing is reported as leaked ten times more than in LOG1, it likely is a real leak.
crash-catcher@lists.fedorahosted.org