dsmcFoam+: Double free or corruption

[timteichmann]

To keep the issue tracker a bit more cleaned this is in reply to:

Vincent:
I was trying out the Orion107km example which runs to completion but then crashes as shown below.  The problem is that because of the crash, the job does not exit - the processes have to be manually killed.  I was running this example on 36 cores.
Finalising parallel run*** Error in dsmcFoam+': double free or corruption (!prev): 0x0000000002cfb0f0 ****** Error in dsmcFoam+': double free or corruption (!prev): 0x000000000349d5e0 ****** Error in dsmcFoam+': double free or corruption (!prev): 0x000000000314e280 ****** Error in dsmcFoam+': double free or corruption (!prev): 0x00000000037b3ef0 ***======= Backtrace: ================ Backtrace: =========/lib64/libc.so.6(+0x81299)[0x2b813bd98299]/lib64/libc.so.6(__cxa_finalize+0x9a)[0x2b813bd5105a]OpenFOAM/iain-v1706/platforms/linux64GccDPInt32Opt/lib/liblagrangian+.so(+0xbf23)[0x2b8138cdbf23]
I see a similar problem when running snappyhexMesh in the Allrun script ...After snappyHexMesh finishes I see the following again in liblagranian.so ...
Finished meshing without any errorsFinished meshing in = 10.31 s.End
*** Error in `snappyHexMesh': double free or corruption (fasttop): 0x0000000001bd3350 ***======= Backtrace: =========/lib64/libc.so.6(+0x81299)[0x2ba54dd4f299]/lib64/libc.so.6(__cxa_finalize+0x9a)[0x2ba54dd0805a]/home/user/OF/OpenFOAM-v1706/platforms/linux64GccDPInt32Opt/lib/liblagrangian.so(+0x10853)[0x2ba54ffbd853]======= Memory map: ========

Originally posted by @iainsymthe in #67 (comment)

If this is a bug chances are high that I have introduced it last year. Ian, could you give me some input on whether you did a clean rebuild of the entire repository after the recent changes? From my experience the issue you describe occurs due to a "version mismatch" of the dsmcFoam+ solver / dmscInitialise+ utility and the lagrangian dsmc library.

I could not reproduce the issue with a clean rebuild.

[vincentcasseau]

I am pasting the message of Iain here:
Tim/Vincent:
Thanks for your response. I had done a clean reinstall in December 2020 - built everything from scratch (ThirdParty, OFv1706 and the hystrath library).
Also, for the Orion107K problem, the controlDict has the endTime set as 70 s, but I see the solution reach close to steady-state in about 2-3 second or running. My definition of SS is "weak" in that I monitored various variables using probes in about 11 locations and saw that temp does not change much (see attached png). I also see that the temp in the initial time is 0, not the initial set value of 217K. Is this something you have seen as well?
Thanks
Iain

[vincentcasseau]

There are too many pseudo DSMC test cases right now, which means less care given to each of them.
I think we should keep 4 or 5 of them at most, improve them and write the tutos.

[timteichmann]

Yes, you are right. Also IIRC none of the current tutorials are adapted to the changes I made with regards to the start of averaging (cf. merges #55 and #56). It would probably be useful to include this as well.

[timteichmann]

As a comment to the original issue here, I still think that this is related to a bad build. Especially, since snappyHexMesh also throws an error.

[iainsymthe]

Tim: As I said in my previous message - both snappyHexMesh and the case itself run to completion. It is only after they are complete that the case gives these errors. When I run the Orion107kmNR case on multiple cores - after I get to the end (Finalising case) - all processors don't exit cleanly.  If there was a build issue, I don't think the case would have even started. On Friday, April 23, 2021, 10:37:48 AM CDT, Tim Teichmann ***@***.***> wrote: As a comment to the original issue here, I still think that this is related to a bad build. Especially, since snappyHexMesh also throws an error. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[vincentcasseau]

Hi Iain,
Any updates on that problem?
Thanks,
Vincent