Floating Point Stack Fault, slink problems

0. I've got 32-bit XP, SP3, ft995 5.50. It's a Dell Dimension 8250, so its a few years old.
1. On my PC, slink crashes with AV (fgetc) when in interactive mode (it writes the * to the console, then crashes). It works on another machine with identical hardware with XP, SP3. It works OK with command line arguments, so my makefile works. 2 a. When I run the executables, I get a floating stack fault. On another computer, the executables run OK. 2 b. When I run the crashing program via sdbg, it crashes with floating point error in a routine that reads an integer array from a disk file (NOT the place reported in the original traceback). In fact, in this routine, all variables are of type integer.
2. In another project, I have not encountered any problems with the floating point stack problem.

Any clues? Are the AV and FP stack fault part of the same thing, or are they separate issues?

Further digging. I have found another PC where slink falls over with an AV. This is the dump of the error

########## Runtime error from program:c:\salford\ftn95\slink.exe Access Violation The instruction at address 1001b39d attempted to read from location 006e006d

1001b1e8 fgetc [+01b5]

1001bb0c fgets [+0278]

00402398 readCommand(<ptr>char) [+0057]

0040a136 acceptCommands(void) [+003c]

0040caf4 main [+009d]

eax=00048530 ebx=000033ab ecx=00000000 edx=00000000 esi=004f2394 edi=006e0069 ebp=0370e798 esp=0370e6dc IOPL=1 ds=0023 es=0023 fs=003b gs=0000 cs=001b ss=0023 flgs=00010206 [NC EP NZ SN DN NV]

1001b39d movb cl,[edi+0x4] 1001b3a0 movb [ebp-0x16],cl 1001b3a3 mov esi,[edi] ############# The same box can go on to make all the required exeutables, which seem to run OK

On the face of it that instruction shouldn't cause an access violation. Are you sure there is only one copy of salflibc on the machine (and it is the one you expect it to be)?

Access violations are caused when an instruction tries to access a memory location it doesn't have the right to use. FP stack faults can also mean the same thing (on a floating point instruction) but can also refer to specific floating point issues (like to many numbers on its stack).

There are multiple copies/versions of salflibc.dll on the disk from previous builds/releases of our program. I have checked that, if there is a salflibc.dll in the current directory, it is the same as the currently installed version. I have also checked the PATH environment variable and there is only one directory containing salflibc.dll and that's the compiler directory.

I tried interactive slink on my home PC and it also fell over with the AV. I'm pretty sure there is only one version of salflibc.dll on that machine, though.

it crashes with floating point error in a routine that reads an integer array from a disk file

I've encountered this as well, namely with underflowed floating point values that came from external sources (directly reading in a float array or interfacing with a C .DLL) which don't trigger the FPU exception when it first occurs but later at innocent-looking IO operations (write , or general file operations). It seems like the IO operations change the FPU control word temporarily thus the still-existing FPU exception flag causes a program exception.

At this point I would not worry about this exception as it may be related to the bad linking of the executable (missing data/bad code).

I have discovered the cause of the floating point stack fault. I set the environment variable SALFENVAR=MASK_UNDERFLOW. Removing this made the crash go away.

I think that I set this in an attempt to get round another problem, but that I solved that one by fixing program source. Then I forgot to unset the environment variable.

The slink problem remains, however. Version 1.44 (shipped with ftn95 5.50) shows the problem, but versions 1.43 and 1.42 (shipped with 5.40 and 5.30 do not show it.

Meantime, I've acquired a new(ish) (and faster) computer from our IT people, so the problem had some good consequences.