Weird segmentation fault!
 

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! :confused:
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.

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

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:
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?

Wrong place to put the "-ltestlib". But I'm guessing you meant this:
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:
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

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.

Exactly.

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


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...

Hi anon_a,

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.

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

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!