Dear all,

I just came across a very interesting problem with (active) cell iterator 
being used as a member of a class in a library

  template <int dim>
  class Atom
  {
  public:
    Atom();
    typename dealii::DoFHandler<dim>::active_cell_iterator parent_cell;
  };


This leads to double free or corruption on GCC in Release mode only. 
The code runs on Clang both in Debug and Release modes.

The prerequisites are as follows (if any of those is not the case, problem 
disappears!)
1. use Utilities::MPI::MPI_InitFinalize  in .cc file
2. In the user library, have a default constructor for a class, which 
contains DoFHandler<dim>::active_cell_iterator
3. link .cc against the library, do not declare and define the class 
directly inside .cc

Attached is a one-dummy-class library with a dummy test which demonstrates 
the issue.
Using GCC it should be enough to do the normal sequence of : cmake / make / 
make test
to see the problem.

Given that DoFHandler<dim>::active_cell_iterator has a default constructor,
I think one should not see a problem with encapsulating this class inside a 
user class.

It could still be my mistake somewhere, but I squeezed the code so much, 
that
I simply fail to see what could be wrong here. Especially given the 
prerequisites above.

If the attached code turns out to be fine, then we would have to
(i)  find out the origin of the problem inside deal.II
(ii) find out how to add a unit test which builds a library and an 
executable

Regards,
Denis.

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: init_finalize.tar.gz
Description: Binary data

Reply via email to