View Issue Details

IDProjectCategoryView StatusLast Update
0002984OpenFOAMBugpublic2018-06-18 10:27
Reporterwyldckat Assigned Tohenry  
Status resolvedResolutionfixed 
Fixed in Versiondev 
Summary0002984: Opening parenthesis in the wrong place in a dictionary file can lead to an infinite loop
DescriptionThe 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.:

        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: - 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:

        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 Reproduce1. 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.:

          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.
TagsNo tags attached.



2018-06-17 21:25

manager   ~0009788

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?


2018-06-17 21:38

updater   ~0009790

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...


2018-06-17 21:41

updater   ~0009791

(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..


2018-06-17 23:02

manager   ~0009793

The problem is that dictionary now supports lists of entries:

commit a7256d6fa9f8f54c5aa2f14d21236659d1fc44d3
Author: Henry Weller <>
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
      - 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.


2018-06-18 10:27

manager   ~0009794

Resolved by commit eca187e025409f508d2d51c0486802c0db998281

Issue History

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