Valgrind and evolution

["Veerapuram Varadhan" <vvaradhan novell com>]

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?
  3) Are there any other options to valgrind that could give me a more
larger stack trace than this?
  4) Any other valgrind options available to fine-tune leak detections?

(Will be putting up these stack traces in go-evolution.org in a day or
two).

I am mailing this to both evolution-hackers and Desktop-devel-list, to
get pointers on where such queries should land.

TIA,

V. Varadhan