seg fault when main_main function is not used
I am working with the amrex/Tutorials/Particles/NeighborList example where I made a minor change. I removed the use of the main_main function in main.cpp and directly used the code from it within. See modification in my fork - https://github.com/hsitaram/amrex/blob/development/Tutorials/Particles/NeighborList/main.cpp
The case ran the prescribed number of time steps but finished with a segfault. I also used gdb to inspect where it happens -
Program received signal SIGSEGV, Segmentation fault.
free (pt=
I noticed the use a similar paradigm in other examples as well where a main_main or a scope separation is used away from amrex::initialize and finalize. I am curious to know why this happening? - is this unexpected or known behavior?
Yes, this is known behavior. See the last paragraph in this section of the documentation: https://amrex-codes.github.io/amrex/docs_html/Basics.html#initialize-and-finalize
Maybe we could do something to make it more friendly. Instead of completely deleting the Arenas, maybe we could leave them in a state that free can still be called without error.
Thank you very much @maxpkatz and @WeiqunZhang for your replies. Missed that bit in the documentation.
Document my thoughts here. amrex::Finalize could turn on a flag in Arena. After the flag is on, Arena::free will call delete this if it's supposed to be the last one. For CArena, we keep track of all the alloc and free calls. So it's easy to know if a call to free is the last or not. Bur BArena is currently a thin wrapper without any information on the number of calls to alloc and free. We will have to add some stats to it.
Note that delete this from a member function is legal. https://isocpp.org/wiki/faq/freestore-mgmt#delete-this
Another way to do it would just be to assert if we're calling something in Arena after we have finalized (which could be checked with a static variable).
Yes, we could do that too. Probably much simpler.