0xC0000005 Access Violation Writing Location Error

0xC0000005 Access Violation Writing Location Error

Hi,

I am writing a code with large arrays. The code works fine for small matrices but when I go beyond a certain level, the following error pops out:

Unhandled exception at 0x77913560 in 3d.exe: 0xC0000005: Access violation writing location 0x0000000000050e14.

I am dynamically allocating memory with variables, then deallocating them. The code is very long, longer than 20,000 lines. I want to trace the problem. Before deciding to start this topic, I search the forum and other sources. The "Stack Size" problem has seemed reasonable. I changed reserve size to 200,000,000 and commit size 20,000,000. The problem stayed the same with small differences:

Unhandled exception at 0x77913560 in 3d.exe: 0xC0000005: Access violation writing location 0x00000000001e0e84.

As you can see the code given at the end of the error line is different, I want to know and trace the error. Any kind of help will be appreciated. Thanks !

Emre

94 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Please try to use -heap-arrays 1024 ( or 2048, 4096, etc ) Fortran compiler option.

Also, How much physical and virtual memory do you have on your system? How big are arrays and what are their data types?

Thanks in advance.

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.

>>...Physical Memory is 4GB and the virtual memory is set to min and max value of 2048 and 6000MB..

Try to set the following combinations of Min and Max Virtual Memory values:

[ Case 1 ]
Min = 6GB
Max = 12GB

[ Case 2 ]
Min = 8GB
Max = 16GB

[ Case 3 ]
Min = 12GB
Max = 24GB

etc

In overall you need to find a right set of values!

If your codes do not have any hidden problems ( processing with smaller arrays works ) then your recursive processing is bound to Physical Memory up to some level and after that it is bound to Virtual Memory ( performance of processing will be affected ).

There are No known to me limitations with Intel Fortran compiler and I recently allocated 128GB of memory for three 64Kx64K matricies in a test case.

Please take a look at:

Forum Topic: A possible bug in the compiler - Forrtl: severe (41): insufficient virtual memory
Web-link: software.intel.com/en-us/forums/topic/377056

I don't confirm a bug. A screenshot and test project attached.

My guess is you are writing to an uninitialized (garbage) reference or writing beyond or before an array. The location written to was  0x0000000000120ff8 which is deffinately not on your x64 stack. 0120ff8 == 1183736. Add code to assert anything about to be referenced is not below 1183744. (your code will have been in error well before this, but this should be a good assert condition)

recursive subrouting FOO(A)
real :: A(4,3)
CALL CHECKLOC(LOC(A))
...
CALL CHECKLOC(LOC(A(I,J))
X =A(I,J)
...

SUBROUTINE CHECKLOC(L)
INTEGER(8) :: L

IF(L  .le. 1183744) THEN
WRITE(*,*) "BUG - PLACE BREAK HERE"
ENDIF
END SUBROUTING CHECKLOC

jIm Dempsey

www.quickthreadprogramming.com

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.

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.

Steve - Intel Developer Support

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 !  

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

Steve - Intel Developer Support

>>...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?

>>>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.

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.

Fichiers joints: 

Fichier attachéTaille
Télécharger error.jpg229.62 Ko
Télécharger callstackpart1.jpg341.6 Ko
Télécharger callstackpart2.jpg433.95 Ko

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).

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

www.quickthreadprogramming.com

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

>>>Can you tell me or show me how can I change this adresses into location to find this uninitialized (garbage) reference ?>>>

You need to run your program under windbg and issue the !address command on the suspected address.I bet that you are trying to execute or to read from so called PAGE_NOACCESS memory.

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

Here is a statement from the 1st post:

>>>>...The "Stack Size" problem has seemed reasonable. I changed reserve size to 200,000,000 and commit size 20,000,000.

Let me provide you with some real numbers for Stack Commit and Reserved values used for a Merge Sorting algorithm ( recursive ) to sort very large data sets ( greater than 64MB on a 32-bit platform ):

...-lS:1073741824 -lSc:1073741824...

Stack Commit = 1073741824
Stack Reserved = 1073741824

Note: 1073741824 = 1GB

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 ).

Quote:

Sergey Kostrov wrote:
Please try to use -heap-arrays 1024 ( or 2048, 4096, etc ) Fortran compiler option.

I agree on using -heap-arrays, but don't bother with a number for the option - the number has no useful effect.

Steve - Intel Developer Support

>>...I agree on using -heap-arrays, but don't bother with a number for the option - the number has no useful effect.

Thank you, Steve for the note!

I've noticed that something is wrong because when I tried to use 2048 or 4096, etc I didn't see any difference for a Fortran test application I used.

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).

 

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

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.

It may be a problem running out of system resources or it may be some other system problem but first you need to identify the point at which your application where things *start* to go wrong. If it were me I would pick a point in the recursive code and set a conditional break in the VS debugger to break (for example) after every 100 hits. By stepping through you will learn the crash is somewhere between 2200 and 2300 hits for example. Run again stopping after 2200 hits on the break point and then step slower say every 5 hits. This way you will find the point in your code where it goes wrong and can step the program line by line. The proability is you exceed an array or at the start of a new level of recursion you run out of some resourse e.g. memory/stack.

>>... 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.

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

Showing us the error messages from the debugger's output pane is not useful. You need to see what your program is doing at the point of the error. That the error moves around when you make changes suggests to me you are corrupting data somewhere.  Inspector XE can help you find this (probably, not guaranteed.)

Steve - Intel Developer Support

>>...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?

>>>Can you tell me or show me how can I change this adresses into location to find ...>>>

You need to ru your program under debugger and for resolving heap allocation issues it is recommended to install Application Verifier.Next you need to track in disassembly window where this address  0x00000000000120ff8 is coming from.I suppose that this is some garbage left on the stack frame which is somehow loaded and dereferenced by your code.

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.

@emreka82

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

>>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.

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 ??

>>...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.

If you have VS2008 or earlier, you must specifically add the X64 components in the installation menu under C++, then apply service packs and re-install Intel64 compilers.

Quote:

emreka82 wrote:

Quote:

iliyapolakwrote:

@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.

Good decision.

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

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.

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)

>>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?

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...

>>...all the files and the program are in D harddisk part not in C harddisk part. Does it make a difference?

No, it should not. Please verify how much free space you have on the drive D.

>>...I think I found the problem, If you agree then I should reinstall the program. The program that I use is x86...

In that case Visual Studio installer ( for example Repair option ) should tell you exactly if 64-bit builts are supported in your current (!) environment.

Also, try to use MS Depends utility ( it is very simple ) to verify that your current executables are 32-bit. After 64-bit support in Visual Studio is installed Re-Build the sources and check the executable with MS Depends again and it should show small 64 numbers if the module is for a 64-bit platform.

Pages

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui