View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002954 | OpenFOAM | Bug | public | 2018-05-23 22:51 | 2018-07-17 11:23 |
Reporter | toliveira | Assigned To | henry | ||
Priority | low | Severity | trivial | Reproducibility | always |
Status | resolved | Resolution | no change required | ||
Platform | GNU/Linux | OS | Ubuntu | OS Version | 16.04 |
Summary | 0002954: DebugSwitch objectRegistry leads to segfault at destruction of object if its registry has been already destroyed | ||||
Description | When 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 Reproduce | 1 - Compile attached code with OpenFOAM-5.0 2 - Activate the DebugSwitch objectRegistry 3 - Run the code | ||||
Additional Information | The 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. | ||||
Tags | No tags attached. | ||||
|
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 ( Foam::IOobject ( Foam::fvMesh::defaultRegion, runTime.timeName(), runTime, Foam::IOobject::MUST_READ ) ) ); Info << "Destroy Time runTime" << endl; } Info << "Destroy autoPtr<fvMesh> mesh" << endl; } Info << "End" << endl; return 0; } |
|
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. |
|
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. |
|
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. |
|
> "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. |
|
> 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. |
|
Henry, thank you very much for the explanation and prompt reply. |
|
> I encountered the same issue by running the `incompressible/simpleFoam/motorBike` tutorial I think this is a different issue and resolved by commit f14637a96594e0afb280ce0aa81a57620b522660 |
|
I believe this issue is explained and/or resolved. Please open another report with more details if the problem persists. |
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 |