Program Hangs When Comparing Zero-Length Allocatable Character String

[Craig_T_Dedo]

My Fortran program hangs when it uses one of the 6 relational operators (==, /=, >, >=, <, <=) on character strings and one of the strings has a zero length.  The zero-length character string is an allocatable varying-length character string.

This problem does not occur if the character string is any other length.

I am encountering this problem while doing consulting work for the Bank of New York Mellon (BNYM).  Currently, BNYM is using Intel Fortran 19.1.3 under Linux.  Due to security requirements I cannot post a copy of the source code.

Is this a known problem with Intel Fortran 19.1.3?  If so, has it been corrected in a subsequent version of Intel Fortran?  If it has been corrected, what version contains the correction?

[Steve_Lionel]

Minimal reproducible example, please. From your description it should be easy to create one.

[jimdempseyatthecove]

>>The zero-length character string is an allocatable varying-length character string.

Due to the fact that your strings are allocatable, I assume that your relational operator code is encapsulated by an:

   if(allocated(yourstring)) then...else...endif

and thus, your exception code could easily add a test for len(yourstring)==0 test.

I agree, the compiler should not generate code that hangs.

Jim Dempsey

[Steve_Lionel]

Allocatable, deferred-length character strings never have to be explicitly allocated - they can get allocated and reallocated by intrinsic assignment. If a bug here really did exist in the 19.1 compiler, we would have seen it much earlier.

Also, it's unclear what "hang" means here - is it an infinite CPU loop, or a pause in operations? Nevertheless, if Craig is unable or unwilling to provide a test case that demonstrates the problem, he'll have to analyze the issue himself, perhaps by stepping through the assembly code to see what it is doing. My experience is that most problems like this are resolved by the process of trying to construct a test case and realizing what the problem really is.

[Craig_T_Dedo]

Hi Steve:

Thanks for your reply.  By "hanging", I mean that the program is unresponsive at the statement where the string comparison is done.  E.g., if we have:

If ( A == B ) Then

    . . .

and B is of zero length, then the program will be unresponsive.

Unfortunately, due to security and confidentiality requirements, I can't provide the exact source code without permission from management at BNYM.  Perhaps later today I can work up some examples on my own time and run them on my own machine which is running Intel Fortran 2021.3.0 under Windows.  If I can do this, then I will post the results of this experiment.

I did construct a work-around.  I tested the length of the allocatable string and, if it was zero, then I set it to one blank. That band-aid "fix" was consistent with the requirements of the program and allowed the program to work correctly without becoming unresponsive.

[Steve_Lionel]

See how easy it is?

D:\Projects>type t.f90
program test
character(:), allocatable :: a, b
a = ''
b = ''
print *, len(a), len(b)
print *, (a == b)
b = 'ABCDE'
print *, len(a), len(b)
print *, (a == b)
print *, "Done"
end
D:\Projects>ifort t.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.3.311 Build 20201010_000000
Copyright (C) 1985-2020 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.29.30139.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:t.exe
-subsystem:console
t.obj

D:\Projects>t.exe
           0           0
 T
           0           5
 F
 Done

D:\Projects>

[mecej4]

The example that Steve_Lionel  gave is actually a counter-example to Craig_T_Dedo's statement, "and B is of zero length, then the program will be unresponsive".

Steve's example shows that, with the possible exception of different behavior on Linux than on the Windows system that Steve used, and the effect of compiler options that Craig_T_Dedo used but did not list, the circumstances and conditions listed by Craig are not sufficient to reproduce the error. It is possible that not all the conditions are necessary, either!

From my own experience with reporting many such compiler bugs, I have learned that sometimes bugs are quite fragile, and first attempts to construct a short reproducer may fail completely. In a few cases, I had to work from both ends, adding more code to a small reproducer and removing code that I felt not necessary in the large code, and stopping when the smaller code showed the bug or when the larger code stopped showing the bug.

[Steve_Lionel]

I modified my test to make B zero length and A non-zero - no difference. I maintain that the issue is something else entirely, but without a test case, I'm not willing to put any more effort in. I will guess that there is an error somewhere else in the program, possibly data corruption caused by a programming error.

Craig should know, as a former member of the Fortran standards committee, that assuming a compiler bug and asking when it would be fixed, without an example, is pointless.