[anon_a]

Hey there

I am facing a very unusual behaviour of the code lately.
A segmentation fault occurs during the deallocation/destruction stage at the end of my custom code.
So far I did not really pay attention to it, since the simulation is finished at that point, but it started becoming annoying.
So, I thought, hey, let's go back and apply the differences one-by-one until the error occurs.

The problem is that the original library of the code (dsmc) does NOT provide an error, while if I make a copy of it (testlib) and compile, then the error shows up!
No other changes were made besides the usual ones in Make/files and Make/options.

The error is shown below. This is off course a non-urgent error but more like curiosity-driven.

...
...
End

*** glibc detected *** testFoam: double free or corruption (fasttop): 0x08b0f358 ***
======= Backtrace: =========
/lib/libc.so.6(+0x6de2b)[0xb5ca9e2b]
/lib/libc.so.6(+0x6ebab)[0xb5caabab]
/lib/libc.so.6(cfree+0x6d)[0xb5caea6d]
/usr/lib/libstdc++.so.6(_ZdlPv+0x1f)[0xb5ea3b0f]
/usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1b)[0xb5e8472b]
/usr/lib/libstdc++.so.6(_ZNSsD1Ev+0x4a)[0xb5e847da]
testFoam(_ZN4Foam6stringD1Ev+0x1d)[0x8074073]
testFoam(_ZN4Foam4wordD1Ev+0x1d)[0x8074499]
/lib/libc.so.6(__cxa_finalize+0xab)[0xb5c6ac1b]
/home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libtest.so(+0x1a794)[0xb652f794]
/home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libtest.so(+0x2aaa0)[0xb653faa0]
/lib/ld-linux.so.2(+0xedfd)[0xb784fdfd]
/lib/libc.so.6(+0x2e89f)[0xb5c6a89f]
======= Memory map: ========
08048000-080c2000 r-xp 00000000 08:07 17956868   /home/bla/OpenFOAM/bla-2.0.1/platforms/linuxGccDPDebug/bin/testFoam
080c2000-080c3000 r--p 0007a000 08:07 17956868   /home/bla/OpenFOAM/bla-2.0.1/platforms/linuxGccDPDebug/bin/testFoam
080c3000-080c4000 rw-p 0007b000 08:07 17956868   /home/bla/OpenFOAM/bla-2.0.1/platforms/linuxGccDPDebug/bin/testFoam
080c4000-08b9b000 rw-p 00000000 00:00 0          [heap]
b4f00000-b4f21000 rw-p 00000000 00:00 0 
b4f21000-b5000000 ---p 00000000 00:00 0 
b5060000-b52fa000 r-xp 00000000 08:07 6818603    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libfieldFunctionObjects.so
b52fa000-b52fe000 r--p 00299000 08:07 6818603    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libfieldFunctionObjects.so
b52fe000-b5304000 rw-p 0029d000 08:07 6818603    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libfieldFunctionObjects.so
b5304000-b5395000 r-xp 00000000 08:07 6818550    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libconversion.so
b5395000-b5396000 r--p 00090000 08:07 6818550    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libconversion.so
b5396000-b5398000 rw-p 00091000 08:07 6818550    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libconversion.so
b5398000-b54c4000 r-xp 00000000 08:07 6818537    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libsurfMesh.so
b54c4000-b54c5000 ---p 0012c000 08:07 6818537    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libsurfMesh.so
b54c5000-b54c7000 r--p 0012c000 08:07 6818537    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libsurfMesh.so
b54c7000-b54ca000 rw-p 0012e000 08:07 6818537    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libsurfMesh.so
b54ca000-b54fe000 r-xp 00000000 08:07 6815820    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libdsmc.so
b54fe000-b54ff000 r--p 00033000 08:07 6815820    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libdsmc.so
b54ff000-b5500000 rw-p 00034000 08:07 6815820    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libdsmc.so
b5500000-b58ab000 r-xp 00000000 08:07 6818551    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libsampling.so
b58ab000-b58b1000 r--p 003aa000 08:07 6818551    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libsampling.so
b58b1000-b58b9000 rw-p 003b0000 08:07 6818551    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libsampling.so
b58b9000-b5934000 r-xp 00000000 08:07 6818691    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libutilityFunctionObjects.so
b5934000-b5935000 ---p 0007b000 08:07 6818691    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libutilityFunctionObjects.so
b5935000-b5936000 r--p 0007b000 08:07 6818691    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libutilityFunctionObjects.so
b5936000-b5938000 rw-p 0007c000 08:07 6818691    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libutilityFunctionObjects.so
b59f8000-b59fb000 rw-p 00000000 00:00 0 
b59fb000-b59fd000 r-xp 00000000 08:06 262825     /lib/libutil-2.11.3.so
b59fd000-b59fe000 r--p 00001000 08:06 262825     /lib/libutil-2.11.3.so
b59fe000-b59ff000 rw-p 00002000 08:06 262825     /lib/libutil-2.11.3.so
b59ff000-b5a15000 r-xp 00000000 08:06 263144     /lib/libnsl-2.11.3.so
b5a15000-b5a16000 r--p 00015000 08:06 263144     /lib/libnsl-2.11.3.so
b5a16000-b5a17000 rw-p 00016000 08:06 263144     /lib/libnsl-2.11.3.so
b5a17000-b5a1a000 rw-p 00000000 00:00 0 
b5a1a000-b5a26000 r-xp 00000000 08:07 6818533    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libfileFormats.so
b5a26000-b5a27000 r--p 0000c000 08:07 6818533    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libfileFormats.so
b5a27000-b5a28000 rw-p 0000d000 08:07 6818533    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libfileFormats.so
b5a28000-b5b3b000 r-xp 00000000 08:07 18094834   /home/bla/OpenFOAM/ThirdParty-2.0.1/platforms/linuxGcc/openmpi-1.5.3/lib/libmpi.so.1.0.1
b5b3b000-b5b3f000 r--p 00112000 08:07 18094834   /home/bla/OpenFOAM/ThirdParty-2.0.1/platforms/linuxGcc/openmpi-1.5.3/lib/libmpi.so.1.0.1
b5b3f000-b5b4c000 rw-p 00116000 08:07 18094834   /home/bla/OpenFOAM/ThirdParty-2.0.1/platforms/linuxGcc/openmpi-1.5.3/lib/libmpi.so.1.0.1
b5b4c000-b5b5d000 rw-p 00000000 00:00 0 
b5b5d000-b5b72000 r-xp 00000000 08:06 263127     /lib/libz.so.1.2.5
b5b72000-b5b73000 r--p 00014000 08:06 263127     /lib/libz.so.1.2.5
b5b73000-b5b74000 rw-p 00015000 08:06 263127     /lib/libz.so.1.2.5
b5b74000-b5c0d000 r-xp 00000000 08:07 6818534    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libtriSurface.so
b5c0d000-b5c0e000 ---p 00099000 08:07 6818534    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libtriSurface.so
b5c0e000-b5c0f000 r--p 00099000 08:07 6818534    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libtriSurface.so
b5c0f000-b5c11000 rw-p 0009a000 08:07 6818534    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/libtriSurface.so
b5c11000-b5c12000 rw-p 00000000 00:00 0 
b5c12000-b5c29000 r-xp 00000000 08:06 263552     /lib/libpthread-2.11.3.so
b5c29000-b5c2a000 r--p 00016000 08:06 263552     /lib/libpthread-2.11.3.so
b5c2a000-b5c2b000 rw-p 00017000 08:06 263552     /lib/libpthread-2.11.3.so
b5c2b000-b5c2d000 rw-p 00000000 00:00 0 
b5c2d000-b5c3a000 r-xp 00000000 08:07 6948993    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/openmpi-1.5.3/libPstream.so
b5c3a000-b5c3b000 r--p 0000d000 08:07 6948993    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/openmpi-1.5.3/libPstream.so
b5c3b000-b5c3c000 rw-p 0000e000 08:07 6948993    /home/bla/OpenFOAM/OpenFOAM-2.0.1/platforms/linuxGccDPDebug/lib/openmpi-1.5.3/libPstream.so
b5c3c000-b5da2000 r-xp 00000000 08:06 263540     /lib/libc-2.11.3.so
b5da2000-b5da3000 ---p 00166000 08:06 263540     /lib/libc-2.11.3.soAborted

