-
Notifications
You must be signed in to change notification settings - Fork 451
Fix undefined behavior in MPAS registry parser #7955
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
base: master
Are you sure you want to change the base?
Fix undefined behavior in MPAS registry parser #7955
Conversation
With `gcc` v13.3.0, I'm seeing unparsable `if (Active .or. analysisModeActive)` clauses in the file `components/mpas-ocean/src/inc/structs_and_variables.inc` generated by the registry parser. The issue appears to be that the registry parser is reading from and writing to the same string in statements like: ``` sprintf(out_packages, "%s;%s", out_packages, token); ``` This is not allowed, as it can lead to race conditions and bad output like I am seeing. This fix avoids this undefined behavior when appending to `out_packages` in the registry parser.
|
@jonbob, if need be, I can post a bug about that and make this a bug fix. |
MPAS-Ocean Standalone TestingSo far, I have only tested this fix in MPAS-Ocean standalone, where I encountered it. I am able to build MPAS-Ocean with gcc/gfortran 13.3.0 with this fix but not without it. I am also able to successfully run various Polaris tests with the resulting build. Testing with E3SM involving all MPAS components is needed to make sure no harm is done, but the changes are simple enough that I doubt we will see problems. |
|
@xylar -- only if you want to for completeness. I don't believe it's necessary when the issue turned up only with standalone mpaso |
That was my thinking as well. It seems worth fixing because it will likely come up in E3SM in the future as we move to gcc 13. |
matthewhoffman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm approving by inspection - the changes make sense to me to fix the problem described.
mark-petersen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good. I see you are just adding a temporary character string with a fixed size. Passes the following on perlmutter:
./create_test SMS_Ln9.TL319_ECwISC30to60E2r1.GMPAS-JRA1p5.pm-cpu_gnu -p e3sm -q debug --walltime 00:30:00
./create_test SMS_Ln9.TL319_ECwISC30to60E2r1.GMPAS-JRA1p5.pm-cpu_intel -p e3sm -q debug --walltime 00:30:00
./create_test SMS_Ld3.ne30pg2_EC30to60E2r2.WCYCL1850.pm-cpu_gnu -p e3sm -q debug --walltime 00:30:00
This passes with both gnu and intel compilers.
|
@darincomeau, let me know if you can take a look, or feel free to assign someone else from the sea-ice development team. |
|
BTW, @mark-petersen's tests should also presumably show that things are working for MPAS-Seaice. |
With
gccv13.3.0, I'm seeing unparsableif (Active .or. analysisModeActive)clauses in the filecomponents/mpas-ocean/src/inc/structs_and_variables.incgenerated by the registry parser.The issue appears to be that the registry parser is reading from and writing to the same string in statements like:
This is not allowed, as it can lead to race conditions and bad output like I am seeing. This fix avoids this undefined behavior when appending to
out_packagesin the registry parser by writing to a temporary string and copying back.[BFB]