Cannot reproduce customer's error

[chstoyer]

I am using the latest version of CVF 6.6.

I have a customer in France who is experiencing a fortl severe (157) Program Exception - access violation. The message gives subroutine and file names and line numbers. It is claiming to occur at the top of a subroutine, that is at the SUBROUTINE statement itself. She has had this occur on two different machines.

The error occurs when loading a data file and it only occurs for one of the possible data files, not for others. It does not occur if this data file is loaded after loading another data file.

I cannot get the error to occur when loading the same or other data files on my machine. I have tried 3 machines, one running Win 98, one XP home and one XP pro. I have run the release and debug versions. I have run the debug version in the debugger as well and looked at the variables in the area where the crash occurs on the customers machine and I cannot find anything wrong.

Suggestions as to how to track down the source of this error are welcome.

I would be happy to furnish anyadditional information which might be required.

Thanks in advance,

Charles.

[durisinm]

If the error occurs at the first line of the subroutine, then my guess is that there is something wrong with the number or type of the arguments. Have you tried running the debugger in the calling routine and verifying that it is passing what the called subroutine expects?

What operating system is your customer running?

Mike D.

[Steven_L_Intel1]

The way I'd approach this is to use the program counter (PC) information in the traceback, along with a link map and assembler listing of the routine to determine exactly which instruction is getting the error. You could also use "just in time debugging" on the user's system (if they have MSVC6 or CVF installed) to enter the debugger when the error occurs.

There may be stack or other data corruption going on which changes symptom depending on memory layout. Believe it or not, I have also heard from customers that a bad printer driver caused erratic behavior of their programs!

Here's a trick I sometimes employed. Ask the customer to boot their PC into Safe Mode and see if the problem still occurs. If not, then there may be some background program running that is corrupting data.

[chstoyer]

The program will not link if there is a difference in the number of arguments.

I have checked code and ran in the debugger, checking the arrays and their allocations and everything seems in order.

I cannot get the thing to crash on any of my 3 machines.

Charles

[chstoyer]

Thanks for the advice. I have asked her to try in safe mode.

I will send the newest release version and see if I can track down the instruction. I have never generated maps or assembler listings with CVF but I used to do this years ago on mainframes, so I know how to do it (I think!)

If she uses Just in Time Debugging, does she need source to do any good or what?

I can't get Just in Time Debugging to work on my current installation of CVF pro for some reason. I need to run in debug mode (G0=F5) if I want to get into the debugger.

Thanks,

Charles

[Steven_L_Intel1]

I think you have to enable JIT debugging in Developer Studio under Tools..Options. Note that this is a system-wide setting. You don't need the source, but you'll at least be able to see the instruction in error and examine registers and memory to see what is triggering the accvio.

[chstoyer]

I have solved the problem.

It had to do with an automatic array. The derived type component which specified the size of the automatic array was not initialized, and therefore was highly dependent on the state of the particular machine at the time. I added some code and that moved things around and it then crashed reliably on my machine in both Release and Debug versions. And in the debugger I could see the large negative number in SM%NPAR. So I initialized it to 1 and all is OK now.

Offending code line:

DIMENSION PTEMP(S%M%NPAR),PMTEMP(SM%M%NPAR)

S%M%NPAR was OK but SM%M%NPAR was never initialized and it was garbage, sometimes was legal, sometimes not.

Thanks for your help,

Charles