[wyldckat]

Greetings anon_a,

Mmm... AFAIK, the "lagrangian/dsmc" library is heavy on C++ templates.
But the main problem might not be that, it might be because the original dsmc library might get loaded into the same object space in memory at execution time, leading to an overload of same named C++ objects.

Therefore, you should either:

• Option 1: Re-implement only the classes that you really need to modify and make 100% certain they have different names, as well as making sure you're using these new ones in your solver.
• Option 1: Fully re-implement all classes in "dsmc" with different names and make sure your solver uses them.

If you can share the initial test modifications you've made to the dsmc library, it might be easier to pinpoint what else still needs changing!


After thinking a bit more on this, one of the trailing thoughts I was missing is this: since "dsmc" it's heavy on templates, you might have added methods to the newly implemented classes that we're not in the original templates. Then the original templates are the ones that are read by the new solver instead, thus leading to discrepancies in the size and form of the object used by the library and the one the solver expects to see.

Best regards,
Bruno

[anon_a]

Hey Bruno, thanks for the answer!

So, at first I copied src/lagrangian/dsmc to src/lagrangian/testlib and applications/solvers/discreteMethods/dsmc/dsmcFoam to applications/solvers/discreteMethods/dsmc/testFoam.

Here are the changes in the files:

src/lagrangian/testlib/Make/files:
LIB = $(FOAM_LIBBIN)/libtestlib

applications/solvers/discreteMethods/dsmc/testFoam/Make/options:
    -I$(LIB_SRC)/lagrangian/testlib/lnInclude \
    -ltestlib

applications/solvers/discreteMethods/dsmc/testFoam/Make/files:
EXE = $(FOAM_APPBIN)/testFoam

