Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

occasional segmentation fault when using the TNode class #39

Open
j-engelmann opened this issue Jun 17, 2024 · 0 comments
Open

occasional segmentation fault when using the TNode class #39

j-engelmann opened this issue Jun 17, 2024 · 0 comments
Assignees

Comments

@j-engelmann
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants