View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002030 | OpenFOAM | [All Projects] Bug | public | 2016-03-18 09:00 | 2016-03-20 10:36 |
| Reporter | projectionist | Assigned To | henry | ||
| Priority | normal | Severity | trivial | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Ubuntu | OS Version | 14.04 |
| Product Version | dev | ||||
| Fixed in Version | dev | ||||
| Summary | 0002030: DebugSwitch objectRegistry leads to segfault at destruction of Time object when the application terminates | ||||
| Description | This 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 Reproduce | Add this to any controlDict and run any application that creates a Time object. DebugSwitches { objectRegistry 1; } | ||||
| Tags | No tags attached. | ||||
|
|
Test-TimeCreationDestruciton.tar.gz (6,124 bytes) |
|
|
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 :) |
|
|
objectRegistry.C (8,615 bytes) |
|
|
Thanks Bruno Resolved by commit 9209192b65c13c52002a46df002ef0ffcb1d7ba3 |
| 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 |
