Skip to content
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

SAL: Explicitly allocate sht variable in SAL_CS #627

Merged
merged 3 commits into from
May 14, 2024

Conversation

marshallward
Copy link
Member

For reasons not entirely clear, deallocation of the RK2 control structure caused a segmentation fault when compiled by Nvidia. A deeper investigation suggested that the compiler was attempting to deallocate a nullified pointer during automatic cleanup of RK2->SAL->sht. Apparently deallocation of a NULL pointer is an error (even though free() is not supposed to care).

By redefining sht as an allocatable component rather than a local component of the SAL_CS instance, it seemed to satisfy the compiler that nothing was needed and the error went away.

There are still some lingering questions behind the cause of the segfault, but for now I am going to put this under "compiler bug".

This patch also initializes some of the logical flags in the SAL_CS type. This is possibly unnecessary, but it is consistent with the general rules of safety followed in other MOM6 derived types.

For reasons not entirely clear, deallocation of the RK2 control
structure caused a segmentation fault when compiled by Nvidia.  A deeper
investigation suggested that the compiler was attempting to deallocate a
nullified pointer during automatic cleanup of RK2->SAL->sht.  Apparently
deallocation of a NULL pointer is an error (even though free() is not
supposed to care).

By redefining `sht` as an allocatable component rather than a local
component of the SAL_CS instance, it seemed to satisfy the compiler that
nothing was needed and the error went away.

There are still some lingering questions behind the cause of the
segfault, but for now I am going to put this under "compiler bug".

This patch also initializes some of the logical flags in the SAL_CS
type.  This is possibly unnecessary, but it is consistent with the
general rules of safety followed in other MOM6 derived types.
@marshallward
Copy link
Member Author

The issue appears to be resolved: https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/jobs/127658

@marshallward
Copy link
Member Author

@marshallward marshallward merged commit 0c790f2 into NOAA-GFDL:dev/gfdl May 14, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants