--- Comment #16 from pohly <patrick.ohly(a)intel.com> 2009-10-20 00:53:17 ---
(In reply to comment #14)
> Either we write suppressions for these problems or we must
configure valgrind to only
> trace our binary (might be hard).
We have to add *too many* suppressions if using suppressions.
How many errors did you find? Looking at tonight's "scheduleworld" run I
one error for /usr/lib/bonobo-activation/bonobo-activation-server and one for
an unknown binary. Everything else is in SyncEvolution. "Everything" luckily
isn't that much: one leak related to libical.
This doesn't look that bad.
What is more annoying is that multiple processes writing into the same valgrind
file seem to add nul bytes to the file. This is visible when viewing with
"less" and makes me wonder whether the output is really complete.
So, here are two ideas how we can avoid this:
* compile the "testing" binaries with --disable-shared --enable-static to
avoid the libtool wrapper script, then stop using --trace-children=yes
* run the bonobo-activation-server in advance, so that valgrind doesn't
I'll have a look at this.
(In reply to comment #15)
> I found several problems:
> - valgrind is run on the libtool shell wrapper with --trace-children=no,
> so it never checked our code; fixed
> - in
A problem is that the nightly test could not be completed in the same day it
starts because valgrind make apps running slowly.
Is that a real problem for us or hypothetical? Tonight's run hasn't completed
yet, but that isn't unusual. valgrind is a indeed a problem for CPU bound code,
but we are mostly limited by IO performance and the obligatory sleeps() that we
need to not overload servers and for the time-based change tracking.
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.