View Issue Details

IDProjectCategoryView StatusLast Update
0002030OpenFOAM[All Projects] Bugpublic2016-03-20 10:36
ReporterprojectionistAssigned Tohenry 
PrioritynormalSeveritytrivialReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSUbuntuOS Version14.04
Product Versiondev 
Fixed in Versiondev 
Summary0002030: DebugSwitch objectRegistry leads to segfault at destruction of Time object when the application terminates
DescriptionThis is a rather academic bug report. Not only does the bug only appear when activating the debugging switch, it was also found in my former office at university by a colleague.

When the debug switch for objectRegistry is activated, (most probably) the debug output leads to a segmentation fault. I suspect that the debug output code wants to access information already destructed, as the error happens upon destruction of the Time object.

I added a stripped down version of the volField test application to demonstrate this bug in isolation. However, I presume that the bug affects every application that creates a Time object.
Steps To ReproduceAdd this to any controlDict and run any application that creates a Time object.

DebugSwitches
{
    objectRegistry 1;
}
TagsNo tags attached.

Activities

projectionist

2016-03-18 09:00

reporter  

Test-TimeCreationDestruciton.tar.gz (6,124 bytes)

wyldckat

2016-03-19 16:31

updater   ~0006041

Last edited: 2016-03-19 19:52

View 2 revisions

I was curious about this and here's what I found:

 1- The crash occurs when the destructor "~regIOobject()" calls the inherited "IOobject::path()" method, after the "~Time()" has been fully destroyed.

 2- More specifically, because the "IOobject::path()" method calls "db_.dbDir()", because "instance().isAbsolute() == false". But given that the "db_" has been destroyed, the crash occurs.


The following seems the simplest and most elegant fix I could think of:

    @@ -55,7 +55,7 @@ Foam::objectRegistry::objectRegistry
            IOobject
            (
                string::validate<word>(t.caseName()),
    - "",
    + t.path(),
                t,
                IOobject::NO_READ,
                IOobject::AUTO_WRITE,

Attached is the file "objectRegistry.C" for "src/OpenFOAM/db/objectRegistry/", indexed to the latest OpenFOAM-dev (commit e80917154) (edit: sorry, I forgot to update the copyright date).

This essentially turns the Time-objectRegistry to have a full "instance", resulting in "instance().isAbsolute() == true" and consequently no longer crashing.


Now, the problem is this: I don't know and I can't find any repercussions for this change, given that there could be any somewhat weirdly programmed situations where it's checking for the "instance" to be empty, in order to deduce if it's the main time object or not. A quick search for the calls to "instance()" did not return any such scenarios, but it could be hidden elsewhere.

I could find that the initial object name was only defined as of OpenFOAM 1.5(.0), because before that both path and name were empty. Therefore, I can't be 100% certain as to why was originally defined as an empty string. It does make some sense, since it's the base of the registry tree, but still... the tree should be aware of where it stands :)

wyldckat

2016-03-19 16:31

updater  

objectRegistry.C (8,615 bytes)

henry

2016-03-20 10:36

manager   ~0006046

Thanks Bruno
Resolved by commit 9209192b65c13c52002a46df002ef0ffcb1d7ba3

Issue History

Date Modified Username Field Change
2016-03-18 09:00 projectionist New Issue
2016-03-18 09:00 projectionist File Added: Test-TimeCreationDestruciton.tar.gz
2016-03-19 16:31 wyldckat Note Added: 0006041
2016-03-19 16:31 wyldckat File Added: objectRegistry.C
2016-03-19 19:52 wyldckat Note Edited: 0006041 View Revisions
2016-03-20 10:36 henry Note Added: 0006046
2016-03-20 10:36 henry Status new => resolved
2016-03-20 10:36 henry Fixed in Version => dev
2016-03-20 10:36 henry Resolution open => fixed
2016-03-20 10:36 henry Assigned To => henry