Sporadic crashes

I've been running some stress tests of my code, and things that were working fine are failing sporadically. The worst problem is with GET_FILTERED_FILE@. Manually running the exact sequence of steps might, or might not, result in a crash. Every attempt to get this to repeat in a small test case in the past has failed. But here's the error anyway:

Runtime error from program:f:\cmasterf95\checkmate\win32\c-master.exe Access Violation The instruction at address 106751f1 attempted to read from location 0f411c18 106751d2 GetFileNameAW(enumÄlogical,<ptr>structÄtagOFNA)#70 [+001f] 106add0d get_file_name(<ptr>void,<ptr>char,<ptr>char,int,<ptr>char,<ptr>char,enumÄlogica [+032e] 106accff f77_get_filtered_file [+01a6] CEXPORT_CSV_NEW - in file cexport_csv_new.for at line 821 [+aaca] XMMANT - in file cmaint.for at line 89 [+0b4d] main - in file cmain.for at line 159 [+1f2e]

eax=0f4119a0 ebx=0dc0dc78 ecx=0f0c7acc edx=00000000 esi=0f0c7d4a edi=00000012 ebp=0f0c78b0 esp=0f0c786c IOPL=2 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00210206 [NC EP NZ SN DN NV]

106751f1 testb [eax+0x278],0x20 106751f8 je 10675229 106751fe push [eax+0x50]

The oddest thing, though, is terminating the program I am now (sporadically) getting this error:

106add0d get_file_name(<ptr>void,<ptr>char,<ptr>char,int,<ptr>char,<ptr>char,enumÄlogica [+032e] 106accff f77_get_filtered_file [+01a6] CEXPORT_CSV_NEW - in file cexport_csv_new.for at line 821 [+aaca] XMMANT - in file cmaint.for at line 89 [+0b4d] main - in file cmain.for at line 159 [+1f2e]

eax=0f4119a0 ebx=0dc0dc78 ecx=0f0c7acc edx=00000000 esi=0f0c7d4a edi=00000012 ebp=0f0c78b0 esp=0f0c786c IOPL=2 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00210206 [NC EP NZ SN DN NV]

106751f1 testb [eax+0x278],0x20 106751f8 je 10675229 106751fe push [eax+0x50]

The oddest thing, though, is terminating the program I am now (sporadically) getting this error:

106add0d get_file_name(<ptr>void,<ptr>char,<ptr>char,int,<ptr>char,<ptr>char,enumÄlogica [+032e] 106accff f77_get_filtered_file [+01a6] CEXPORT_CSV_NEW - in file cexport_csv_new.for at line 821 [+aaca] XMMANT - in file cmaint.for at line 89 [+0b4d] main - in file cmain.for at line 159 [+1f2e]

eax=0f4119a0 ebx=0dc0dc78 ecx=0f0c7acc edx=00000000 esi=0f0c7d4a edi=00000012 ebp=0f0c78b0 esp=0f0c786c IOPL=2 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00210206 [NC EP NZ SN DN NV]

106751f1 testb [eax+0x278],0x20 106751f8 je 10675229 106751fe push [eax+0x50]

The oddest thing, though, is terminating the program I am now (sporadically) getting this error:

106add0d get_file_name(<ptr>void,<ptr>char,<ptr>char,int,<ptr>char,<ptr>char,enumÄlogica [+032e] 106accff f77_get_filtered_file [+01a6] CEXPORT_CSV_NEW - in file cexport_csv_new.for at line 821 [+aaca] XMMANT - in file cmaint.for at line 89 [+0b4d] main - in file cmain.for at line 159 [+1f2e]

eax=0f4119a0 ebx=0dc0dc78 ecx=0f0c7acc edx=00000000 esi=0f0c7d4a edi=00000012 ebp=0f0c78b0 esp=0f0c786c IOPL=2 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00210206 [NC EP NZ SN DN NV]

106751f1 testb [eax+0x278],0x20 106751f8 je 10675229 106751fe push [eax+0x50]

The oddest thing, though, is terminating the program I am now (sporadically) getting this error: [quote:a0e86c0d53] Runtime error from program:f:\cmasterf95\checkmate\win32\c-master.exe Access Violation The instruction at address 10637642 attempted to read from location 0f2d8fb4 10637500 __winexit [+0142] 10631702 do_atexits(void) [+0018] 1063180a __fortranexit [+000c] 1072c676 DEBUGEXIT# [+0016] 1072fcc0 STOP# [+0066] CEXIT - in file cexit.for at line 44 [+0219] XMMANT - in file cmaint.for at line 162 [+183b] main - in file cmain.for at line 159 [+1f2e]

eax=0f2a6368 ebx=09825e2a ecx=0f2d8fb0 edx=00000000 esi=0f0dc48c edi=00000000 ebp=0f0dc3b8 esp=0f0dc390 IOPL=3 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00010202 [NC OP NZ SN DN NV]

10637642 push [ecx+0x4] 10637645 call 10767b10 1063764a lea esp,[ebp-0xc]

Sorry I can't give you anything better than that. Will continue to try to isolate the issue. One piece of additional info. I have recently added a block of 'C' code for coordinate transformation (out of PROJ4). When compiled using SCC, I get a LOT of errors in the link stating that nearly every compiled module has the following kind of size mismatch: [quote:a0e86c0d53] WARNING - Class 'pj_opaque' was previously defined in module f:\cmasterf95\CHECKMATE\WIN32_WIDE\PROJ4LIB.LIB as size 16 but is now defined as size 280 (f:\cmasterf95\CHECKMATE\WIN32_WIDE\PROJ4LIB.LIB) WARNING - Class 'PJconsts' was previously defined in module f:\cmasterf95\CHECKMATE\WIN32_WIDE\PROJ4LIB.LIB as size 416 but is now defined as size 424 (f:\cmasterf95\CHECKMATE\WIN32_WIDE\PROJ4LIB.LIB) WARNING - Class 'pj_opaque' is the same size but defined differently than previously in module f:\cmasterf95\CHECKMATE\WIN32_WIDE\PROJ4LIB.LIB (f:\cmasterf95\CHECKMATE\WIN32_WIDE\PROJ4LIB.LIB)

I know the reason why most of these warnings occur: the structure pj_opaque (for instance) is defined in each compiled section as if it were global, but with the same name, kind of like a COMMON block that is re-defined and resized in different modules. I was thinking that this might have some effect on the executable, but am unsure the why/how these structures might interfere with each other, and if they do, how to stop them from doing so and still use SCC.

Item 382 in the document cwplus.enh describes changes in the implementation of GET_FILTERED_FILE@ which may be relevant.

I don't understand the warnings but this kind of warning could be important and should be removed by providing unique names for structures etc. that differ.

There seems to be no easy solution to your problem Bill, but if you are creating lots of files is a partial solution perhaps to name them yourself, rather than getting the user to? In essence, this is having a 'project' where all the files have the same names but different extensions, and in these days of very long filenames, a root part and a variety part, as in: (respectively)

Texas.Map Texas.XYZ

or

Texas_Eocene.Oil Texas_Miocene.Oil

The root in both cases being 'Texas'.

For scratch files, I see that FTN77 had a routine TEMP_FILE@ which would return a unique name in the current directory, and even better, USE_VIRTUAL_SCRATCH_FILES@ which would force files of (STATUS=’SCRATCH’) to stay in the disk cache and thus read back at RAM speed. So many of the FTN77 utilities made it to FTN95, and I wonder if these did?

Given how difficult Paul found it to deal with your problem the previous time it came up makes me suspect that it is the result of some deep-rooted assumptions in Windows itself about the way Windows applications should work.

Eddie

Paul, I've added the option described, and will let you know. Since the crash is sporadic but frequent, I'll keep running my own regression testing and report back later. As far as the C structures causing these messages and possibly causing problems, I had attempted to make changes to the code to eliminate these. Unfortunately, none of my 'fixes' were entirely successful. Since it is someone else's code, it's a lot more difficult!

Eddie, thanks for your suggestions. I do already use the TEMP_FILE@ function when creating work-in-progress files. Your suggestion has merit, but it's not what the user is expecting! I need to continue to use the function, and I'll continue to test to make sure it won't cause a problem for my users!

I'll grant you that I don't often have easily solved problems. By the time I post here, I've already spent days, if not weeks, looking for root cause. Often times, I've rooted out the issue, and it is my error. I fully accept that, then move on. If it is a workaround (i.e. it should have worked, but didn't, and here's what I did), I post that here, looking for someone such as yourself to point out my incorrect assumptions. That feedback is much appreciated, and certainly helps me later.

When I have something like this problem, in code that has worked for months, flawlessly, for both myself and my users, then get these results, I dig in, probe the code, then report. Because 'it shouldn't happen'.

If the problem is caused by a deep-rooted assumption about the way Windows works, I can't be the only one who experiences this!

I came up with a solution to the multiple instances in the 'C' routines of the same, named structures (and enumerated types) defined differently in multiple files.

I used SCC's capability to /DEFINE a macro on the command line. Using the command line arguments, I set a /DEFINE for each one of the named structures.

For the pj_opaque structure, this became

/DEFINE pj_opaque=pj_opaquexxx

where xxx is different for each file being compiled (1 through 170). All of my test cases showed no discernible effect.

If these might have been a contributor to the other issues, time will tell.