On Mon, 2005-09-26 at 08:55 -0600, Veerapuram Varadhan wrote: > Hi, > > For the past couple of weeks, I am running valgrind on evolution and I > am using LDTP (http://ldtp.sf.net) to automate test-cases. LDTP > requires accessibility to be enabled. Initially the test runs used to > take long hours to finish or crash. With the much improved LDTP, I am > able to run my test runs without much hassle. > > I have a PIV, 3.0 GHZ with 4GB RAM as the test machine for this > memory-leaks hunting task. > > I am using valgrind with following options for my memory-leaks-hunt. > "valgrind --tool=memcheck --trace-children=yes --track-fds=yes > --show-reachable=yes --error-limit=no -v --log-file=foo.log > evolution-2.4" > > and I am running these tests from a custom built gnome-environment. > (built 2 weeks back) > > During the valgrind run, I found traces like: > > ==27176== > ==27176== 71592 (7408 direct, 64184 indirect) bytes in 463 blocks are > definitely lost in loss record 251 of 274 > ==27176== at 0x1B8FF8A6: malloc (in > /usr/lib/valgrind/vgpreload_memcheck.so) > ==27176== by 0x1B900BF1: realloc (in > /usr/lib/valgrind/vgpreload_memcheck.so) > ==27176== by 0x1C57C418: g_realloc (gmem.c:170) > ==27176== by 0x1C55EBCB: g_array_maybe_expand (garray.c:358) > ==27176== by 0x1C55EDC3: g_array_append_vals (garray.c:146) > ==27176== by 0x1D099321: gail_tree_view_real_initialize > (gailtreeview.c:582) > ==27176== by 0x1C01CA7B: atk_object_initialize (atkobject.c:1272) > ==27176== by 0x1D0993E4: gail_tree_view_new (gailtreeview.c:680) > ==27176== by 0x1D072CCD: gail_tree_view_factory_create_accessible > (gail.c:92) > ==27176== by 0x1C01D030: atk_object_factory_create_accessible > (atkobjectfactory.c:85) > ==27176== by 0x1BED2762: gtk_widget_real_get_accessible > (gtkwidget.c:7577) > ==27176== by 0x1BED26C8: gtk_widget_get_accessible (gtkwidget.c:7559) > ==27176== > > in which, I am not finding any evolution-related calls. This is just a > sample trace of many such traces, > including some bonobo, gtk, xml parser calls. > > I would like to know > > 1) How to debug such traces? > 2) How to report these leaks as bugs and under which module?
you'll first have to figure out where the leak is coming from :) > 3) Are there any other options to valgrind that could give me a more > larger stack trace than this? --num-callers and set a larger value to get more stack info > 4) Any other valgrind options available to fine-tune leak detections? not sure if you still need --alignment=8, but you used to. -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. [EMAIL PROTECTED] - www.novell.com _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
