View Issue Details

IDProjectCategoryView StatusLast Update
0002954OpenFOAMBugpublic2018-07-17 11:23
Reportertoliveira Assigned Tohenry  
Status resolvedResolutionno change required 
PlatformGNU/LinuxOSUbuntuOS Version16.04
Summary0002954: DebugSwitch objectRegistry leads to segfault at destruction of object if its registry has been already destroyed
DescriptionWhen the DebugSwitch objectRegistry is activated, the attached code gives a segmentation fault.

In this code, an autoPtr<fvMesh> is declared, then a Time is declared, and finally the autoPtr<fvMesh> is set to a fvMesh registered on the Time.

Time goes out of scope. When autoPtr<fvMesh> goes out of scope, the fault happens. I guess it happens when the destructor of fvMesh is called but its registry doesn't exist anymore.
Steps To Reproduce1 - Compile attached code with OpenFOAM-5.0
2 - Activate the DebugSwitch objectRegistry
3 - Run the code
Additional InformationThe attached code is meaningless because it was extracted from an application in order to isolate the source of the fault.

This may be related to issue 0002030.

I am not sure if there is a easy way to fix it, or if it is better that the users just avoid this kind of situation.
TagsNo tags attached.



2018-05-23 22:51


Time_has_been_destroyed.C (813 bytes)   
#include "fvCFD.H"

int main(int argc, char *argv[])
    Foam::argList args(argc, argv);

        autoPtr<fvMesh> mesh;

            Foam::Time runTime(Foam::Time::controlDictName, args);

            mesh.set(new Foam::fvMesh
            Info << "Destroy Time runTime" << endl;
        Info << "Destroy autoPtr<fvMesh> mesh" << endl;

    Info << "End" << endl;

    return 0;
Time_has_been_destroyed.C (813 bytes)   


2018-05-23 23:49

manager   ~0009636

I think this is a bug in your code, you have to ensure the mesh is destroyed before the Time it holds a reference to. You might find valgrind useful in debugging this kind of memory and access violation.


2018-05-24 10:37

reporter   ~0009637

I encountered the same issue by running the `incompressible/simpleFoam/motorBike` tutorial. Thus I'm convinced that it's an openfoam bug that needs to be fixed.

Commit 7601e8e86f98d49c8c06c2b3680e62a586dcbc68 on master branch of dev repo.


2018-05-24 10:57

manager   ~0009638

Could you be more specific about the problem you have with the `incompressible/simpleFoam/motorBike` tutorial? The commit 7601e8e86f98d49c8c06c2b3680e62a586dcbc68 does not change either the motorBike tutorial nor the objectRegistry behavior.


2018-05-24 11:29

reporter   ~0009639

> "I think this is a bug in your code, you have to ensure the mesh is destroyed before the Time it holds a reference to."
I think this is a valid interpretation and a fair requirement the user should comply with.

I reported the issue in case you thought it was necessary to do any changes regarding this behaviour in OpenFOAM (such as automatic call of destructors of objects registered on the objectRegistry), and to keep it documented for other users that may encounter this problem.

For the record, with DebugSwitch objectRegistry deactivated, 'valgrind -v --leak-check=full --show-leak-kinds=all' reports no error, just one block still reachable.

Regarding the note by ttocci about 'incompressible/simpleFoam/motorBike', I couldn't find any problem when running it wih OpenFOAM-5.0.


2018-05-24 11:54

manager   ~0009640

> such as automatic call of destructors of objects registered on the objectRegistry

The objectRegistry automatically destroys objects it "owns" but not those which have be created and maintained without transfer of ownership for which the objectRegistry holds references. If you want the objectRegistry to delete the object you create you need to transfer ownership to the objectRegistry.


2018-05-24 12:06

reporter   ~0009641

Henry, thank you very much for the explanation and prompt reply.


2018-05-24 13:32

manager   ~0009642

> I encountered the same issue by running the `incompressible/simpleFoam/motorBike` tutorial

I think this is a different issue and resolved by commit f14637a96594e0afb280ce0aa81a57620b522660


2018-07-17 11:23

manager   ~0009855

I believe this issue is explained and/or resolved. Please open another report with more details if the problem persists.

Issue History

Date Modified Username Field Change
2018-05-23 22:51 toliveira New Issue
2018-05-23 22:51 toliveira File Added: Time_has_been_destroyed.C
2018-05-23 23:49 henry Note Added: 0009636
2018-05-24 10:37 ttocci Note Added: 0009637
2018-05-24 10:57 henry Note Added: 0009638
2018-05-24 11:29 toliveira Note Added: 0009639
2018-05-24 11:54 henry Note Added: 0009640
2018-05-24 12:06 toliveira Note Added: 0009641
2018-05-24 13:32 henry Note Added: 0009642
2018-07-17 11:23 henry Assigned To => henry
2018-07-17 11:23 henry Status new => resolved
2018-07-17 11:23 henry Resolution open => no change required
2018-07-17 11:23 henry Note Added: 0009855