Running the freeSpacePeriodic tutorial leads to the aforementioned error.
I did not really mess with anything else, like file names (I am such a lazy guy sometimes). Could that be the cause of the problem? Is there a fast way to do this, other than the traditional one?

[wyldckat]

Originally Posted by anon_a

applications/solvers/discreteMethods/dsmc/testFoam/Make/options:
    -I$(LIB_SRC)/lagrangian/testlib/lnInclude \
    -ltestlib

Wrong place to put the "-ltestlib". But I'm guessing you meant this:

EXE_INC = \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/lagrangian/basic/lnInclude \
    -I$(LIB_SRC)/lagrangian/testLib/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude

EXE_LIBS = \
    -lmeshTools \
    -lfiniteVolume \
    -llagrangian \
    -ltestLib

OK, it really depends on the modifications you want to do!? Do you want to do a major hack to the code, by adding several more variables and parameters to the "dsmc" library?
If not, then you could simply add more implementations to the existing library, without having to build a new one. Here's an example of adding an additional boundary condition: http://openfoamwiki.net/index.php/Ho...dary_condition

I'm checking right now to see what happens if I follow your footsteps... I'll edit this post when I reach a conclusion.
_________________
edit: Test complete. Attached is a file with the library and solver and tutorial with the adjusted files so it will do what's intended.
It was based on 2.1.x, commit dbda68ff9b2e9b35b3bd686bf5e33d72649b1bb2. In other words, 25th of June, almost a month after 2.1.1 was released.

To see what was modified, run these commands from within the "customDSMC" folder:

diff -Nur $FOAM_SRC/lagrangian/dsmc myDsmc > myDsmc.patch
diff -Nur $FOAM_APP/solvers/discreteMethods/dsmc/dsmcFoam myDsmcFoam > myDsmcFoam.patch
diff -Nur $FOAM_TUTORIALS/discreteMethods/dsmcFoam/freeSpacePeriodic freeSpacePeriodicMy > freeSpacePeriodicMy.patch

The newly created files "*.patch" will show you what I modified to make things work. Disregard changes made to the "*.dep" files and such, namely files that are generated by wmake.
Lines that start with + or - indicate new code and old code respectively.

The attached tutorial "freeSpacePeriodicMy" ran without any problems.

Have fun!
Bruno

[anon_a]

Hey Bruno

First of all thank you for taking the time to answer and in fact for your whole involvement. You dedicate a lot of time in this forum and this is highly appreciated.

Originally Posted by wyldckat

Wrong place to put the "-ltestlib". But I'm guessing you meant this: ...

Exactly.

Originally Posted by wyldckat

OK, it really depends on the modifications you want to do!?

In this case, I only wanted to make a working copy without any modifications.

Originally Posted by wyldckat

It was based on 2.1.x, commit dbda68ff9b2e9b35b3bd686bf5e33d72649b1bb2. In other words, 25th of June, almost a month after 2.1.1 was released.

Originally Posted by wyldckat

To see what was modified, run these commands...

99% the same as the files of 2.0.1, that I am using.
The only differences were the dates on the OpenFOAM header and the changes in Make/*.
The tutorial was also the same (with testFoam instead of myDsmcFoam).


A relative(?) question: Does it matter that I use $(FOAM_LIBBIN), $(FOAM_APPBIN) instead of $(FOAM_USER_LIBBIN), $(FOAM_USER_APPBIN)? Besides making my system a little more chaotic. Maybe this is where the problem comes from?


Finally, the craziest thing is that I can run your version of the tutorial with my "testFoam" without producing any errors! This is not true for the original tutorial...

[wyldckat]

Hi anon_a,

Originally Posted by anon_a

A relative(?) question: Does it matter that I use $(FOAM_LIBBIN), $(FOAM_APPBIN) instead of $(FOAM_USER_LIBBIN), $(FOAM_USER_APPBIN)? Besides making my system a little more chaotic. Maybe this is where the problem comes from?

OpenFOAM was designed with the idea to have OpenFOAM's master folder kept untouched after installation. One of several reasons is this: if you (even accidentally) change the core code of OpenFOAM, the simulation results may no longer be valid. This is why the user folders were created, so that the core code is kept untouched.

Additionally, this makes you life easier when you need to update you modifications to the latest (or go back to an older) version of OpenFOAM.

Originally Posted by anon_a

Finally, the craziest thing is that I can run your version of the tutorial with my "testFoam" without producing any errors! This is not true for the original tutorial...

That might be because if you look to the "controlDict" in the case I attached, there are two major differences:

1. I changed the name of the application to be run. Not essential, but useful for Allrun to know which one to run.
2. I commented out the list of function objects, because they looked very suspicious to me, in the sense that they might load the original libraries, leading to object overload at run time.

Best regards,
Bruno

[anon_a]

Yes, you are right about keeping the original directory intact. I will keep this in mind when I will perform a fresh re-installation in a few weeks.

I also changed the solver name in controlDict but did not deactivate the libraries.
This was finally the key point: after commenting out the libraries, the error disappears!
Actually, I do not need them anymore because of the modifications, so I can remove them and free my self from the error. Thanks again!