Silverfrost Forums

Welcome to our forums

Sporadic \"crash\" when exiting

26 Jul 2017 7:34 #19894

I have a customer that is able to repeat consistently something that only happens to me sporadically. Namely, a crash that occurs when the user has asked the program to exit, and after all the clean-up has occurred. Interestingly, all of the crashes have the same basic 'signature' but all occur at different instructions and access violation at different memory addresses.

I do not dynamically allocate any arrays. All compilations are done with /SAVE.

Runtime error from program:c:\program files (x86)\cmaster\c-master.exe
Access Violation
The instruction at address 119c7642 attempted to read from location 1146beac

 119c7500 __winexit [+0142]
 119c1702 do_atexits(void) [+0018]
 119c180a __fortranexit [+000c]
 11abc676 DEBUGEXIT# [+0016]
 11abfcc0 STOP# [+0066]
 CEXIT -  in file cexit.for at line 53 [+055b]
 main -  in file cmain.for at line 175 [+1fd9]
 006931c6 SALFStart [+06ff]

eax=11415840   ebx=00000026   ecx=1146bea8
edx=00000000   esi=113af55c   edi=00000000
ebp=113af488   esp=113af460   IOPL=2
ds=002b   es=002b   fs=0053
gs=002b   cs=0023   ss=002b
flgs=00010202 [NC OP NZ SN DN NV]

 119c7642  push     [ecx+0x4] 
 119c7645  call     11af7b10 
 119c764a  lea      esp,[ebp-0xc] 



Runtime error from program:c:\program files (x86)\cmaster\c-master.exe
Access Violation
The instruction at address 11b47642 attempted to read from location 115ebeac

 11b47500 __winexit [+0142]
 11b41702 do_atexits(void) [+0018]
 11b4180a __fortranexit [+000c]
 11c3c676 DEBUGEXIT# [+0016]
 11c3fcc0 STOP# [+0066]
 CEXIT -  in file cexit.for at line 53 [+055b]
 main -  in file cmain.for at line 175 [+1fd9]
 006931c6 SALFStart [+06ff]

eax=11595840   ebx=00000026   ecx=115ebea8
edx=00000000   esi=113af55c   edi=00000000
ebp=113af488   esp=113af460   IOPL=2
ds=002b   es=002b   fs=0053
gs=002b   cs=0023   ss=002b
flgs=00010202 [NC OP NZ SN DN NV]

 11b47642  push     [ecx+0x4] 
 11b47645  call     11c77b10 
 11b4764a  lea      esp,[ebp-0xc] 



Runtime error from program:c:\program files (x86)\cmaster\c-master.exe
Access Violation
The instruction at address 11b27642 attempted to read from location 115cbeac

 11b27500 __winexit [+0142]
 11b21702 do_atexits(void) [+0018]
 11b2180a __fortranexit [+000c]
 11c1c676 DEBUGEXIT# [+0016]
 11c1fcc0 STOP# [+0066]
 CEXIT -  in file cexit.for at line 53 [+055b]
 main -  in file cmain.for at line 176 [+1f57]
 0068f186 SALFStart [+06ff]

eax=11575840   ebx=00000026   ecx=115cbea8
edx=00000000   esi=1139f564   edi=00000000
ebp=1139f490   esp=1139f468   IOPL=2
ds=002b   es=002b   fs=0053
gs=002b   cs=0023   ss=002b
flgs=00010202 [NC OP NZ SN DN NV]

 11b27642  push     [ecx+0x4] 
 11b27645  call     11c57b10 
 11b2764a  lea      esp,[ebp-0xc] 

I do not have a copy of the linker MAP file. Would this be something that could help in identifying the actual issue?

Thanks.

26 Jul 2017 10:18 #19895

The user is running Windows 7, 16 gb of main memory. Application takes about 140 MB when it is running (measured under Windows 10).

27 Jul 2017 11:57 #19896

Bill,

The fact that you compile with /SAVE probably means that your crash reason is different from the one I experienced, which was that the return path from various Clearwin+ WINIO@s had disappeared somewhere along the shutdown sequence. The answer was explicit SAVEs in every routine that split WINIO@s across them. I don't always remember to have a command line /SAVE, so maybe you have a routine that wasn't compiled that way.

In new code, I put the return variable in a COMMON block, because I basically don't like SAVE - a fortran traditionalist never expected anything outside COMMON to be SAVEd, and that is always my implicit assumption.

Despite how irritating FTN95 error screens are, the process does not damage Windows or a future run of the program in question.

Eddie

27 Jul 2017 12:16 #19897

The probable cause for this failure has been identified and fixed for the next release.

27 Jul 2017 7:41 #19899

Thanks for the info, Paul! Looking forward to it.

27 Jul 2017 10:36 #19900

Eddie, thanks for your comments.

The code was originally written for FTN 66, and the contents of local variables always assumed (and were) saved between calls. I actually would have preferred something like 'C' ('static' declarations) when the code was first written, but there you have it.

Rather than go through all the code to find which variables are to be SAVEd or not, I use the compiler option. A cop-out? Perhaps, but that the way it is!

BTW, all the FTN is compiled with the exact same set of options, so I am assured that /SAVE is applied to every FTN routine. The 'C' and 'C++' routines are all compiled via SCC in /RELEASE mode.

And, yes, nothing appears to be 'harmed' when the fault is detected. Which is good.

Please login to reply.