Thanks for the quick answer Sergey. I changed heap arrays to 1024. Now, I'm running the code....The problem does not change, but the place of it:

Unhandled exception at 0x000007fef5e3fe67 in 3d.exe: 0xC0000005: Access violation writing location 0x0000000000120ff8.

Physical Memory is 4GB and the virtual memory is set to min and max value of 2048 and 6000 MB . The maximum array size is 7 to 5 but the recursive subroutines and the pointers increase them. To make it clear: An 4x3 array with one-level high 1D array (which is pointed by 4x3 array) inside a recursive subroutine which calls 172 times itself and in the 173rd call the code breaks. The array elements are float, in Fortran literature real*8.

Hi Jim,

I apply your suggestion in my code, but it is hard to find the problem. When I insert the "call FOO" statements in my code, the program gives the same error with another location:

Unhandled exception at 0x000007feff7ffaad in 3d.exe: 0xC0000005: Access violation writing location 0x00000000000a0fe8.

Actually, I give the 4x3 array as an example. I do not know the "exact" problematic array. There are 20+ different arrays in my code.

@ Sergey,

I use min 11GB max 22GB but the error stays the same. By the way, when I remove a "one line self-calling(recursive)" do-loop inside the problematic subroutine, the error disappears but ,as expected, my code gives wrong outputs.

Quote:

Steve Lionel (Intel) wrote:

Access violation is not usually related to size of memory used. If you run the program under the debugger, it should stop at the point of the error (sometimes you may need to look at earlier stack frames to see your code rather than library code). If you enable traceback, it will tell you where the error occurred. I suggest using Intel Inspector XE's memory analysis to see if it identifies allocatable memory usage errors.

Yes, I increase the virtual memory even more ( 21GB-42GB) but the stopping point is the same, (the error point) is the starting line of one of my recursive subroutine.

I don't know how to enable traceback, would you tell me how?...I did not hear before the functionality of Intel Inspector in this type of problems. I will try that. Thanks Steve !  

Quote:

Sergey Kostrov wrote:

>>...I increase the virtual memory even more ( 21GB-42GB) but the stopping point is the same, (the error point) is
>>the starting line of one of my recursive subroutine...

Could you provide some details on what the code does in the recursive subroutine?

The recursive subroutine is a 300 line subroutine which is constructed for a 3 dimensional grid generator, works as a cut-cell refiner. It calls itself at 8 different parts of it and also some of them are in a do loop. It also calls 10 different subroutines. 

Quote:

iliyapolak wrote:

>>>Unhandled exception at 0x000007fef5e3fe67 in 3d.exe: 0xC0000005: Access violation writing location 0x0000000000120ff8.>>>

This exception can be due to some wrong pointer passed in registers or some garbage loaded in register and dereferenced by the code.
!address 0x00000000000120ff8 should reveal the what is the memory content in this address.

