Re: [Evolution-hackers] checking Evolution with valgrind
On Sat, 2008-03-29 at 12:32 -0400, Matthew Barnes wrote: > On Sat, 2008-03-29 at 14:46 +0100, Patrick Ohly wrote: > > My offer still stands: I could add interested developers to CC of the > > emails which report nightly test success or failure. I look at the > > results rather sporadically; this time only two days have passed since > > the tests started to fail, but it could easily be a week or more. > > Sign me up, please. > > Not sure how responsive I'll be at fixing leaks as they emerge, but I'd > like to stay informed at least. Thanks for volunteering. As an example, the attached email was marked in red in my inbox due to an incoming filter which checks for "failed". "evolutiontrunk" is the build step of the latest Evolution source. If it fails, then the other steps are attempted with whatever did compile or is left from a previous compilation. The rationale is that if building the Evolution GUI fails, EDS testing would still run. "client-api" and "syncevolution" are the repository checkouts of these two components; "compile", well, compiles them. When that fails, no tests are run. "evolution" is the part where EDS and the SyncEvolution client are tested - this is what we want to succeed. The rest of the email can be ignored. > Thanks for your efforts here, by the way. It's very much appreciated. Thanks for your kind words. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ --- Begin Message --- http://www.estamos.de/runtests/2008-03-29-10-00/head-evolution-trunk-minimal evolutiontrunk successful client-api successful syncevolution successful compile successful dist skipped: disabled in configuration evolution: CLIENT_TEST_ALARM=1200 CLIENT_TEST_LOG= CLIENT_TEST_EVOLUTION_PREFIX=file:///tmp/runtests/head/work/databases run_garnome /home/patrick/evo-svn/gtk+2.0 /tmp/runtests/head/tmp/evolutiontrunk-result valgrindcheck.sh ./client-test Client::Source: failed (return code 35072) scheduleworld skipped: disabled in configuration egroupware skipped: disabled in configuration synthesis skipped: disabled in configuration funambol skipped: disabled in configuration /home/patrick/bin/runtests.py --client-tag r_tested --configure --enable-static-cxx LDFLAGS=-Wl,--as-needed --prefix=/usr --tmp=/tmp/runtests/head/tmp --workdir=/tmp/runtests/head/work --resultdir=/home/patrick/runtests/2008-03-29-10-00/head-evolution-trunk-minimal --resulturi=http://www.estamos.de/runtests/2008-03-29-10-00/head-evolution-trunk-minimal --shell=run_garnome /home/patrick/evo-svn/gtk+2.0 /tmp/runtests/head/tmp/evolutiontrunk-result --evosvn=trunk=/home/patrick/evo-svn --enable evolutiontrunk --enable compile --enable evolution --test-prefix=valgrindcheck.sh --from [EMAIL PROTECTED] --to [EMAIL PROTECTED] --- End Message --- ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] checking Evolution with valgrind
On Sat, 2008-03-29 at 14:46 +0100, Patrick Ohly wrote: > My offer still stands: I could add interested developers to CC of the > emails which report nightly test success or failure. I look at the > results rather sporadically; this time only two days have passed since > the tests started to fail, but it could easily be a week or more. Sign me up, please. Not sure how responsive I'll be at fixing leaks as they emerge, but I'd like to stay informed at least. Thanks for your efforts here, by the way. It's very much appreciated. Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] checking Evolution with valgrind
On Wed, 2008-03-26 at 15:03 -0400, Matthew Barnes wrote: > On Wed, 2008-03-26 at 19:33 +0100, Patrick Ohly wrote: > > > The best is that if you could track it down to Evolution, file a > bug > > > with the valgrind traces and CC me there. > > > > ... this is exactly what I won't have time for - sorry! I was hoping > > that some other developer would perhaps be motivated to use valgrind to > > analyse some of these problems. > > I run Evolution and E-D-S under valgrind occasionally but haven't made a > regular habit of it. I'll try to start doing that regularly. Great, here's a good reason to fire it up: http://bugzilla.gnome.org/show_bug.cgi?id=524964 Hint: your changes seem to be involved in the use-after-free and ensuing crash found in the nightly testing ;-) My offer still stands: I could add interested developers to CC of the emails which report nightly test success or failure. I look at the results rather sporadically; this time only two days have passed since the tests started to fail, but it could easily be a week or more. The tests still produce new valgrind leak reports for which I don't have suppression rules; in particular the "potentially lost" reports seem to be a bit random. Currently I'm still in the "ignore leaks" mode and just suppress anything that I find. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] checking Evolution with valgrind
On Wed, 2008-03-26 at 19:33 +0100, Patrick Ohly wrote: > I'm afraid it won't help Evolution much apart from catching regressions > from now on, because ... > > > The best is that if you could track it down to Evolution, file a bug > > with the valgrind traces and CC me there. > > ... this is exactly what I won't have time for - sorry! I was hoping > that some other developer would perhaps be motivated to use valgrind to > analyse some of these problems. I run Evolution and E-D-S under valgrind occasionally but haven't made a regular habit of it. I'll try to start doing that regularly. Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] checking Evolution with valgrind
On Tue, 2008-03-25 at 23:44 +0530, Srinivasa Ragavan wrote: > On Tue, 2008-03-25 at 20:58 +0100, Patrick Ohly wrote: > > as part of the nightly testing that I mentioned recently I now also > > started to run evolution-data-server and the test program under > > valgrind, including --leak-check=yes. That covers the file backends for > > calendar and contacts, libical, libecal and libebook. I run with > > GLIBCXX_FORCE_NEW=1 G_SLICE=always-malloc G_DEBUG=gc-friendly > > Oh Patrick, you are doing an awesome job for Evolution. I'm afraid it won't help Evolution much apart from catching regressions from now on, because ... > The best is that if you could track it down to Evolution, file a bug > with the valgrind traces and CC me there. ... this is exactly what I won't have time for - sorry! I was hoping that some other developer would perhaps be motivated to use valgrind to analyse some of these problems. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] checking Evolution with valgrind
On Tue, 2008-03-25 at 20:58 +0100, Patrick Ohly wrote: > Hello, > > as part of the nightly testing that I mentioned recently I now also > started to run evolution-data-server and the test program under > valgrind, including --leak-check=yes. That covers the file backends for > calendar and contacts, libical, libecal and libebook. I run with > GLIBCXX_FORCE_NEW=1 G_SLICE=always-malloc G_DEBUG=gc-friendly Oh Patrick, you are doing an awesome job for Evolution. > > My main motivation is to catch memory leaks inside the client program. > Because I neither have the time nor the necessary insights to clean up > Evolution itself, I rather aggressively suppress all valgrind reports > which don't seem to be caused by my own code. I attach the current > suppression file, just in case that a) another client developer is in > the same situation or b) some of the Evolution developers are interested > in the errors that are found (full stack traces are included as > comments; there are quite some leaks, but also uninitialized memory > accesses). All tests were done with a nightly build of Evolution trunk > on Debian Etch over a period of the last few weeks (I could only work on > it occasionally). The best is that if you could track it down to Evolution, file a bug with the valgrind traces and CC me there. > > Some of the leaks could be explained by SyncEvolution not freeing > resources when it should; unfortunately this does not always show up > with a backtrace that includes the code in SyncEvolution because the > background thread allocates the memory. Is the following code the right > way to free the results of the individual calls? This is what I > currently use after each and every such call that SyncEvolution makes > itself, but I still see leaks for memory allocated in > build_change_list() from libecal. > The addressbook code seems right to me. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] checking Evolution with valgrind
Hello,
as part of the nightly testing that I mentioned recently I now also
started to run evolution-data-server and the test program under
valgrind, including --leak-check=yes. That covers the file backends for
calendar and contacts, libical, libecal and libebook. I run with
GLIBCXX_FORCE_NEW=1 G_SLICE=always-malloc G_DEBUG=gc-friendly
My main motivation is to catch memory leaks inside the client program.
Because I neither have the time nor the necessary insights to clean up
Evolution itself, I rather aggressively suppress all valgrind reports
which don't seem to be caused by my own code. I attach the current
suppression file, just in case that a) another client developer is in
the same situation or b) some of the Evolution developers are interested
in the errors that are found (full stack traces are included as
comments; there are quite some leaks, but also uninitialized memory
accesses). All tests were done with a nightly build of Evolution trunk
on Debian Etch over a period of the last few weeks (I could only work on
it occasionally).
Some of the leaks could be explained by SyncEvolution not freeing
resources when it should; unfortunately this does not always show up
with a backtrace that includes the code in SyncEvolution because the
background thread allocates the memory. Is the following code the right
way to free the results of the individual calls? This is what I
currently use after each and every such call that SyncEvolution makes
itself, but I still see leaks for memory allocated in
build_change_list() from libecal.
e_book_get_changes():
static void unref(GList *pointer) {
if (pointer) {
GList *next = pointer;
do {
EBookChange *ebc = (EBookChange *)next->data;
g_object_unref(ebc->contact);
g_free(next->data);
next = next->next;
} while (next);
g_list_free(pointer);
}
}
e_cal_get_changes():
static void unref(GList *pointer) {
if (pointer) {
GList *next = pointer;
do {
ECalChange *ecc = (ECalChange *)next->data;
g_object_unref(ecc->comp);
g_free(next->data);
next = next->next;
} while (next);
g_list_free(pointer);
}
}
e_book_get_contacts():
e_cal_get_object_list_as_comp():
static void unref(GList *pointer) {
if (pointer) {
GList *next = pointer;
do {
g_object_unref(G_OBJECT(next->data));
next = next->next;
} while (next);
g_list_free(pointer);
}
}
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
evo.supp.bz2
Description: application/bzip
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
