Maxi,
since your program is crashing in debug mode even before the location where it
crashes in release mode, let's just ignore the release mode issue -- if a
program doesn't run in debug mode, you should not assume that it does anything
reasonable at all in release mode.
> When compiling in debug mode, my results vary, and the program behaves
> unpredictable, even though I run it in serial mode. In this case it fails
> earlier during
>
> |
> std::cout <<"Looped over all levels, performing plain_copy:
> "<<perform_plain_copy <<" or renumbered_plain_copy
> "<<perform_renumbered_plain_copy <<"\n";
> if(perform_plain_copy)
> {
> // In this case, we can simply copy the local range.
> AssertDimension(dst[dst.max_level()].local_size(),src.local_size());
> dst[dst.max_level()].copy_locally_owned_data_from(src);
> return;
> }
> elseif(perform_renumbered_plain_copy)
> {
> // std::cout << "dst_level-size: " <<
> dst[dst.max_level()].local_size()
> << '\n';
> // std::cout << "src-size: " << src.local_size() << '\n';
> Assert(copy_indices_level_mine.back().empty(),ExcInternalError());
> LinearAlgebra::distributed::Vector<Number>&dst_level =
> dst[dst.max_level()];
> for(std::pair<unsignedint,unsignedint>i :this_copy_indices.back())
> dst_level.local_element(i.second)=src.local_element(i.first);
> std::cout <<"Renumbered copy done\n";
> return;
> }
> |
>
> plain_copy is (at some point) equal to 0, resulting in the program choosing
> the second option (perform_renumbered_plain_copy), where it crashes with a
> segfault while evaluating the loop
> |
>
>
> for(std::pair<unsignedint,unsignedint>i :this_copy_indices.back())
> dst_level.local_element(i.second)=src.local_element(i.first);
> |
>
> This behaviour is rather random, and changes at different runs even though
> the
> program was not recompiled.
>
> Why is that happening? Did I forget to initialize something, or is that an
> internal bug?
Is the code you show somewhere in the library, or in your application code? In
those cases where it crashes, is this_copy_indices.size()==0, so that the call
to .back() yields nonsense?
As to why this happens, and does so only intermittently, I don't know. A
common cause is that some earlier piece of code (accidentally) overwrites
data. But I can of course only speculate.
Best
W.
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/2c39ac99-b88e-224d-7e71-7a5679e87f09%40colostate.edu.
