-
Notifications
You must be signed in to change notification settings - Fork 845
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address sanitizer tests in the CI pipeline #2246
Conversation
Discussion #2213 is about fixes for the address sanitizer detections in the |
Maybe we can avoid creating another instance is the surface_movement pointer is not nullptr when the init function is called? In CDriver we would just make sure all surface_movement are initialized to nullptr. |
Yeah, that would be an alternative to creating |
The address sanitizer reports a heap buffer overflow for this piece of code. I presume the issue is the access
Is someone familiar with the Below is the address sanitizer report, see also here.
|
@joshkellyjak can you take a look at the issue above? Thanks |
I think the issue is looping jSpan between 0 and nSpanDonor-1, I think it should be looped between 1 and nSpanDonor-2 (as is done in the higher level of the for loop) as the hub and shroud are handled seperately and there is no interpolation performed here. Admittedly, this is probably the area of the turbomachinery code I am most unfamiliar with. |
Thanks @joshkellyjak! I'll try this. |
Interesting that only one of the tests fails - to be honest I was expecting all the turbomachinery tests to fail, does this solve the heap overflow? |
The address sanitizer records are clean with this fix 👍 |
Hi all, I've just tried to run the Aachen parallel regression test locally (code from SU2 feature_asan, restart files from SU2/TestCases) and I get a pretty different outcome than the PR here. residuals I get locally: residuals I see as a result of the regression test: Also, feature_asan doesn't have any Aachen_turbine folder among the testcases. |
Hi @alecappiello, thanks for joining the discussion.
If you use your local environment for building and running (as opposed to the containers), that can lead to differences, too (although it's not a good sign if they are large). So I think the question is rather, with the changes in the @bigfooted reports that the Aachen turbine case in current develop is not deterministic (see here and here), that could be an issue, too. If it is due to memory issues, the changes in this PR might fix this.
I see this Aachen turbine folder, is it not the correct one? |
@alecappiello The Aachen turbine case is in the |
Hi @jblueh, I double-checked and you're right. Sorry for that. I'm installing the right one now. |
I'm not sure about what is the cause of this poorly deterministic behaviour. I can imagine that the convergence level of the restart plays a role. I'll be running some tests with better converged restart files and let you guys know |
@alecappiello As the restart files were not obtained with the changes in this branch, maybe they are no longer consistent and need to be updated? |
@alecappiello Any news from your side? |
To get this PR going, I have reverted the proposed fix c97610b for now and excluded the Aachen turbine test case from address sanitizer testing. I'll create an issue about this. |
Sorry for my late reply. Unfortunately, I don't have great news. I have tried restarting the calculation by means of feature_asan from:
|
To my understanding they should work as the others... |
Proposed Changes
This PR automates the address sanitizer analysis that lead to the fixes in #2212. I'll make the additions step by step, to see if things in the CI pipeline work as expected.
Related Work
su2code/Docker-Builds#24, #2212, #2068, #2213
PR Checklist
pre-commit run --all
to format old commits.