Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Debug Assertion Failed!

nowizle
Beginner
250 Views

I have found that a read(*,*) statement, which reads from a command window, causes a "debug assertion failed" prompt to show up. If I remove the read statement, the error goes away. I also have to remove another read statement as well. I do not experience other errors for read statements, which read directly from a file. I am using Intel Fortran in microsoft visual studio. Below is the snippet of code that causes the error. A write statement gives 3 options to the user and then the user types in either 0, 1, or 3. After the read executes, it prompts the error which is attached. Also, this error only occurs on a specific user's account. I have several other users who use the same code statements and no error occurs. Can something be wrong internally in another users account, because I am out of ideas. 


77 format(/,1x,'GA Run - 0; Single Pass - 1; Monte Carlo Run - 3 ')

write(*,77)
read(*,*)iruntype

0 Kudos
1 Solution
Steve_Lionel
Black Belt Retired Employee
220 Views

My guess is that the MSVC library is complaining about data corruption for dynamically allocated memory. The actual cause of this will be elsewhere in the program.

When I am diagnosing an error like this, I first build with all run-time checks enabled, as well as generated interface checking (this is the default for a debug build.) If the error remains, I then start disabling/removing pieces of code to see if I can identify a code section that seems responsible. It's a drawn-out process, but usually I can find the culprit. It won't be where the error actually gets reported.

View solution in original post

2 Replies
mecej4
Black Belt
230 Views

Note that the error occurs inside the Microsoft CRT.

Unless you can specify the versions of VS, VC and Intel Parallel Studio that you are using, and can provide a specific example code that displays the problem behavior, nothing can be done.

Check if the users who experience the error have incompatible versions of Visual C runtime libraries installed.

Steve_Lionel
Black Belt Retired Employee
221 Views

My guess is that the MSVC library is complaining about data corruption for dynamically allocated memory. The actual cause of this will be elsewhere in the program.

When I am diagnosing an error like this, I first build with all run-time checks enabled, as well as generated interface checking (this is the default for a debug build.) If the error remains, I then start disabling/removing pieces of code to see if I can identify a code section that seems responsible. It's a drawn-out process, but usually I can find the culprit. It won't be where the error actually gets reported.

Reply