View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001559 | OpenFOAM | Bug | public | 2015-03-06 03:23 | 2015-06-15 17:52 |
| Reporter | Assigned To | henry | |||
| Priority | low | Severity | minor | Reproducibility | sometimes |
| Status | closed | Resolution | no change required | ||
| Platform | GNU/Linux | OS | CentOS | OS Version | 6.5 |
| Summary | 0001559: Segmentation fault when destructing IOdictionary | ||||
| Description | I created a minimal working example in which a static local singleton class has an IOdictionary data member. When the singleton (and thereby, the IOdictionary) is destructed, Foam::HashTable::nElmts_ is negative, and Foam::HashTable<T, Key, Hash>::find(const Key&) causes a segmentation fault. | ||||
| Steps To Reproduce | A minimal working example and a GDB output are attached. I am not very familiar with the inner workings of OpenFOAM, but I will do my best. To produce the bug, I used g++ 4.8.1 with WM_COMPILE_OPTION=Debug. In the MWE, when the program reaches the end of main(), the Singleton class is destructed, which in turn destructs the class data member dict_. Following the GDB stack trace, at the point where the seg fault happens, HashTable.C:143 reports a value of nElmts_ equal to -172155104, which does not sound right to me. In HashTable.C:147, table_[hashIdx] then corresponds to an invalid memory location. | ||||
| Additional Information | These steps prevent the bug, but it is unclear to me why. - Uncommenting line 51 of the MWE—so as to call checkOut() manually on the IOdictionary prior to the IOdictionary destructor call. - Changing Singleton into a regular non-singleton class, by making the constructor (line 27) and destructor (line 40) public and calling the constructor directly in main() (line 50). Also, I was unable to reproduce this problem on another machine (Springdale Linux 6.6, OpenFOAM 2.3.1, compiled with g++ 4.8.2 and WM_COMPILE_OPTION=Opt). It is entirely possible that the problem is with my machine. | ||||
| Tags | No tags attached. | ||||
|
2015-03-06 03:23
|
|
|
|
Two mistakes in the issue report—my apologies. First, to run the example, you need to have a dictionary named "dict" in system/. The entries of dict are irrelevant. Second, the line numbers were wrong in "Additional Information". Let me try again: These steps prevent the bug, but it is unclear to me why. - Uncommenting line 53 of the MWE—so as to call checkOut() manually on the IOdictionary prior to the IOdictionary destructor call. - Changing Singleton into a regular non-singleton class, by making the constructor (line 27) and destructor (line 41) public and calling the constructor directly in main() (line 52). |
|
|
Greetings kkchen, As far as I can figure out, without having to go deeper into the specific stack trace entry for each class, this problem which occurs only when compiled in Debug mode, is due to the order in which the objects are destroyed. My guess is that: 1- in optimized compile mode, the static objects for the main application are destroyed first and then the ones on each library are destroyed. 2- in debug mode, the objects in the libraries are destroyed first and the static ones in the main application are destroyed last. This explains why calling the "checkOut()" method before terminating the application is a good idea. Either way, it feels like you're trying to re-implement something that OpenFOAM already has got, namely the ability to get dictionary objects from memory, by using OpenFOAM's memory registry. In other words, you don't need to store the whole dictionary this way, you only need to store the name in which it is registered. Have a look at the source code for the function object "readFields" and you'll see what I mean. Best regards, Bruno |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-03-06 03:23 |
|
New Issue | |
| 2015-03-06 03:23 |
|
File Added: MWE.zip | |
| 2015-03-06 03:29 |
|
Note Added: 0003973 | |
| 2015-03-06 03:40 |
|
Note Edited: 0003973 | |
| 2015-03-24 00:17 | liuhuafei | Issue cloned: 0001624 | |
| 2015-03-29 14:24 | wyldckat | Note Added: 0004535 | |
| 2015-06-15 17:52 | henry | Status | new => closed |
| 2015-06-15 17:52 | henry | Assigned To | => henry |
| 2015-06-15 17:52 | henry | Resolution | open => no change required |
