I have good news and bad news. Good news is that I found where the problem
lies.
Bad news -- it's deal.II@master.
I did two fresh builds of deal.II on Ubuntu with Candi -- one 8.4.1 and one
@master.
8.4.1 runs fine, @master gives this ugly error.
Bisection in process...
On Tuesday, September 6, 2016 at 11:19:17 AM UTC+2, Denis Davydov wrote:
>
> Hi Wolfgang,
>
> Attached is the error log.
>
> Regards,
> Denis.
>
> On Tuesday, September 6, 2016 at 11:06:23 AM UTC+2, Wolfgang Bangerth
> wrote:
>>
>> Denis
>> Can you post the error message and back trace you get?
>> Best
>> Wolfgang
>>
>>
>> -------- Original message --------
>> From: Denis Davydov <davy...@gmail.com>
>> Date:09/06/2016 02:44 (GMT-07:00)
>> To: "deal.II developers" <dealii-d...@googlegroups.com>
>> Subject: [dealii-developers] MPI_InitFinalize / active_cell_iterator /
>> double free or corruption
>>
>> 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-develop...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=CwMFaQ&c=ODFT-G5SujMiGrKuoJJjVg&r=KkOrCga5IcWjxrpeTIn1nmQG6jJSnwzdZwfNniMeeCc&m=i0BtibjfmPV3wSHod94Wv66Y54qB8dpYaW_t4TvAry4&s=0IDCRR_cEHJyCoLRjGPcYRH-Th6EgIXXdjE5Vi7L7ro&e=>
>> .
>>
>
--
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.
