corrupted double-linked list
Posted February 21, 2017 at 12:04 by kindle
I copied a derived boundary condition from src/finiteVolume/fields/fvPatchFields/derived/turbulentInlet modified and recompiled it in user directory. It compiles and I name the new library libturbulentInletUser.
When using it in a simluation. Running the solver seems all right but I get "corrupted double-linked list" when I call "blockMesh" or "decomposePar".
In the source code, all classes in finiteVolume is compiled as a single library which contains the class libturbulentInletUser.
The problem may be : I didn't change the run time name (turbulentInlet) of in the macro functions (at least I think so)
makepatchTypeFieldTypedefs
makepatchFields
which are located in the other three files (seemed not that important! But turn out to be) turbulentInletFvPatchFields.C, turbulentInletFvPatchFields.H and turbulentInletFvPatchFieldsFwd.C.
After I change these names compactly. I get no more "corrupted double-linked list".
Conclusion:
Maybe it is a run time library issue: I was refering to libA(from my variation of the code) still using the old "patchTypeName" of libB(of the source code).
When I do " libs("libA"); " in the system/controlDict, the "patchTypeName" of libA (turbulentInlet) will be added to the runtime table of "Valid patchField types" which coincidents the libB with the same name turbulentInlet. Therefore at run time, OpenFOAM gives error and there's no error at all at compilation.
So every time we include a shared object (*.so) at controlDict, what is in the *.so will be added to the run time table of in this example "patchField types". Make sure that every name has only one correspondance.
Good Habit :
Like in the video of 8th Floor CFD@FSB Basic OpenFOAM Programming Tutorial : Writing a Custom Boundary Condtion :
1. Compactly change the source file names (corresponds to the modified class name)
2. Change Make/files Make/options to suit the need
3. Change compactly in all source files the class name, pay attention to the name added by macro functions to the runtime table.
4. (Try if it compiles) Then begin to make modification.
When using it in a simluation. Running the solver seems all right but I get "corrupted double-linked list" when I call "blockMesh" or "decomposePar".
In the source code, all classes in finiteVolume is compiled as a single library which contains the class libturbulentInletUser.
The problem may be : I didn't change the run time name (turbulentInlet) of in the macro functions (at least I think so)
makepatchTypeFieldTypedefs
makepatchFields
which are located in the other three files (seemed not that important! But turn out to be) turbulentInletFvPatchFields.C, turbulentInletFvPatchFields.H and turbulentInletFvPatchFieldsFwd.C.
After I change these names compactly. I get no more "corrupted double-linked list".
Conclusion:
Maybe it is a run time library issue: I was refering to libA(from my variation of the code) still using the old "patchTypeName" of libB(of the source code).
When I do " libs("libA"); " in the system/controlDict, the "patchTypeName" of libA (turbulentInlet) will be added to the runtime table of "Valid patchField types" which coincidents the libB with the same name turbulentInlet. Therefore at run time, OpenFOAM gives error and there's no error at all at compilation.
So every time we include a shared object (*.so) at controlDict, what is in the *.so will be added to the run time table of in this example "patchField types". Make sure that every name has only one correspondance.
Good Habit :
Like in the video of 8th Floor CFD@FSB Basic OpenFOAM Programming Tutorial : Writing a Custom Boundary Condtion :
1. Compactly change the source file names (corresponds to the modified class name)
2. Change Make/files Make/options to suit the need
3. Change compactly in all source files the class name, pay attention to the name added by macro functions to the runtime table.
4. (Try if it compiles) Then begin to make modification.
Quote:
Originally Posted by gschaider
That looks to me not like a OF-error per se, but like a "the application an the library are out of tune"-problem. Usually that kind of problem occurs when the following happens:
In my experience the best way to resolve this problem is to make an Allwmake of the WHOLE distro (not just the parts that YOU thought were affected by the changes)
Bernhard
- An update of the sources gets downloaded. This update changes the size that some object needs in memory (because data was added etc) or changes the interface in some other way
- Either only the library that was changed or the application that depends on it was recompiled
- When calling the application library and application each act upon their "version of the truth"
- Because their versions differ some great misunderstanding happens and your above stack-trace is thrown
In my experience the best way to resolve this problem is to make an Allwmake of the WHOLE distro (not just the parts that YOU thought were affected by the changes)
Bernhard
Total Comments 0
