View Issue Details

IDProjectCategoryView StatusLast Update
0001454OpenFOAMBugpublic2014-12-12 08:51
Reporteroliveroxtoby Assigned Tohenry  
PrioritynormalSeverityminorReproducibilitysometimes
Status resolvedResolutionfixed 
PlatformLinuxOSFedoraOS Version20
Summary0001454: Bug in polyTopoChange::getCellOrder
DescriptionThere appears to be a bug in
src/dynamicMesh/polyTopoChange/polyTopoChange/polyTopoChange.C
In the function getCellOrder, on line 684, the line
                const labelList& neighbours = cellCellAddressing[currentCell];
should change to
                const labelList neighbours = cellCellAddressing[currentCell];
as CompactLabelList::operator[] returns a value, not a reference.

This appears to cause incorrect operation of the getCellOrder function.

Many thanks
Oliver
Steps To ReproduceI have not included a working example as snappyHexMesh does not seem to be affected by this issue. However I believe it is a fairly clear cut bug.
TagsNo tags attached.

Activities

oliveroxtoby

2014-12-08 13:50

reporter  

changeMeshProblem.tgz (953,156 bytes)

oliveroxtoby

2014-12-08 14:01

reporter   ~0003300

Last edited: 2014-12-08 14:02

I must apologise - I was a bit hasty with this bug report. I thought it was dangerous to bind a reference to an rvalue as is done here, but I see this is perfectly acceptable with a const reference.

I find that I experience this issue with gcc 4.8.2 but not with gcc 4.4.3, so I suspect it is a compiler rather than an OpenFOAM problem and maybe not worth pursuing further.

However if you wish to reproduce, I attach a minimal example and code to demonstrate the issue. The code hangs for a long time (more than an hour) inside the getCellOrder function when the changeMesh function is called. Applying the workaround above or the alternative
                const labelUList& neighbours = cellCellAddressing[currentCell];
solves the issue (the changeMesh function runs in a second or two).

Sorry for the confusion!

henry

2014-12-12 08:50

manager   ~0003305

Thanks for this bug report. I agree with your initial assessment of the problems: it is VERY dangerous to hold a reference to an object returned as a copy irrespective of the form of the reference.

Resolved by commit 6380962068a52d374b1c4d7a82c6ee827e6794ae

Issue History

Date Modified Username Field Change
2014-12-08 07:26 oliveroxtoby New Issue
2014-12-08 13:50 oliveroxtoby File Added: changeMeshProblem.tgz
2014-12-08 14:01 oliveroxtoby Note Added: 0003300
2014-12-08 14:02 oliveroxtoby Note Edited: 0003300
2014-12-12 08:50 henry Note Added: 0003305
2014-12-12 08:50 henry Status new => resolved
2014-12-12 08:50 henry Resolution open => fixed
2014-12-12 08:50 henry Assigned To => henry