- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page