|
From: Dan K. <da...@ke...> - 2003-07-06 02:32:58
|
I've been getting more and more use out of Valgrind while trying to reproduce bugs reported by others in OpenOffice. The curious can search the OpenOffice bug tracking database for mentions of Valgrind here: http://www.openoffice.org/project/www/issues/buglist.cgi?issue_type=DEFECT&long_desc=valgrind&long_desc_type=substring So far it's mentioned in 16 bugs, and has been crucial to reproducing about half of them. I needed it twice today, nothing else would do. Thanks, guys! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Julian S. <js...@ac...> - 2003-07-06 12:26:45
|
Dan
Great that you're working on OO. It's an important project. I used
1.1beta2 recently to make a couple of presentations and think it a great
improvement on the 1.0.X series.
A couple of comments:
1. ==5982== pthread_mutex_destroy: mutex is still in use
==5982== at 0x410D2D2D: pthread_error (vg_libpthread.c:292)
==5982== by 0x410D3BEB: __pthread_mutex_destroy (vg_libpthread.c:1002)
==5982== by 0x412EA2AE: closedir (in /lib/libc-2.2.93.so)
I believe this to be a glibc thing, in that glibc thinks that destroying a
mutex implicitly unlocks it. I don't think this is a sign of trouble in
OO.
2. Comparing runs of 1.1beta2 vs 1.0.3 on Valgrind, I get the impression
that 1.1 allocates many fewer blocks than 1.0.3 does (perhaps a 1/3 the
number). I'm not sure that this is accurate. However, it did make me
wonder if OO is using some internal memory manager that V does
not understand, rather than the standard malloc/new/new[] and
free/delete/delete[] ones? If so, that will hinder V's ability to
detect problems.
3. Does OO (or at least some of its components) have some automated
testsuite which could be run under V ? Running regression tests on V
seems to have been an effective way to look for problems in other
projects. It would be nice to know that OO ran all its regression tests
(etc, assuming there are such) in a V-clean way.
Promoting V use in the OO developer community can only be a good
thing, I reckon.
J
|
|
From: Dan K. <da...@ke...> - 2003-07-06 15:59:28
|
Julian Seward wrote: > Dan > > Great that you're working on OO. It's an important project. I used > 1.1beta2 recently to make a couple of presentations and think it a great > improvement on the 1.0.X series. > > A couple of comments: > > 1. ==5982== pthread_mutex_destroy: mutex is still in use > ==5982== at 0x410D2D2D: pthread_error (vg_libpthread.c:292) > ==5982== by 0x410D3BEB: __pthread_mutex_destroy (vg_libpthread.c:1002) > ==5982== by 0x412EA2AE: closedir (in /lib/libc-2.2.93.so) > > I believe this to be a glibc thing, in that glibc thinks that destroying a > mutex implicitly unlocks it. I don't think this is a sign of trouble in > OO. Right. It's fixed in glibc-2.3.2 or so. Similarly, there are a couple STL errors V always finds on startup of OOo that are probably gcc bugs. I always remove all of those from any valgrind logs I send to the OOo developers, > 2. Comparing runs of 1.1beta2 vs 1.0.3 on Valgrind, I get the impression > that 1.1 allocates many fewer blocks than 1.0.3 does (perhaps a 1/3 the > number). I'm not sure that this is accurate. However, it did make me > wonder if OO is using some internal memory manager that V does > not understand, rather than the standard malloc/new/new[] and > free/delete/delete[] ones? If so, that will hinder V's ability to > detect problems. Er, I dunno... maybe when some real OOo developers start using V more heavily, they can look at this and comment. > 3. Does OO (or at least some of its components) have some automated > testsuite which could be run under V ? Running regression tests on V > seems to have been an effective way to look for problems in other > projects. It would be nice to know that OO ran all its regression tests > (etc, assuming there are such) in a V-clean way. OOo does have an automated testsuite, and I proposed last night on the de...@qa... list that we should require OOo pass that test under Valgrind before release. No reaction yet. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |