Fortran substring runtime errors: forrtl: severe (408): fort: (12):
ktarbet opened this issue · comments
Summary: When running HMS test suite a Fortran runtime error causes a failure.
It has been difficult to reproduce unless the full test suite is run.
The following errors are from different program runs, The difference is different DSS_JNI_MESSAGE_LEVEL values.
forrtl: severe (408): fort: (12): Variable CLINE has substring ending point 5 which is greater than the variable length of 4
forrtl: severe (408): fort: (12): Variable CLINE has substring ending point 65 which is greater than the variable length of 64
forrtl: severe (408): fort: (12): Variable CLINE has substring ending point 115 which is greater than the variable length of 4
DSS_JNI_MESSAGE_LEVEL=4
forrtl: error (63): output conversion error, unit 15, file C:\project\hms-testing-utils\hms-benchmark-runner\build\resources\test\Bench11_3.0\Bench11_3.0.out
Stack trace terminated abnormally.
forrtl: severe (408): fort: (12): Variable CLINE has substring ending point 5 which is greater than the variable length of 4
Stack trace terminated abnormally.
forrtl: The handle is invalid.
forrtl: severe (38): error during write, unit 15, file C:\project\hms-testing-utils\hms-benchmark-runner\build\resources\test\Bench11_3.0\Bench11_3.0.out
forrtl: severe (28): CLOSE error, unit 15, file "Unknown"
DSS_JNI_MESSAGE_LEVEL=5
lots of debug output starts going to console instead of output file.
DSS_JNI_MESSAGE_LEVEL=6
forrtl: severe (408): fort: (12): Variable CLINE has substring ending point 5 which is greater than the variable length of 4
DSS_JNI_MESSAGE_LEVEL=7
one run Ok. not consistent.
forrtl: severe (408): fort: (12): Variable CLINE has substring ending point 5 which is greater than the variable length of 4
Stack trace terminated abnormally.
forrtl: The handle is invalid.
forrtl: severe (38): error during write, unit 15, file C:\project\hms-testing-utils\hms-benchmark-runner\build\resources\test\Bench11_3.0\Bench11_3.0.out
forrtl: severe (28): CLOSE error, unit 15, file "Unknown"
DSS_JNI_MESSAGE_LEVEL=10
forrtl: severe (408): fort: (12): Variable CLINE has substring ending point 5 which is greater than the variable length of 4
DSS_JNI_MESSAGE_LEVEL=15
not Consistend. One run appeared OK. However, output switched to console (last of file log below)
-----DSS---Debug: Enter zset6; Flag: MUNI, Numb: 6, String:
09:36:08.098 =====DSS===Debug: zset; Entering
09:36:08.098 =====DSS===Debug: zset; Parameter: MUNIT
09:36:08.098 =====DSS===Debug: zset; character val:
09:36:08.098 =====DSS===Debug: zset; integer val: 6
--- another failing run ---
forrtl: severe (408): fort: (12): Variable CLINE has substring ending point 5 which is greater than the variable length of 4
Stack trace terminated abnormally.
forrtl: The handle is invalid.
forrtl: severe (38): error during write, unit 15, file C:\project\hms-testing-utils\hms-benchmark-runner\build\resources\test\Bench11_3.0\Bench11_3.0.out
forrtl: severe (28): CLOSE error, unit 15, file "Unknown"
one interesting behavior , when debugging this issue is sometimes the console output stops going to the log file and switched to the console (when running from gradle). DSS has a feature to set the message unit zset('MUNI') and sometimes that seems to be getting set.
@perrymanmd When looking at files with CLINE I came up with a Fortran question:
What implicit variable type will be assigned to CLINE in the bottom of this file: hec-dss\heclib\heclib_f\src\zcorec6.f
Will Fortran look inside the function being called to figure out the variable type?
Nope. The implicit type for any variable not starting with I..N is Real. This could be a problem!
Sorry - forgot to tag @ktarbet.
Nope. The implicit type for any variable not starting with I..N is Real. This could be a problem!
Thanks @perrymanmd. Good news - looks like the method is not being used. Here is a PR to remove:
#111
The following errors are after renaming all making CLINE variables unique to each routine. CLINE32 is unique to the file:
https://github.com/HydrologicEngineeringCenter/hec-dss/blob/debug/cline/heclib/heclib_f/src/Support/upcase.f
[12:41:14]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 349 which is greater than the variable length of 4
[12:41:51]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 6 which is greater than the variable length of 4
[12:42:15]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 5 which is greater than the variable length of 4
[12:42:21]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 5 which is greater than the variable length of 4
---------- HEC_HMS_DEV_BENCHMARKS_1478.LOG
[15:59:42]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 5 which is greater than the variable length of 4
[16:00:23]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 103 which is greater than the variable length of 4
[16:03:07]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 86 which is greater than the variable length of 4
thanks @MikeNeilson for finding strlen(epart) typo, Unfortunately looks like we still need to keep looking.
---------- HEC_HMS_DEV_BENCHMARKS_1483.LOG
[13:14:08]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 5 which is greater than the variable length of 4
[13:14:24]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 65 which is greater than the variable length of 4
[13:14:26]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 95 which is greater than the variable length of 4
[13:16:48]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 6 which is greater than the variable length of 4
[13:18:45]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable CLINE32 has substring ending point 264 which is greater than the variable length of 4
[13:18:45]W: [Step 1/1] forrtl: severe (28): CLOSE error, unit 80, file "Unknown"
Unfortunate that it didn't fix this problem. But at least we know THAT won't cause others now.
many errors indicate the string has a length of 4. That would be something like '1DAY' in a call to get interval type JNI methods
printing input for all calls to upcase()
excerpt below is around one of the errors. Unfortunately we are not getting a stack trace even though we have /check:all and / /traceback compiler flags.
Upcase(MLEV)
[09:30:59] : [Step 1/1] Upcase(
[09:30:59] : [Step 1/1] //JR R1220-MC30/FLOW//30MIN/RUN:MC_HEC_MC_Jan02_GR/
[09:30:59] : [Step 1/1]
[09:30:59]W: [Step 1/1] forrtl: severe (408): fort: (12): Variable LOWER_CASE_INPUT has substring ending point 5 which is greater than the variable length of 4
[09:30:59] : [Step 1/1]
[09:30:59]W: [Step 1/1]
[09:30:59] : [Step 1/1]
[09:30:59]W: [Step 1/1]
[09:30:59] : [Step 1/1] Upcase(01Jan1999 )
[09:30:59] : [Step 1/1] Upcase(MLVL)
[09:30:59]W: [Step 1/1] Stack trace terminated abnormally.
[09:30:59] : [Step 1/1] )
[09:30:59] : [Step 1/1] Upcase(MLEV)
Can you put in some debugging code to print the stack trace whenever Upcase() gits that specific string?
I'm able to force a full stack trace in the DSS-C test program, but not yet working with javaHeclib.dll.
I've created a one layer-up stack trace by manually passing in the caller locations to Upcase("who is calling", input). Also we got a JNI crash which may be helpful.
zinqir6.f Upcase(UNIT); LEN= 4
zgintl6.f Upcase(1MIN); LEN= 4
zsrtsi6.f Upcase(
); LEN= 128
zsrtsi6.f Upcase(
); LEN= 128
zsrtsi6.f:248 Upcase(
forrtl: severe (408): fort: (12): Variable LOWER_CASE_INPUT has substring ending point 5 which is greater than the variable length of 4
Stack trace terminated abnormally.
PRECIP-CUM
); LEN= 128
datymd.f Upcase(1 January 2000); LEN= 14
▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌); LEN= 20
#
# A fatal error has been detected by the Java Runtime Environment:
#
replacing the Fortran UPCASE with a C upcase_ may have resolved the issue.