View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001560OpenFOAMBugpublic2015-03-06 21:102015-03-09 10:51
Reporteruser1080Assigned Tohenry  
PriorityhighSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Summary0001560: execFlowFunctionObjects is crashing the solver due to corrupted double linked list errors
DescriptionHi all,

I'm using pimpleDyMFoam to simulate an oscillating airfoil. When I include forceCoeffs file in my controlDict folder the simulation crashes. It runs fine without the forceCoeffs file. Therefore I started using execFlowFunctionObjects to calculate the forceCoeffs after the simulation has been run. Even then I suffer from segmentation faults and corrupted double linked lists. Here is a stack trace

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::forces::calcForcesMoment() at ??:?
#4 Foam::forceCoeffs::write() at ??:?
#5 Foam::OutputFilterFunctionObject<Foam::forceCoeffs>::execute(bool) at ??:?
#6 Foam::functionObjectList::execute(bool) at ??:?
#7
 at ??:?
#8
 at ??:?
#9 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10

Here is the corrupted linked list error

*** Error in `execFlowFunctionObjects': corrupted double-linked list: 0x0000000002664690 ***

As a work around to these issues I have been using a shell script to rerun execFlowFunctionObjects from the previous crash point. Here is the link http://www.cfd-online.com/Forums/openfoam-post-processing/148940-shell-script-handle-segmentation-faults-arising-execflowfunctionobjects.html

I do not face this error with the same mesh in pimpleFoam.
Steps To ReproduceI uploaded the case file to github. Please clone the case file and run the Allrun.sh script located in the case file. Here is the link https://github.com/pruthvi1991/pimpleDyMFoam-Tutorials/tree/master/pimpleDyMFoam_bugreporting
Additional InformationThis error has repeatedly occurred for various other cases of pimpleDyMFoam.
TagsNo tags attached.

Activities

wyldckat

2015-03-08 16:06

updater   ~0004028

Greetings pruthvi1991,

I'm unable to reproduce the error you've reported with the case you provided, because the cases you have provided do not work in the way they currently are (in commit 438267f01). Please fix the test cases, so that I or anyone else can test this properly.

Problems found so far, at which point I stopped trying:

 1- "snappyAmbientCoarse_airfoil" doesn't work, because the "snappyHexMeshDict" file is not referencing the correct feature file.

 2- "plunging_NACA0012/run.sh" doesn't copy the mesh from "snappyAmbientCoarse_airfoil".

 3- decomposePar fails with the error message:

    --> FOAM FATAL IO ERROR:
    Cannot find patchField entry for symFront


Best regards,
Bruno

user1080

2015-03-08 17:12

  ~0004037

Hello Bruno,

Thanks for checking the case and pointing the errors. I fixed the feature file name in snappy. I also changed the Allrun.sh script to cleanCase the plunging folder before running extrudeMesh and createPatch. I tested it and its working fine. I ran the case in serial and it crashes at different times every time I run it. But if I run in parallel on 4 cores I face seg faults immediately.

Here is the link to the previous repository https://github.com/pruthvi1991/pimpleDyMFoam-Tutorials/tree/master/pimpleDyMFoam_bugreporting

Here is the link to a new repository
https://github.com/pruthvi1991/OpenFOAM-bug-reporting

Both repositories have the same copy.

Thanks,
Pruthvi.

wyldckat

2015-03-08 17:25

updater   ~0004039

Many thanks! I've reproduced the problem and will start diagnosing it!

user1080

2015-03-08 17:37

  ~0004040

I'm glad and I really appreciate your help. I've been facing issues with this bug for a long time and I'm really happy that someone can fix it.

wyldckat

2015-03-08 20:42

updater  

issue1560.patch (1,055 bytes)    
diff --git a/src/postProcessing/functionObjects/forces/forces/forces.C b/src/postProcessing/functionObjects/forces/forces/forces.C
index 539e14b..0c4fc15 100644
--- a/src/postProcessing/functionObjects/forces/forces/forces.C
+++ b/src/postProcessing/functionObjects/forces/forces/forces.C
@@ -378,12 +378,16 @@ void Foam::forces::applyBins
         forAll(dd, i)
         {
             label binI = floor(dd[i]/binDx_);
-            force_[0][binI] += fN[i];
-            force_[1][binI] += fT[i];
-            force_[2][binI] += fP[i];
-            moment_[0][binI] += Md[i]^fN[i];
-            moment_[1][binI] += Md[i]^fT[i];
-            moment_[2][binI] += Md[i]^fP[i];
+            
+            if(0<=binI && binI<force_.size())
+            {
+              force_[0][binI] += fN[i];
+              force_[1][binI] += fT[i];
+              force_[2][binI] += fP[i];
+              moment_[0][binI] += Md[i]^fN[i];
+              moment_[1][binI] += Md[i]^fT[i];
+              moment_[2][binI] += Md[i]^fP[i];
+            }
         }
     }
 }
issue1560.patch (1,055 bytes)   

wyldckat

2015-03-08 20:42

updater  

forces.C.issue1560 (26,081 bytes)

wyldckat

2015-03-08 20:46

updater   ~0004049

OK, I've figured out the problem! It happens due to an unprotected memory access in the method "forces::applyBins". As far as I could see, there was an access to index "-1". I haven't dug deeper to figure out if the algorithm will always give -1 in case of failure to find the bin.


Attached are two files:

 - "issue1560.patch" - is the patch for fixing this issue.

 - "forces.C.issue1560" is the complete file for replacing "src/postProcessing/functionObjects/forces/forces/forces.C". Indexed to commit ade709a58e9 in 2.3.x.

user1080

2015-03-08 20:56

  ~0004050

Great! I'm glad. What happens now? I have never done a bug report so Im unsure what happens next. When will this change be added to the OpenFOAM 2.3.x. repository?

Regarding the attached files, am I supposed to recompile OpenFOAM with these files?

wyldckat

2015-03-08 21:01

updater   ~0004052

OK, if you don't want to wait, it's simple:

 1- Download the file "forces.C.issue1560".

 2- Place this file in a folder you know the path for. The usual location for downloads is "~/Download", therefore the following commands should handle the replacement of the file just fine:

    foam
    cp ~/Download/forces.C.issue1560 src/postProcessing/functionObjects/forces/forces/forces.C

 3- Build the library in question, by running:

    wmake libso src/postProcessing/functionObjects/forces

 4- And it's ready to be used!


The fix will likely be pushed by Henry as soon as he can have a look into this :)

user1080

2015-03-08 21:05

  ~0004053

Thanks a ton Bruno. I appreciate your help. I can't believe this issue got almost resolved so fast.

wyldckat

2015-03-08 21:06

updater   ~0004054

WARNING: Sorry, there is a bug in the fix I provided!!

Please edit the file "src/postProcessing/functionObjects/forces/forces/forces.C", go to line 382 and change this:

            if(0<=binI && binI<force_.size())

to this:

            if(0<=binI && binI<force_[0].size())


------

As for the problem itself, I did a bit more digging and the problem seems to be related to this calculation:

   dd((d & binDir_) - binMin_);

where "d" is the centre of faces of the patch. And since the patch can morph, this means that the centres can have smallish errors that could be big enough to result in values going outside of the existing bins.

Limiting would likely have been the better fix, i.e. inside the forAll loop, do:

   label binI = min(max(floor(dd[i]/binDx_), 0), force_[0].size());

henry

2015-03-09 10:51

manager   ~0004058

@Bruno, I implemented the clipping you suggested but this approach simply accumulates data outside the range of the bins into the first or last bin which may be OK for small motions. For larger motions it may be better if the bins are updated or operate in a coordinate system attached to the body for solid-body motion. Something to consider in the future.

Resolved by commit 5179e8ea3bcb24cdb6ad0ac96764c0d562a55945

Issue History

Date Modified Username Field Change
2015-03-06 21:10 user1080 New Issue
2015-03-08 16:06 wyldckat Note Added: 0004028
2015-03-08 17:12 user1080 Note Added: 0004037
2015-03-08 17:25 wyldckat Note Added: 0004039
2015-03-08 17:37 user1080 Note Added: 0004040
2015-03-08 20:42 wyldckat File Added: issue1560.patch
2015-03-08 20:42 wyldckat File Added: forces.C.issue1560
2015-03-08 20:46 wyldckat Note Added: 0004049
2015-03-08 20:56 user1080 Note Added: 0004050
2015-03-08 21:01 wyldckat Note Added: 0004052
2015-03-08 21:05 user1080 Note Added: 0004053
2015-03-08 21:06 wyldckat Note Added: 0004054
2015-03-09 10:51 henry Note Added: 0004058
2015-03-09 10:51 henry Status new => resolved
2015-03-09 10:51 henry Resolution open => fixed
2015-03-09 10:51 henry Assigned To => henry
2015-03-24 00:17 liuhuafei Issue cloned: 0001628