dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #15609
Re: [HG DOLFIN] A try to suppress some more annoying mpi valgrind complaints
On Tue, Sep 22, 2009 at 03:11:23PM +0200, Johan Hake wrote:
> On Tuesday 22 September 2009 15:06:22 Garth N. Wells wrote:
> > Johan Hake wrote:
> > > On Tuesday 22 September 2009 14:57:16 DOLFIN wrote:
> > >> One or more new changesets pushed to the primary dolfin repository.
> > >> A short summary of the last three changesets is included below.
> > >>
> > >> changeset: 7134:18c7e560897b
> > >> tag: tip
> > >> user: "Johan Hake <hake@xxxxxxxxx>"
> > >> date: Tue Sep 22 14:57:13 2009 +0200
> > >> files: test/memory/dolfin_valgrind.supp
> > >> description:
> > >> A try to suppress some more annoying mpi valgrind complaints
> > >
> > > In the memtest on the jaunty-amd64 buildbot there are some complaints
> > > related to gts and petsc:
> > >
> > > GTS:
> > >
> > > 72 bytes in 1 blocks are still reachable in loss record 40 of 67
> > > at 0x4C278AE: malloc (vg_replace_malloc.c:207)
> > > by 0x9077A12: g_malloc (in /usr/lib/libglib-2.0.so.0.2000.1)
> > > by 0x908DB07: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.2000.1)
> > > by 0x9061812: g_hash_table_new_full (in
> > > /usr/lib/libglib-2.0.so.0.2000.1) by 0x87D0E82: gts_object_class_new (in
> > > /usr/lib/libgts-0.7.so.5.0.1) by 0x87D0F3E: gts_object_class (in
> > > /usr/lib/libgts-0.7.so.5.0.1) by 0x87DCD0D: gts_bbox_class (in
> > > /usr/lib/libgts-0.7.so.5.0.1) by 0x5043E1E:
> > > dolfin::GTSInterface::create_box(dolfin::Cell const&)
> > > (GTSInterface.cpp:186)
> > > by 0x5043FFD: dolfin::GTSInterface::buildCellTree()
> > > (GTSInterface.cpp:198) by 0x5044134:
> > > dolfin::GTSInterface::GTSInterface(dolfin::Mesh const&)
> > > (GTSInterface.cpp:34)
> > > by 0x502DDA0:
> > > dolfin::IntersectionDetector::IntersectionDetector(dolfin::Mesh const&)
> > > (IntersectionDetector.cpp:30)
> > > by 0x4F67F67: dolfin::FunctionSpace::eval(double*, double const*,
> > > dolfin::Function const&) const (FunctionSpace.cpp:122)
> > >
> > > +++
> > >
> > > PETSc:
> > >
> > > 96 bytes in 2 blocks are indirectly lost in loss record 55 of 67
> > > at 0x4C278AE: malloc (vg_replace_malloc.c:207)
> > > by 0xC6A5059: (within /usr/lib/openmpi/lib/libmpi.so.0.0.0)
> > > by 0xC6D1503: PMPI_Attr_put (in /usr/lib/openmpi/lib/libmpi.so.0.0.0)
> > > by 0x76C6F1D: PetscCommDuplicate(ompi_communicator_t*,
> > > ompi_communicator_t**, int*) (tagm.c:233)
> > > by 0x764612F: PetscHeaderCreate_Private(_p_PetscObject*, int, int,
> > > char const*, ompi_communicator_t*, int (*)(_p_PetscObject*), int (*)
> > > (_p_PetscObject*, _p_PetscViewer*)) (inherit.c:44)
> > > by 0x7318595: VecCreate(ompi_communicator_t*, _p_Vec**)
> > > (veccreate.c:39) by 0x7379278: VecCreateSeq(ompi_communicator_t*, int,
> > > _p_Vec**) (vseqcr.c:38)
> > > by 0x4FE7B82: dolfin::PETScVector::init(unsigned int, unsigned int,
> > > std::string) (PETScVector.cpp:520)
> > > by 0x4FE884B: dolfin::PETScVector::PETScVector(std::string)
> > > (PETScVector.cpp:50)
> > > by 0x5016EEE: dolfin::PETScFactory::create_vector() const
> > > (PETScFactory.cpp:27)
> > > by 0x4F4C2E8:
> > > dolfin::VariationalProblem::solve_linear(dolfin::Function&) (Vector.h:32)
> > > by 0x438CB7: Eval::testArbitraryEval() (test.cpp:73)
> > >
> > > +++
> > >
> > > Are these real leaks or false positives? Can someone with more knowledge
> > > of PETSc and/or GTS look at it?
> >
> > I believe that the first is a libgts issue. The second I don't know. I
> > had a look but I don't see any problems.
> >
> > The supression files are of limited used because they depend on the
> > library versions - the valgrind messages I get on my desktop are
> > slightly different the valgrind messages on the buildbots. This makes
> > sorting out leaks clumsy.
>
> For sure!
>
> However there are ways of expressing general suppressions with the use of *.
> We have tried to do that, but as you say, it is tedious and certainly not fail
> proof.
>
> Should we only run the memtest on one buildbot? The problem are all the
> different configurations we have, which we then do not test.
I think that would be enough. On the other hand, the buildbot seems to
be green now on 3 of 5 platforms.
What's up with the other two?
--
Anders
Attachment:
signature.asc
Description: Digital signature
Follow ups
References