gemshub/gems3k

gems3k's Issues

occasional segmentation fault when using the TNode class

Hi!

I briefly spoke about this to @gdmiron at the Conference the other week. I am in the process of developing reactive transport models using either GEMS or Reaktoro, and ran into an issue with GEMS a while back:

When I execute my code, everything works as expected, but during the shutdown of the process, i sometimes get a segmentation fault from GEMS, which i believe has to do with the deletion of the TNode pointer. The simplest example i can come up with is a version of the gemcalc example:

#include <ctime>
#include <cmath>
#include <string>
#include <memory>
#include <iostream>
#include <iomanip>
#include <node.h>
#include <spdlog/spdlog.h>

int main()
{
        std::shared_ptr<TNode> node( new TNode() );
        if(  node->GEM_init( "tp_test/H2O-dat.lst" ) )
        {
            std::cout << "error occured during reading the files" << std::endl;
            return 1;
        }

        // Segmentation Fault/Bad Access occurs only if GEM_run is used, so probably caused somewhere in here?
        long NodeStatusCH = node->GEM_run( false );
        
        return 0;
}

I use a super simple chemical system here (just 1 mol H2O, 25°C, 1bar), here are the IO-files: tp_test.zip

Running the above script returns:

[gems3k] [info] Home directory is /Users/jengelmann
[tnode] [info] Initialization of system water     G  H2O         0    0       1       25      0   
[1]    21360 segmentation fault  ./gemcalc

about half of the time, the other half it just runs.

Debugging with lldb in vscode results in a EXC_BAD_ACCESS, also about half of the time. This is the call stack:

tiny_free_list_remove_ptr (@tiny_free_list_remove_ptr:31)
tiny_free_no_lock (@tiny_free_no_lock:268)
free_tiny (@free_tiny:127)
TNode::~TNode() (/Users/name/GEMS3K/NEW_test/GEMS3K/node.cpp:100)
std::__1::default_delete<TNode>::operator()[abi:v160006](TNode*) const (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/__memory/unique_ptr.h:65)
std::__1::__shared_ptr_pointer<TNode*, std::__1::shared_ptr<TNode>::__shared_ptr_default_delete<TNode, TNode>, std::__1::allocator<TNode>>::__on_zero_shared() (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/__memory/shared_ptr.h:246)
std::__1::__shared_count::__release_shared[abi:v160006]() (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/__memory/shared_ptr.h:157)
std::__1::__shared_weak_count::__release_shared[abi:v160006]() (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/__memory/shared_ptr.h:198)
std::__1::shared_ptr<TNode>::~shared_ptr[abi:v160006]() (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/__memory/shared_ptr.h:745)
std::__1::shared_ptr<TNode>::~shared_ptr[abi:v160006]() (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/c++/v1/__memory/shared_ptr.h:743)
main (/Users/name/GEMS3K/NEW_test/gemcalc_SegFault/main.cpp:66)
start (@start:593)

I can avoid this issue by adding set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address") into my CMakeLists.txt, but this fix is not compatible with the transport part of my code.

Can you reproduce the issue? I work on an ARM Mac on the latest trunk branch of GEMS from this repository.