ice_calendar: zero-initialize 'nstreams' #752
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR checklist
title
me
I checked that the code runs fine with the fix when compiling with
-init=huge
. It crashes without the fix.I ran the
base
,decomp
andnothread
suites with the fix and-init=huge
and everything passed as expected.The variable ice_calendar::nstreams, which corresponds to the number of
output history streams to use for the run, is initialized in
ice_history::init_hist depending on the number of non-'x' elements in
'histfreq' in the namelist.
However, the code does use 'nstreams' before ice_history::init_hist is
called, in ice_calendar::calendar when called from
ice_calendar::init_calendar. Both 'init_calendar' and 'init_hist' are
called from CICE_InitMod::cice_init, in that order, such that the loop
that initializes 'write_history' in 'calendar' uses 'nstreams'
uninitialized.
'calendar' ends up being called at least once more during 'cice_init', from
ice_calendar::advance_timestep, at which point 'nstreams' is correctly
defined and 'write_history' is thus correctly initialized, before its
first use in 'accum_hist'.
To avoid using 'nstreams' uninitialized in the first call to 'calendar'
from 'init_calendar', initialize it to zero in 'init_calendar' before
calling 'calendar'.
This issue was discovered by compiling using the '-init=huge' flag of
the Intel compiler.