problems with run-time error checks

[martymike]

Options like /check:output_conversion seems like a good idea, but they don't work very well. They certainly crash the program, but that's hasn't proved to be very helpful. Mostly this is due to the fact that our primary application has a C++ GUI and therefore a C++ main. But we have an alternate way of running it with a Fortran main and it still doesn't work well. The program crashes with no information about where. I have seen this option work well with very small (one file) test programs, but on larger applications with many dll's is just gets completely lost. Are there any known reasons for this?

[Steve_Lionel]

Are you building with /traceback enabled? (Requires a Fortran main program.) What do you see? Please show a screenshot of the error message.

You can also run under the debugger and it should stop there when an error occurs. Also look at ESTABLISHQQ.

[martymike]

forrtl: error (63): output conversion error, unit -5, file Internal Formatted Write
Image              PC        Routine            Line        Source
libifcoremdd.dll   0FBDF9C3  Unknown               Unknown  Unknown
libifcoremdd.dll   0FC39E80  Unknown               Unknown  Unknown
psseng.dll         044FFC6C  Unknown               Unknown  Unknown
psseng.dll         044DCF86  Unknown               Unknown  Unknown

It is a very abbreviated traceback. Earlier today I found the statement that caused this and there ought be several more programs in the traceback. We are running with the debugger. To find these errors we have to set breakpoints and do a kind of binary search through the code (it got here - it didn't get here) with repeated executions to find the problem. When the error occurs, the line indicated by the debugger is random, and varies each execution. Even the traceback seems to have lost all idea of which programs were called from where.

We are building with /traceback enabled and with a Fortran main (we have two ways of starting the application, one with an MFC GUI written in C++, one with console interface written in Fortran).

In smaller applications (usually non-production programs) I've see these options behave just fine, so it's not the installation.

I looked at ESTABLISHQQ. I really only need for the debugger to tell me what line the error occurred at.

[Steve_Lionel]

Are both the main program and the DLL built as Debug configuration with traceback enabled?

[mecej4]

Your GUI application is rather complex, but a question that occurred to me may be pertinent: Is there an open console, to which the RTL can send traceback and other debugging output?

It is even possible that console output has been set to go to the null device (a.k.a. bit dump) so as to avoid distracting messages that are of no interest to the end user of the GUI application.

If I remember correctly, in Windows a process can have zero or one console, and multiple processes can output to one console.

[Steve_Lionel]

That martymike got the error output shows that the message and traceback is being displayed, but that his DLL may not have traceback info linked in. 

[martymike]

I almost wrote back that all the dll's had traceback on, but I checked and found one that did not. We have dozens of dlls in our build. I will check them all and try again.

Thank you. This was the kind of thing I was looking for.