DirichletBC::is_compatible and BoundaryCondition::check_arguments not working

[Timothée Lecomte]

Dear Dolfin devs,

I get a segfault when running a dolfin script. The segfault is not permanent, indicating an invalid memory access that might sometimes be valid by chance. (Somehow the memory patterns must have changed between dolfin 1.0 and 1.1 since I cannot remember getting any segfaults with dolfin 1.0, but I believe the underlying problem may affect both branches of dolfin).

This is obtained running dolfin from trunk (built with dorsal) on MacOS X 10.6.8 (64 bits).

When the segfault appears, the stack trace consistently shows :

Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libdolfin.1.1.dylib 0x0000000103752d6e dolfin::DirichletBC::compute_bc_topological(boost::unordered::unordered_map<unsigned long, double, boost::hash<unsigned long>, std::equal_to<unsigned long>, std::allocator<std::pair<unsigned long const, double> > >&, dolfin::BoundaryCondition::LocalData&) const + 1726 (DirichletBC.cpp:813)
1 libdolfin.1.1.dylib 0x00000001037533c3 dolfin::DirichletBC::compute_bc(boost::unordered::unordered_map<unsigned long, double, boost::hash<unsigned long>, std::equal_to<unsigned long>, std::allocator<std::pair<unsigned long const, double> > >&, dolfin::BoundaryCondition::LocalData&, std::string) const + 323 (Timer.h:62)
2 libdolfin.1.1.dylib 0x0000000103753748 dolfin::DirichletBC::apply(dolfin::GenericMatrix*, dolfin::GenericVector*, dolfin::GenericVector const*) const + 264 (basic_string.h:493)
3 _fem.so 0x0000000110c944c1 _wrap_DirichletBC_apply__SWIG_2 + 497 (modulePYTHON_wrap.cxx:1437)
4 _fem.so 0x0000000110cc86ff _wrap_DirichletBC_apply + 255 (modulePYTHON_wrap.cxx:20873)
5 org.python.python 0x00000001000c1f99 PyEval_EvalFrameEx + 25849

I run my full script under Valgrind and found a single "invalid write" problem in DirichletBC.apply. I managed to get the following minimal script to reproduce this 'invalid write' (note that this script does not produce a segfault, probably because h is not used after the BC has been applied) :

import sys
from dolfin import *

mesh = RectangleMesh (0, 0, 1., 1., 16, 16)

V = VectorFunctionSpace(mesh, "CG", 2)
Q = FunctionSpace(mesh, "CG", 1)
W = V * Q

u = Function(W) # with this line commented, the invalid write is still here, but the pattern is slightly different

g = Function(V)
bc = DirichletBC(W.sub(0), g, lambda x, on_boundary: on_boundary) # the bug disappears when W.sub(0) is replaced by V

h = Function(V)

print "Bug is here !"
sys.stderr.write("1\n")
bc.apply(h.vector()) # error is here !!
sys.stderr.write("2\n")

I run the above script using valgrind to track the memory problem (valgrind --trace-children=yes --suppressions=valgrind-python.supp --dsymutil=yes python test_segfault.py 2> valgrind-log.txt). The output file is attached. The interesting part is :

1
==32808== Invalid write of size 8
==32808== at 0x10615EDFF: VecSetValues_Seq(_p_Vec*, int, int const*, double const*, InsertMode) (in /Users/tlecomte/FEniCS-Dorsal-stable/lib/libpetsc.dylib)
==32808== by 0x10618178B: VecSetValues(_p_Vec*, int, int const*, double const*, InsertMode) (in /Users/tlecomte/FEniCS-Dorsal-stable/lib/libpetsc.dylib)
==32808== by 0x1046D7A70: dolfin::DirichletBC::apply(dolfin::GenericMatrix*, dolfin::GenericVector*, dolfin::GenericVector const*) const (DirichletBC.cpp:530)
==32808== by 0x116402C0E: _wrap_DirichletBC_apply (modulePYTHON_wrap.cxx:20553)
...
==32808== Address 0x100d37a60 is not stack'd, malloc'd or (recently) free'd
2

So, the problem is when applying a boundary condition defined on a subspace of a mixed space (W.sub(0) in the example) on a function defined on the original subspace (V in the example). If the boundary condition is defined on V directly, there is no issue.

Thank you in advance for your help.

Best regards,

Timothée Lecomte

P.S. : Additionaly, I sometimes get an additional 'invalid read' for the same script, but I believe that this one may be fixed when the first one will be fixed :

==15643== Invalid read of size 8
==15643== at 0x1046E1B50: boost::unordered::unordered_map<unsigned long, unsigned long, boost::hash<unsigned long>, std::equal_to<unsigned long>, std::allocator<std::pair<unsigned long const, unsigned long> > >::~unordered_map() (in /Users/tlecomte/FEniCS-Dorsal-stable/lib/libdolfin.1.1.0.dylib)
==15643== by 0x1046E0F60: dolfin::DofMap::~DofMap() (in /Users/tlecomte/FEniCS-Dorsal-stable/lib/libdolfin.1.1.0.dylib)
==15643== by 0x104733118: dolfin::FunctionSpace::~FunctionSpace() (in /Users/tlecomte/FEniCS-Dorsal-stable/lib/libdolfin.1.1.0.dylib)
==15643== by 0x104733EEF: std::_Rb_tree<std::vector<unsigned long, std::allocator<unsigned long> >, std::pair<std::vector<unsigned long, std::allocator<unsigned long> > const, boost::shared_ptr<dolfin::FunctionSpace> >, std::_Select1st<std::pair<std::vector<unsigned long, std::allocator<unsigned long> > const, boost::shared_ptr<dolfin::FunctionSpace> > >, std::less<std::vector<unsigned long, std::allocator<unsigned long> > >, std::allocator<std::pair<std::vector<unsigned long, std::allocator<unsigned long> > const, boost::shared_ptr<dolfin::FunctionSpace> > > >::_M_erase(std::_Rb_tree_node<std::pair<std::vector<unsigned long, std::allocator<unsigned long> > const, boost::shared_ptr<dolfin::FunctionSpace> > >*) (in /Users/tlecomte/FEniCS-Dorsal-stable/lib/libdolfin.1.1.0.dylib)
==15643== by 0x104732FEB: dolfin::FunctionSpace::~FunctionSpace() (in /Users/tlecomte/FEniCS-Dorsal-stable/lib/libdolfin.1.1.0.dylib)
==15643== by 0x10472CA11: dolfin::Function::~Function() (in /Users/tlecomte/FEniCS-Dorsal-stable/lib/libdolfin.1.1.0.dylib)
...
==15643== Address 0xc01bb8289521fbf4 is not stack'd, malloc'd or (recently) free'd

[Jan Blechta (blechta)]

You've answered by yourself - you can't apply DirichletBC(V1, ....) on Function(V2). Spaces involved must be same.

The bug is that:
-bool DirichletBC::is_compatible(GenericFunction& v) const
    doesn't work at the moment,
-void BoundaryCondition::check_arguments(GenericMatrix* A, GenericVector* b,
                                        const GenericVector* x) const
    doesn't work for subspaces at the moment,
so no check for compatibility is performed.

Jan