Access Violation in CCOPY

We are getting a few cases whereby users are seeing an Access Violation in CCOPY. eg.

The instruction at address xxxxx attempted to write to location 7fff1000

xxxxx CCOPY#[+0026] xxxxx xxxxx

This is with code that hasn't changed for donkeys years. The latest case shows up with a customer who has migrated from WinServer 2012 to 2022 using Citrix. Is it a memory clash with something else on the system ? We can't reproduce it ourselves and the customer fixes it by re-booting, but then it comes back again later. Thanks, Kevin

Kevin

1. Is it 32 bits or 64 bits?
2. Do you know what is calling CCOPY#?
3. Which version of FTN95 and the Silverfrost DLLs are being used?

Paul,

1. 32bit
2. Either GET_STORAGE@ or GET_GSTORAGE@ although they and the routine that calls them do not appear on the traceback.
3. FTN77 v4.02 and SALFLIBC v12.2.27.20 (27-FEB-2010)

I know what you are going to say and we did try and re-build with a v8.80 of the compiler and dll but hit a different access violation starting in yield_program_control and finishing in constructed_button_procedure@ We couldn't fix that so had to wind back to the old version.

Kevin

Did you really mean FTN77 or should it be FTN95?

Either way, I would need to be able to step through the code and that is not going to be possible for versions dating back to 2010 and before.

Paul, I'm afraid I did mean FTN77. (If it ain't broke, blah blah blah)

As I said, we can't reproduce the crash, so even if you could step through the code, there is no guarantee that it will misbehave.

Any clue as to what CCOPY is doing at that line number ?

I quote: 'CCOPY@ performs character copying operations where one or both of the lengths is unknown at compile time'.

For FTN77 and 32 bit FTN95 the routine is coded directly in assembly code. Here is the 64 bit FTN95 form written in C.

extern 'C' void CCOPY$(const char* source, char* dest, long long sl, long long dl)
{
  char* q = NULL;
  char* d = dest;
  if(sl < 0) sl = 0;
  if(dl < 0) dl = 0;
  if(source < dest && source+sl > dest)
  {
    q = (char*)stack_malloc(sl);
    memcpy(q,source,sl);
    source = q;
  }
  if(dl <= sl)
  {
    memcpy(d,source,dl);
  }
  else
  {
    memcpy(d,source,sl);
    memset(d+sl,' ',dl-sl);
  }
  if(q) stack_free(q);
}

It is typically used by the compiler for Fortran character concatenation when the process is not simple.

In F77, this type of error could have occurred if generating a concatenated string into itself. It can be overcome by using an explicit defined destination string that is long enough, then copying the result string back to the original destination, with explicit size limits on the final string. My memory is F77 did not like concatenation that overflowed the destination length, and this was best to check in the Fortran code. F95 was reliable by 1998, so I stoped using FTN77 a long time ago. Windows made FTN77.exe difficult to use a long time ago !!

Kevin,

As you probably know, the more users with diverse PC hardware and Windows versions use your code, the more likely it is that bugs will be noted and fixed.

If you are able and willing to provide a reproducer with instructions, the issues that you wrote about may be possible to observe and fix. If, as you said, 'hasn't changed for donkeys years', the original code itself may serve as a reproducer. If the code ran on a 640K PC, the chances are good, unless the suspected bugs are related to 16-bit Windows API calls.

Thanks all for the feedback. As I mentioned, we can't reproduce the issue ourselves, so it must be dependent on machine configuration or customer data (as most memory-overwrite issues are). We will try again to update our code to the latest version of FTN95 but that could be a long-haul as I'm dealing with nearly 2 million lines of code!