I guess so, the thing is I cannot find the wrong pointer.Can you tell me or show me how can I change this adresses into location to find this uninitialized (garbage) reference ? ( as jim dempsey said before  0120ff8 == 1183736. but when I change the virtual memory limits, it changes too. Thanks.

Quote:

Steve Lionel (Intel) wrote:

You enable traceback by adding /traceback on the command line. It is the default when building a debug configuration.

Ok, Steve. /traceback is in the command line by default. I will try Inspector on Monday, then I will share the results.

Let me show the problem page and the outputs, maybe it can show you that I cannot see. I upload the screenshots of the error and the "call stack" outputs (as part1 and part2) after the break.

I forgot it. When I stop the debugger after this access violation error, the debug output gives:

'3d.exe': Loaded 'E:\3d\x64\Debug\3d.exe', Symbols loaded.
'3d.exe': Loaded 'C:\Windows\System32\ntdll.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\kernel32.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\KernelBase.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\imagehlp.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\msvcrt.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\advapi32.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\sechost.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\rpcrt4.dll', Cannot find or open the PDB file
First-chance exception at 0x0000000140617977 in 3d.exe: 0xC00000FD: Stack overflow.
'3d.exe': Loaded 'C:\Windows\System32\dbghelp.dll', Cannot find or open the PDB file
First-chance exception at 0x000007feff57faad in 3d.exe: 0xC0000005: Access violation writing location 0x0000000000040fa8.
Unhandled exception at 0x000007feff57faad in 3d.exe: 0xC0000005: Access violation writing location 0x0000000000040fa8.
First-chance exception at 0x000007feff57faad in 3d.exe: 0xC0000005: Access violation writing location 0x0000000000040fa8.
Unhandled exception at 0x000007feff57faad in 3d.exe: 0xC0000005: Access violation writing location 0x0000000000040fa8.
The program '[6524] 3d.exe: Native' has exited with code -1073741819 (0xc0000005).

Quote:

jimdempseyatthecove wrote:

>>First-chance exception at 0x0000000140617977 in 3d.exe: 0xC00000FD: Stack overflow.

I found a thread which is very similar to mine:

http://software.intel.com/en-us/forums/topic/282409

Quote:

Sergey Kostrov wrote:

>>>>>Please try to increase Stack Commit and Reserved values:

Stack Commit = 268435456
Stack Reserved = 268435456

Also, power of 2 values are recommended and instead of 200,000,000 use 268,435,456 ( 2^28 ).

Sergey,

I applied your stack size suggestions but the problem is the same:

Unhandled exception at 0x000000013fbb7977 in 3d.exe: 0xC0000005: Access violation writing location 0x000000000014f000.

The output is:

'3d.exe': Loaded 'C:\Windows\System32\ntdll.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\kernel32.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\KernelBase.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\imagehlp.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\msvcrt.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\advapi32.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\sechost.dll', Cannot find or open the PDB file
'3d.exe': Loaded 'C:\Windows\System32\rpcrt4.dll', Cannot find or open the PDB file
First-chance exception at 0x000000013fbb7977 in 3d.exe: 0xC0000005: Access violation writing location 0x000000000014f000.
Unhandled exception at 0x000000013fbb7977 in 3d.exe: 0xC0000005: Access violation writing location 0x000000000014f000.
The program '[6084] 3d.exe: Native' has exited with code -1073741819 (0xc0000005).

Quote:

app4619 wrote:

Not quite the same the first exception was stack overflow in the earlier dump now it is access violation.

Also, I see that when I run the program again, it stopped at the "malloc.c". But after I run the program agin without any change, it again stops at my recursive subroutine as it was in first time. I don't understand why it goes to malloc.c, it happened only one time.

Quote:

Sergey Kostrov wrote:

>>... I see that when I run the program again, it stopped at the "malloc.c"...

There are about ~200 code lines for 4 functions in malloc.c source file. So, where exactly the debugger stops ( a line number )? Also, please attach malloc.c because depending on a version of Visual Studio some differences are possible.

I wish I can turn back in time and see the line. It happened only "one" time, unrepeatedly. If it happens again, I will surely look at the line.

Quote:

Steve Lionel (Intel) wrote:

Use the stack frame dropdown to see where malloc was called from in your source (indirectly). It may be several frames up

I see that, but cannot reach malloc.c using stack frame. It is not there now, maybe it is because of different VM limits and stack sizes. I changed them several times.

Quote:

Sergey Kostrov wrote:

>>...The maximum array size is 7 to 5 but the recursive subroutines and the pointers increase them. To make it clear:
>>An 4x3 array with one-level high 1D array (which is pointed by 4x3 array) inside a recursive subroutine which calls 172 times
>>itself and in the 173rd call the code breaks. The array elements are float, in Fortran literature real*8...

Hi emreka82.

Let's try more resolute actions:

1. Set VM values as follows: Min = 24GB and Max = 32GB

2. Set values Stack Commit = 536870912 and Stack Reserved = 536870912, and Heap Commit = 536870912 and Heap Reserved = 536870912
Note: 536870912 = 2^29 / you could use even higher values, like 2^30

3. Verify that application is compiled for 64-bit in Release and Debug configurations

4. Comment All processing in your recursive subroutines and declare a global counter of recursive calls. So, as soon as it reaches 173 ( or so ), call a return in order to "unwind" all resursion calls

5. If it Did Not crash everything is fine with memory and simplefied Fortran codes. If it is Not increase Stack\Heap Commit & Stack\Heap Reserved values and look for bugs ( ask somebody to do a code review )

6. The goal is as follows: you need to create a simplified and very clean version of your processing ( Do Not worry about results yet! ) and when it Did Not crash start uncommenting codes line by line or by a couple of lines at a time with a verification that codes are working.

Does it make sense?

I applied first 3 actions. The thing is the same but at the end of the "call stack" window, "The maximum number of stack frames supported by Visual Studio has been exceeded" is written. Is it because of "out-of-memory" ? I will apply rest of your action suggestions and see what happens. Thanks.

Quote:

Sergey Kostrov wrote:

>>....4. Comment All processing in your recursive subroutines and declare a global counter of recursive calls. So, as soon as it reaches 173 ( or so ), call a return in order to "unwind" all resursion calls

5. If it Did Not crash everything is fine with memory and simplefied Fortran codes. If it is Not increase Stack\Heap Commit & Stack\Heap Reserved values and look for bugs ( ask somebody to do a code review )

6. The goal is as follows: you need to create a simplified and very clean version of your processing ( Do Not worry about results yet! ) and when it Did Not crash start uncommenting codes line by line or by a couple of lines at a time with a verification that codes are working.

Does it make sense?

I added print*, <a number> in the recursive subroutine. This time, it stopped in "write.c" . The stopping line (showns as "HERE IT STOPS" comment) is as follows:

/***
*write.c - write to a file handle
*
* Copyright (c) Microsoft Corporation. All rights reserved.
*
*Purpose:
* defines _write() - write to a file handle
*
*******************************************************************************/
#include <cruntime.h>
#include <oscalls.h>
#include <ctype.h>
#include <io.h>
#include <errno.h>
#include <msdos.h>
#include <mtdll.h>
#include <stdlib.h>
#include <string.h>
#include <internal.h>
#include <setlocal.h>
#include <locale.h>
#include <wchar.h>
#define BUF_SIZE 5*1024 /* size of LF translation buffer */
 /* default buffer is 4K, plus extra for LFs */
/***
*int _write(fh, buf, cnt) - write bytes to a file handle
*
*Purpose:
* Writes count bytes from the buffer to the handle specified.
* If the file was opened in text mode, each LF is translated to
* CR-LF. This does not affect the return value. In text
* mode ^Z indicates end of file.
*
* Multi-thread notes:
* (1) _write() - Locks/unlocks file handle
* _write_nolock() - Does NOT lock/unlock file handle
*
*Entry:
* int fh - file handle to write to
* char *buf - buffer to write from
* unsigned int cnt - number of bytes to write
*
*Exit:
* returns number of bytes actually written.
* This may be less than cnt, for example, if out of disk space.
* returns -1 (and set errno) if fails.
*
*Exceptions:
*
*******************************************************************************/
/* define normal version that locks/unlocks, validates fh */
int __cdecl _write (
 int fh,
 const void *buf,
 unsigned cnt
 )
{
 int r; /* return value */
 /* validate handle */
 _CHECK_FH_CLEAR_OSSERR_RETURN( fh, EBADF, -1 );
 _VALIDATE_CLEAR_OSSERR_RETURN((fh >= 0 && (unsigned)fh < (unsigned)_nhandle), EBADF, -1);
 _VALIDATE_CLEAR_OSSERR_RETURN((_osfile(fh) & FOPEN), EBADF, -1);
_lock_fh(fh); /* lock file */
__try {
 if ( _osfile(fh) & FOPEN )
 r = _write_nolock(fh, buf, cnt); /* write bytes */
 else {
 errno = EBADF;
 _doserrno = 0; /* not o.s. error */
 r = -1;
 _ASSERTE(("Invalid file descriptor. File possibly closed by a different thread",0));
 }
 }
 __finally {
 _unlock_fh(fh); /* unlock file */
 }
return r;
}
/* now define version that doesn't lock/unlock, validate fh */
int __cdecl _write_nolock (
 int fh,
 const void *buf,
 unsigned cnt
 )
{ ////HERE IT STOPS
 int lfcount; /* count of line feeds */
 int charcount; /* count of chars written so far */
 int written; /* count of chars written on this write */

After that, I follow the stack frame. The second line is 74 of write.c, other "call stack locations" are:

3d.exe!for__write_output() + 0x58c bytes

3d.exe!for__put_sf() + 0x129c bytes

3d.exe!for__write_seq_lis_xmit()+ 0x2fbb bytes

3d.exe!for__write_seq_lis() + 0x988 bytes

Then it continues as usual, name of my recursive subroutine and its connected subroutines.

By the  way, as I add these "print*, <a number>" comments, the breaking point changes. So, I am sure that it runs out of memory.

Quote:

iliyapolak wrote:

@emreka82

Why do not you try to use windbg and application verifier in order to automate the error finding task.

I will give a try, it is on my list. Before installing these kind of  programs, I applied the effects of change in Visual Studio, Virtual Memory etc. Once I am done with these changes, I will install both windbg and application verifier. Thanks iliya.

Quote:

Sergey Kostrov wrote:

>>I applied first 3 actions. The thing is the same but at the end of the "call stack" window, "The maximum number of stack
>>frames supported by Visual Studio has been exceeded" is written

I'll check it for a 64-bit application.

Emreka82, Please try to try to follow steps 4, 5 and 6. As I've already mentioned you need to continue with a simplified and clean version of your processing.

In Visual Studio check Advanced properties of the Linker and your Target Machine needs to be MachineX64 (/MACHINE:X64), that is for a 64-bit Windows platform.

I cannot change the target machine. It has "MachineX86 (/MACHINE:IX86)" or "not Set" selections. I have 64bit Windows operating system. Why can't it change ??

Quote:

Sergey Kostrov wrote:

>>...I cannot change the target machine. It has "MachineX86 (/MACHINE:IX86)" or "not Set" selections. I have 64bit Windows operating
>>system...

It looks like a Root Cause of your problems because MachineX86 (/MACHINE:IX86) is a setting for 32-bit platforms and 32-bit applications can not allocate more then 2GB of memory.

>>...Why can't it change?..

Please ptovide exact details for a Visual Studio you use.

I use VS 2010 version 10.0.40219.1 SP1Rel

Quote:

Sergey Kostrov wrote:

Emreka82,

Could you create and attach a simple Fortran project for a review? It is really Not clear why you could not change the Target Machine. Thanks in advance.

Please take into account that with a 64-bit application maximum amount of memory a 64-bit application can allocate is more than 1TB ( of course a system must have it installed ). So, there should not be any limitations for Stack/Heap Commit and Stack/Heap Reserved values if the Target Platform is 64-bit.

Yes, I open a simple Fahr_to-Celc project implied from Fortran90 textbook and under linker advanced options multiple machine types (MachineX64, SH4, X86 etc)

Quote:

Sergey Kostrov wrote:

>>Yes, I open a simple Fahr_to-Celc project implied from Fortran90 textbook and under linker advanced options
>>multiple machine types (MachineX64, SH4, X86 etc)

Did you remove Read Only attribute for project files after you've copied the project to a hard drive?

I don't remove but all of the f90 files and other project files are NOT read only as default. By the way, all the files and the program are in D harddisk part not in C harddisk part. Does it make a difference ?

Quote:

Sergey Kostrov wrote:

>>Yes, I open a simple Fahr_to-Celc project implied from Fortran90 textbook and under linker advanced options
>>multiple machine types (MachineX64, SH4, X86 etc)

Did you remove Read Only attribute for project files after you've copied the project to a hard drive?

I think I found the problem, If you agree then I should reinstall the program. The program that I use is x86. The destination to VS developer is "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe"

Under x64 part of my program files ("C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\") destination there are only vsdiag_regwcf.exe file with PrivateAssemblies and Xml folders...