forums.silverfrost.com

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

Robert, yes, this is a side effect of memory being filled with spaces, incorrectly, wiping out local variables, and constants that would nominally be correct for error-free operation. The reason for this is mystifying especially since I did a test where none of my code was run, yet local variables did not have their set values (via a DATA statement).

I am no longer concerned about LENG8$, it is operating correctly if given correct inputs. In this case, it was not.

mecej4 · Joined: 31 Oct 2006 Posts: 1899

Robert wrote: "It isn't byte 0x20 repeated, it is 0x02 repeated".

The index variable I_LOGMTR pertains to character*16 variables. The instructions

MOVSX_Q RBX,I_LOGMTR
IMUL_Q RBX,16_4

cause RBX to contain I_LOGMTR shifted left by one nybble, before the call to LENG8$, and the function does not touch RBX.

Robert · Joined: 29 Nov 2006 Posts: 457 Location: Manchester

Ah, I see.

StamK · Joined: 12 Oct 2016 Posts: 167

So what is the conclusion from this thread? Is it an ftn95 bug (zeroing not happening properly) or is it a user error?
I am asking because I occasionally get the same error (cannot easily repeat it).

mecej4 · Joined: 31 Oct 2006 Posts: 1899

My assessment is that there could be no conclusion, since no reproducer was provided. From the code fragments that were shown, speculations were made.

A reexamination allows me to suspect that it was an error in the user code. Here is a short test program that may help you if your code has the same error as in the test program.

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

mecej4,

I read your post, then re-read the thread. One thing you missed in your assumption of an error in my code: This is a local variable (0:2) and other local variables have been initialized/modified to be (hex) 2020... sequences. Even floating point constants. Bizarre. And the 32-bit version of the code runs just fine.

StamK indicates that this also happens to him occasionally and he cannot easily repeat it either.

mecej4 · Joined: 31 Oct 2006 Posts: 1899

Bill,

You did say that i_logmtr was local and had values in the range 0..2; later, you wrote "That is - every local variable I looked at contained the same pattern of (hex) 20202020", but I did not know if that applied to the feet_or_meters_scale array and if that array was local.

This new errror (all variables set to values of Z'20202020') is, by itself, worthy of analysis. Can you provide a reliable reproducer for this error? That would help.

Noting that your OP was made a year ago, I looked at the code of LEN8$ in the most recent version of CLEARWIN64.DLL, and found that it was the same as in the older version (which was listed in an earlier post in this thread).

PaulLaidler · Posted: Wed Jan 26, 2022 5:58 pm Post subject:

I have not followed the discussion on this thread but LENG8$ is the same as LEN_TRIM except that it returns an INTEGER*8 value.

So it would only be needed for CHARACTR variables with length LEN(str) greater than 2,147,483,647 (very long). It scans from the end looking for the first character that is not a space (0x20).

I would need to check the explist to see if FTN95 is sending it an INTEGER*8 value as the input for its LEN.

PaulLaidler · Posted: Thu Jan 27, 2022 10:52 am Post subject:

This is a correction to my last post.

FTN95 implements LEN_TRIM(string, kind=k) where k defaults to 3. For 64 bits, regardless of k, it calls LENG8$ and passes a 64 bit value for LEN(str). LENG8$ returns a 64 bit value that is moved (via MOV, MOV_Q etc.) to the "destination". For example, a simple assignment to an INTEGER*4 will use a 32 bit MOV whilst an assignment to an INTEGER*8 will use a 64 bit MOV_Q.

It is possible that this is not the best strategy and a review may be required. In particular, there may be problems when LEN_TRIM is called within a function or subroutine argument list.

If this turns out to be the case then a temporary fix is to remove the call to LEN_TRIM from the argument list and to provide a simple assignment (to a temporary INTEGER of the required kind) before the call.

mecej4 · Joined: 31 Oct 2006 Posts: 1899

Here is a test program that exhibits many of the malfunctions encountered in 64-bit runs by Wahorger, as described earlier in this thread.

PaulLaidler · Posted: Fri Jan 28, 2022 9:20 am Post subject:

Thanks. I will take a look at this.

mecej4 · Joined: 31 Oct 2006 Posts: 1899

Two properties of the SDBG64 debugger that I noticed as being handicaps while probing this issue at the assembler level:

1. A bug in the disassembler, as reported at http://forums.silverfrost.com/viewtopic.php?t=4594 .

2. The string length parameter, 16, is a constant stored in the data segment. It may be represented by an address such as "[50b0]$" in the disassembly and /EXP listings, and it took several disassembly runs to associate 50b0 with the character length. For instance, the EXP listing shows

Robert · Joined: 29 Nov 2006 Posts: 457 Location: Manchester

You are correct about the $. RBP is loaded with the DLL/EXE's load address and then data is referenced from it.

PaulLaidler · Posted: Sat Jan 29, 2022 9:43 am Post subject:

mecej4

Thank you for your feedback. I can now confirm your analysis.

At the moment I can't think of a way to avoid this failure (apart from correcting the Fortran source code) nor how to provide a meaningful error report when the source code contains this bug.

PaulLaidler · Posted: Sat Jan 29, 2022 10:11 am Post subject:

mecej4

I have changed LENG8$ so that your sample code will give a runtime failure
"Memory corrupted before call to LEN_TRIM".

This is not very helpful but better than nothing.