CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Programming & Development

Weird segmentation fault!

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By wyldckat

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   July 16, 2012, 12:33
Default Weird segmentation fault!
  #1
Disabled
 
Join Date: Mar 2011
Posts: 174
Rep Power: 15
anon_a is on a distinguished road
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.

Code:
...
...
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
anon_a is offline   Reply With Quote

Old   July 16, 2012, 19:33
Default
  #2
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
hua1015 likes this.
__________________
wyldckat is offline   Reply With Quote

Old   July 18, 2012, 09:33
Default
  #3
Disabled
 
Join Date: Mar 2011
Posts: 174
Rep Power: 15
anon_a is on a distinguished road
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:
Code:
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?
anon_a is offline   Reply With Quote

Old   July 18, 2012, 17:17
Default
  #4
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Quote:
Originally Posted by anon_a View Post
Code:
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:
Code:
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:
Code:
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
Attached Files
File Type: gz customDSMC.tar.gz (27.9 KB, 34 views)
__________________

Last edited by wyldckat; July 18, 2012 at 18:10. Reason: see "edit:"
wyldckat is offline   Reply With Quote

Old   July 19, 2012, 09:59
Default
  #5
Disabled
 
Join Date: Mar 2011
Posts: 174
Rep Power: 15
anon_a is on a distinguished road
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.

Quote:
Originally Posted by wyldckat View Post
Wrong place to put the "-ltestlib". But I'm guessing you meant this: ...
Exactly.

Quote:
Originally Posted by wyldckat View Post
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.


Quote:
Originally Posted by wyldckat View Post
It was based on 2.1.x, commit dbda68ff9b2e9b35b3bd686bf5e33d72649b1bb2. In other words, 25th of June, almost a month after 2.1.1 was released.
Quote:
Originally Posted by wyldckat View Post
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...
anon_a is offline   Reply With Quote

Old   July 20, 2012, 05:58
Default
  #6
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Hi anon_a,

Quote:
Originally Posted by anon_a View Post
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.

Quote:
Originally Posted by anon_a View Post
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
__________________
wyldckat is offline   Reply With Quote

Old   July 20, 2012, 07:55
Default
  #7
Disabled
 
Join Date: Mar 2011
Posts: 174
Rep Power: 15
anon_a is on a distinguished road
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!
anon_a is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Segmentation fault when running dieselFoam or dieselEngineFoam in parallel francesco OpenFOAM Bugs 4 May 2, 2017 22:59
Segmentation fault in interFoam run through openMPI voingiappone OpenFOAM 16 November 2, 2011 07:49
Segmentation Fault Shawn_A OpenFOAM Running, Solving & CFD 6 October 31, 2011 15:38
ParaView segmentation fault only for multiphase gwierink OpenFOAM 9 March 25, 2010 08:23
KIVA and Segmentation Fault Felix Main CFD Forum 2 January 18, 2006 02:24


All times are GMT -4. The time now is 12:33.