GiDIO segfaults without Variables added #492
Comments
|
I definitely agree it would be good!
Riccardo
El 13 jun. 2017 10:12 a. m., "Philipp Bucher" <[email protected]>
escribió:
… If GiDIO is initialized with a modelpart where variables have not been
added yet it exits with Segmentation Fault. This is not so nice to debug,
can a check be implemented for that?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#492>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AHr7ETl_hwhZcNok2xTfYbBM3Kx9kz_Zks5sDjZogaJpZM4N4E0G>
.
|
|
@philbucher can u write a minimal python test for this? |
|
@RiccardoRossi Unfortunately I cannot replicate the error now :/ If will close this issue and reopen it in case I have the same problem again. |
|
@AndreasWinterstein and me found a very nasty bug that is very similar to this issue: Figuring this out took us several hours, so it would be really good to have a solution or at least a warning/error message for this! @KratosMultiphysics/kratos-core-team and @jcotela do you have an idea of how to do this? We could unfortunately not pin down what is the exact problem. Therefore sorry for the rather long script, but it is relatively hard to reproduce. |
|
@philbucher Tere is a test with expected failure in the kratos core. Cold you see if it is the same error? |
|
Which test are you referring to? I looked at the tests of model_part and GidIO but I couldn't find anything related to this |
|
I have not check the test you sent but everything is pointing to a memory error by using a nodal variable which is not added. You can check this by building the FullDebug version of Kratos as described in wiki |
|
… On Oct 10, 2017 5:08 PM, "Philipp Bucher" ***@***.***> wrote:
Which test are you referring to? I looked at the tests of model_part and
GidIO but I couldn't find anything related to this
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#492 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHr7ETXLBaeq5CTtaEkswt0vgHE00zC4ks5sq4hUgaJpZM4N4E0G>
.
|
|
@RiccardoRossi the test fails as expected |
|
I have no clue but the expected fail given by @RiccardoRossi will be solved by hash variables. So if is the same reason the solution would be the same. |
|
I think what @RiccardoRossi means is a different issue |
|
Let me check it... |
|
Do you have an updated version of the test you posted? It gives me a python error before crashing: |
|
That is unfortunate, for me it works, I am on the latest version of the master branch. Are you using an older version? |
|
I am not 100% sure but I think this could actually be related to the problem. I remember that when I first encountered this problem I had similar errors. That was part of the reason why it took so long to debug. |
|
It was in my branch from Monday. Let me check it with master branch now. But it gives me an idea that maybe you have two incompatible binaries for core and application you have. |
|
I have still the same signature error. @philbucher would you please check it by yourself? |
|
I get the following output: Do you have an idea what else we can do? |
|
in master? There is something wrong with my compilation then (or maybe yours which cause this segmentation fault) |
|
With master branch last night I could not reproduce it.... It crashes before. |
|
That is unfortunate. |
|
@RiccardoRossi is looking into it also |
|
Hi @philbucher i have been looking into this. This is some memory error, and i would bet that it is OpenMP related. i tried out with Valgrind, and it is far from clean. Here is the log. Could u take a look at it? (code compiled with FullDebug + -D_GLIBCXX_DEBUG) | / | No inverted elements found valgrind: m_mallocfree.c:303 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. host stacktrace: sched status: Thread 1: status = VgTs_WaitSys (lwpid 8758) Thread 2: status = VgTs_WaitSys (lwpid 8767) Thread 3: status = VgTs_WaitSys (lwpid 8768) Thread 4: status = VgTs_WaitSys (lwpid 8769) Thread 5: status = VgTs_Yielding (lwpid 8770) Thread 6: status = VgTs_Runnable (lwpid 8771) Thread 7: status = VgTs_Yielding (lwpid 8772) Note: see also the FAQ in the source distribution. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind Compilation exited abnormally with code 1 at Thu Oct 26 13:30:50 |
|
I usually run with one thread now I tried with 1 and with 6 threads, valgrindoutput is attached We also tried with Klaus' computer, same Problem |
|
@philbucher so before more debugging I would suggest you to clean the memory problem.... |
|
How do you mean? |
|
Yes of course! Actually yesterday I thought the first error is directly in your application but now in your txt I saw that it is in initialize and clone time step. Would you please try to reduce the script removing any application and steps that won't alter the first errors in the valgrind? we need a smaller test to deal with. (of course if is possible) |
|
I reduced the test as much as I could |
|
@RiccardoRossi are you on this? |
|
well, the error is now clear. You can not import variables after having called the ImportModelPart function. bad thing is that we currently have no mechanism to protect from this. I will post a proposal of what to do later on during the day (can not do it right now) |
|
While what @RiccardoRossi is saying is 100% true, in @philbucher's script someone is reading the Note that this is one of my motivations for #869. EDIT: The cause of the SegFault is the addition of the PENALTY variable out of place in the script (it does not SegFault if I just comment out the addition). Please don't add variables after reading the ModelPart. |
|
I also know that I should not add the Variables after ImportModelPart. @jcotela the penatly variable was chosen randomly, just for demonstration purpose |
|
My proposal in order to catch those errors would be to define in the root model part initialized by default to false. We could then add a function say which sets the variable to true. Such functions could be called at the beginning of the ImportModelPart function. if then in the AddVariables we check if the variable is frozen, we would easily catch this sort of errors (or have the same behaviour as now if we never call the freezing function |
|
Checking with @pooyan-dadvand, in this particular instance the error may be related to a bug in AddNodalSolutionStepData (it should work as it is done in SetBufferSize, but some code appears to be missing). |
|
An alternative solution to @RiccardoRossi proposal would be to check in |
|
+1 for pooyan |
|
+1 for Pooyan's solution too |
|
just to tell that i made PR #928 to implement the idea |
|
I close it as PR #928 merged. |
If GiDIO is initialized with a modelpart where variables have not been added yet it exits with Segmentation Fault. This is not so nice to debug, can a check be implemented for that?
The text was updated successfully, but these errors were encountered: