forums.silverfrost.com

Kevin · Joined: 01 Mar 2012 Posts: 34 Location: Ascot, UK

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

PaulLaidler · Posted: Sat Feb 24, 2024 8:30 am Post subject:

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?

Kevin · Joined: 01 Mar 2012 Posts: 34 Location: Ascot, UK

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.

PaulLaidler · Posted: Mon Feb 26, 2024 6:04 pm Post subject:

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.

Kevin · Joined: 01 Mar 2012 Posts: 34 Location: Ascot, UK

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 ?

PaulLaidler · Posted: Tue Feb 27, 2024 9:31 am Post subject:

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.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

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 !!

mecej4 · Joined: 31 Oct 2006 Posts: 1886

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.

Kevin · Joined: 01 Mar 2012 Posts: 34 Location: Ascot, UK

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!