View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002984 | OpenFOAM | Bug | public | 2018-06-17 21:17 | 2018-06-18 10:27 |
| Reporter | wyldckat | Assigned To | henry | ||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | dev | ||||
| Summary | 0002984: Opening parenthesis in the wrong place in a dictionary file can lead to an infinite loop | ||||
| Description | The other day a colleague of mine had finished adapting a case from an old OpenFOAM version to 5.x and missed the removal of a parenthesis in the file 'system/fvSolution', e.g.: (p_rgh { solver PCG; preconditioner DIC; tolerance 1e-08; relTol 0.01; } because it was previously something like "(p_rgh|p)". Then he ran the 'Allrun' script and saw that 'snappyHexMesh' had stalled right after showing that it had read the mesh "Time = 0"... but it then seemed to be in an infinite loop, because it wasn't doing anything else but use up CPU time. This reminds me of report #1538: https://bugs.openfoam.org/view.php?id=1538 - but fortunately it's not as bad, since there was no (noticeable) memory leak nor a hard crash. And the fix made back then is still in place... so it's apparently not the same issue. Backtracking to older versions, this bug seems to have been introduced sometime before OpenFOAM 5.0 version was released, since it's not in 4.x, 3.0.x and 2.3.x. A bit of trying to back-trace the infinite loop with GDB and it seems to be a bug/limitation that was introduced with the uncollated data reader. Even if we close the parenthesis: (p_rgh) { solver PCG; preconditioner DIC; tolerance 1e-08; relTol 0.01; } it still gets stuck in an infinite loop. I'm not familiar enough with this part of the code, so I keep getting lost on where the EOF should be detected. | ||||
| Steps To Reproduce | 1. Choose any tutorial case, e.g. 'mesh/snappyHexMesh/iglooWithFridges', then run it with 'Allrun'. 2. After it starts running the solver, hit Ctrl+C to stop it. 3. Add a parenthesis before the name 'solvers', e.g.: (solvers { p_rgh { solver PCG; preconditioner DIC; ... 4. Run the solver manually and it should get stuck in an infinite loop after this line: Create mesh for time = 0 The same will happen with 'snappyHexMesh' or any other applications that needs this dictionary file. Even with 'foamDictionary' it will get stuck... as expected, given it parses with the same mechanism as the other applications that load it the standard way. | ||||
| Tags | No tags attached. | ||||
|
|
The bug appears to be in the dictionary rather than the code, surely you should remove the spurious '('? In what way do you consider this a bug in OpenFOAM? |
|
|
Sorry, I did forgot to emphasize that this is indeed a user-side error, but given that OpenFOAM's applications usually complain when things go wrong and at least give a rough idea of what went wrong, this seems to be an unintended feature and _not normal_... hence this bug report, given that this should at least be kept on record as a known feature/limitation. At the office, we had gotten lucky in finding the error after a couple of minutes, but it seemed very odd that 'snappyHexMesh' would lock up in such an usual way. At first, I was even wondering if there was a hardware problem going on... If users rely on keeping track of their file changes with Git or something similar, this will be fairly easy to catch, but not all users do that... |
|
|
(OK, I keep forgetting to write things down...) If you prefer, this can be closed as suspended for the time being, given that this is not critical and is mostly a user-side error, even though this isn't consistent with how OpenfOAM's applications usually work.. |
|
|
The problem is that dictionary now supports lists of entries: commit a7256d6fa9f8f54c5aa2f14d21236659d1fc44d3 Author: Henry Weller <http://cfd.direct> Date: Fri Nov 25 20:33:03 2016 +0000 foamDictionary: Added support for manipulating lists of dictionaries - provides support for manipulating polyMesh/boundary - changed behaviour of disableFunctionEntries option to preserve #include - dictionary: added reading of lists of dictionaries. + each list element may be accessed using the 'entryDDD' keyword according to their list index. Patch contributed by Mattijs Janssens so the '(' is now valid but the following entry is not. So it should be possible to stop the reading and give some context but it is not possible to state that the '(' is incorrect. I am testing some changes to the dictionaryListEntry read at the moment so avoid the infinite loop. |
|
|
Resolved by commit eca187e025409f508d2d51c0486802c0db998281 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-06-17 21:17 | wyldckat | New Issue | |
| 2018-06-17 21:25 | henry | Note Added: 0009788 | |
| 2018-06-17 21:26 | henry | Severity | block => trivial |
| 2018-06-17 21:38 | wyldckat | Note Added: 0009790 | |
| 2018-06-17 21:41 | wyldckat | Note Added: 0009791 | |
| 2018-06-17 23:02 | henry | Note Added: 0009793 | |
| 2018-06-17 23:02 | henry | Severity | trivial => minor |
| 2018-06-18 10:27 | henry | Assigned To | => henry |
| 2018-06-18 10:27 | henry | Status | new => resolved |
| 2018-06-18 10:27 | henry | Resolution | open => fixed |
| 2018-06-18 10:27 | henry | Fixed in Version | => dev |
| 2018-06-18 10:27 | henry | Note Added: 0009794 |
