Help ! "FORRTL: SEVERE (157): PROGRAM EXCEPTION - ACCESS VIOLATION" ERROR

Help ! "FORRTL: SEVERE (157): PROGRAM EXCEPTION - ACCESS VIOLATION" ERROR

Hi,

I am getting this error "forrtl: severe (157): Program Exception - access violation" in my Fortran codes. If you build and run the code, you can see that I have positioned the line of the problem with the use of "call system('pause')" in line 767. Then, if you push any button, the program gives "the error". Any ideas based on the declarations and code posted in the attached file? Thanks.

Emre

20 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

pause is not a standard system command in Windows/Linux/Unix. pause is recognized within a batch file by the Windows command processor; it is a deleted Fortran statement, as well. Decide which you wish to use and read about the rules and interpretation of the verb.

Ok, I understand that, but "pause" is not my problem, I have used this statement only to stop the debugging on a specific line (line 767).

I see two errors the compiler complains about by default when building in Visual Studio. These would cause access violation errors:

U370808.f90(249): error #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source.   [PP]
U370808.f90(255): error #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source.   [PP]

The routines you're calling here, mg_forminit and mg_centercoord, which have pointer dummy arguments. The standard requires that an explicit interface be provided, but you didn't do that. This causes the arguments to be passed incorrectly.

If you are building from the command line, add /warn:interface to see that.

Steve - Intel Developer Support

Zitat:

Steve Lionel (Intel) schrieb:

I see two errors the compiler complains about by default when building in Visual Studio. These would cause access violation errors:

U370808.f90(249): error #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source.   [PP]
U370808.f90(255): error #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source.   [PP]

The routines you're calling here, mg_forminit and mg_centercoord, which have pointer dummy arguments. The standard requires that an explicit interface be provided, but you didn't do that. This causes the arguments to be passed incorrectly.

If you are building from the command line, add /warn:interface to see that.

Hi Steve,

These violation errors were n the "warning" part of the build results, which were:

------ Build started: Project: Source2, Configuration: Debug|Win32 ------

Compiling with Intel(R) Visual Fortran Compiler XE 12.1.1.258 [IA-32]...
Source2.f90
.......................................\Source2.f90(249): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [PP]
.......................................\Source2.f90(255): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [PP]
.......................................\Source2.f90(268): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [PP]
.......................................\Source2.f90(422): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [NEU]
.......................................\Source2.f90(752): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [NEU]
.......................................\Source2.f90(760): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [PP]
.......................................\Source2.f90(769): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [PP]
.......................................\Source2.f90(773): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [PP]
.......................................\Source2.f90(821): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [ROOT]
.......................................\Source2.f90(879): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [ROOT]
.......................................\Source2.f90(887): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [ROOT]
.......................................\Source2.f90(888): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [ROOT]
.......................................\Source2.f90(891): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [PP]
.......................................\Source2.f90(894): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [ROOT]
.......................................\Source2.f90(895): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [ROOT]
.......................................\Source2.f90(897): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [ROOT]
.......................................\Source2.f90(901): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [ROOT]
.......................................\Source2.f90(902): warning #8055: The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source. [ROOT]

Build log written to "file:/.......................................\Source2\Debug\BuildLog.htm"
Source2 - 0 error(s), 18 warning(s)

---------------------- Done ----------------------

When I add the explicit interfaces in the class_meshgen part of my code, the warnings disappear. I upload the original code and this revised code. But the problem stays the same. 

Anlagen: 

Why are you using Word to attach Fortran sources? Please attach the .f90 directly.

When I run this, it gets an error in one of the recursive calls to MG_SETNEIGHBOR. On this call, the pointer NEU is unallocated. It comes from a call in MG_SETCELLREFINE where the value comes from neu%ch(i)%pp (where i is 4). This suggests a logic error in the code - you'll have to debug it and trace where that value was supposed to be set.

Steve - Intel Developer Support

Hi Steve,

I couldn't attach as fortran code f90 using mozilla. It gave some error pop-ups. I will try chrome now (attached the revies version again).

I have understood the problem, that is why I placed the pause (in line 852) before the value  (i=4) called in MG_SETNEIGHBOR. The problem is that I cannot find the logical error, that is why I posted. I check the codes 2 times for any logic error and cannot find. The pointer neu turn to be unallocated, but I have no deallocation part for the neu pointer. I'll appreciate that if you can help me, thanks.

Anlagen: 

AnhangGröße
Herunterladen source2.f9028.55 KB

Suggestion - rather than call system("pause)", use call DebugBreak and add USE KERNEL32 to the routine where you call this.  It will break into the debugger if being run under the debugger.

At the point where you have the pause, when the problem occurs, it isn't neu that is the issue but rather neu%ch(4)%pp.

Given that this code is creating what looks like linked lists of pointers, it's hard for me to follow since I don't know what it is doing. I have a couple of debugging ideas I will try, but there's a limit to how much time I can spend on this.

Steve - Intel Developer Support

Steve,

Thanks for the advices, I will apply the DebugBreak.

Yes, the problem is the son of the pointer neu and yes, that is the linked list structure.

If you tell me the debugging ideas, I can also run them. Sorry for taking your time, I know you try to help everyone in the whole forum. So far, you show me the problems that I aware of. I know where the program stops and tells me there is an "access violation error" but I don't know specifically whether it is a allocation error or logical error (which I do not encountered) or anything else. Thanks.

Emre

I use call DebugBreak line, it is really much more useful than call system('pause'). While I'm using it, I can see the value of the pointer neu just before the access violation error and after the error occurs. Just before the access violation error, pointer neu and its branches turns into "undefined adress". After the error occurs,  pointer neu and its branches turns into "undefined/pointer array". Problem could be allocatilon/deallocation problem or related to wrong nullifying, but I cannot figure it out. 

By the way, I have read the article named as "Don't Touch Me There - What error 157 (Access Violation) is trying to tell you" by Steve Lionel in http://software.intel.com/en-us/forums/topic/275071#comment-1548436 I guess my problem fits in the "References to unallocated pointers" type of access violation.

I have made some progress on this - the rest will be up to you.

First, when the DebugBreak call breaks into the debugger, click on the Disassembly tab and then click Step Over (or press F10) twice. This will bring you back into the context of the routine that called DebugBreak so that you can see the local variables. Otherwise you'll see some things undefined.

To help track this down, I added an integer field "seq" to the cell derived type and added a module variable nextseq which was initialized to 0. Each time forminit was called, I added one to nextseq and stored the value in neu%seq. This allowed me to keep track of which cell values were being used. I couldn't use addresses as I'm on Windows 7 and it has "address space layout randomization".

Initially, I looked at the value of neu%seq when the access violation occurred, and it was 1528. But when I added a test:

if (neu%seq == 1528) before the loop, it didn't trigger. By adding a print of neu%seq before the loop I determined that neu%seq was 255 before the loop, but at the point of the fourth time through the loop, it had changed to 1528!

Stepping through the code showed me that on the third time through the loop, when:

call mg_setneighbors(i,neu%ch(i)%pp)

was called, neu was pointing to an entirely different cell on return. I then saw that it was this line in mg_setneighbors:

neu%parent%ng(4)%pp%ch(2)%pp%ng(2)%pp=>neu

that caused the change. This component had been pointing at neu 255 but was now pointing at neu 1528, and it was the argument to mg_cutcellrefine that was "neu" in that routine.

I have no idea if this is what you want, but you're effectively rearranging the tree of cells out from under mg_cutcellrefine. If you want to make sure that neu is staying the same through that call, you'll need a local pointer of type cell that gets a pointer to neu, and then reference the pointer copy, eliminating the reference to the dummy argument.

Good luck!

Steve - Intel Developer Support

@emreka82

As it was advised for "Access violation" error type the best option is to run your program under windbg or to set winddbg as post-mortem debugger which will be called upon occurence of some kind of exception.

Zitat:

Steve Lionel (Intel) schrieb:

Good luck!

@ Steve Lionel:

Thanks! After hours of debugging I figure out that at the end of the do loop, level of the pointer (neu) changes from 5 to 6 (it has to be 5) which means that it turns out to be unallocated pointer! I added a checkpoint after the" call mg_setneighbors" line to overcome this:

if(.not.associated(neu%ch(i)%pp)) then
neu=>neu%parent
end if

It worked! But it made me think and showed me that a do loop here is not functioning well, maybe I should use do while ? Now, I have bunch of modules to add. But, I made a big progress. Especially, I want to thank Steve Lionel for his great support.

Zitat:

iliyapolak schrieb:

@emreka82

As it was advised for "Access violation" error type the best option is to run your program under windbg or to set winddbg as post-mortem debugger which will be called upon occurence of some kind of exception.

@ iliyapolak

Thank you, but I don't need "windbg" tool for now. I will have it if I have this kind of error once again.

@emreka82

Ok it is up to you which debgger to use.I wanted to add that in case of complex software development and testing windbg is recommended debugger to be used.

I disagree about windbg - it doesn't understand Fortran.  The Visual Studio debugger is perfectly fine for debugging applications.  windbg is more useful if you are trying to understand errors in Windows itself.

Steve - Intel Developer Support

>>...I wanted to add that in case of complex software development and testing windbg is recommended debugger to be used...

Thank you for the recommendation.

However, You're recommending software developers who 99.99% of their time work on scientific projects and who use IDEs, like Visual Studio, to use some tools which are designed for really low level tasks, like driver software development.

Visual Studios have integrated debuggers and they allow to debug at source codes level. I agree that a comment about WinDbg is irrelevant.

Iliya, I think we should stop any discussion(s) related to applications of WinDbg on the Intel Fortran forum ( and all the rest as well ). It takes everybody's time and doesn't help at all to solve problems or issues with Intel software.

Thanks for understanding.

>>>However, You're recommending software developers who 99.99% of their time work on scientific projects and who use IDEs, like Visual Studio, to use some tools which are designed for really low level tasks, like driver software development>>>

Aa I tend to agree with you that for majority of programmers here on Intel Fortran forum windbg could be an overkill.But windbg was not designed for low level tasks and it is perfectly capable to debug user mode code at the deeper level than VS debugger which in turn is helpful only at software development and compilation stage.At the runtime when the software crashes VS debugger will not be helpful it does not have special metacommands and tailored to specific tasks extensions  and it cannot also debug interaction between OS and running program. 

>>>Visual Studios have integrated debuggers and they allow to debug at source codes level. I agree that a comment about WinDbg is irrelevant>>>

Yes it is perfectly suite for compile time , but not for the runtime problem.

>>>Iliya, I think we should stop any discussion(s) related to applications of WinDbg on the Intel Fortran forum ( and all the rest as well ). It takes everybody's time and doesn't help at all to solve problems or issues with Intel software>>>

Sergey you are talking against the usage of windbg , so how can you attempt to solve this problem with VS debugger only: http://software.intel.com/en-us/forums/topic/356336

Iliya, windbg is a great tool fof device drivers, as in the post you link to. It is not an appropriate tool for Fortran applications.

Steve - Intel Developer Support

Zitat:

Steve Lionel (Intel) schrieb:

Iliya, windbg is a great tool fof device drivers, as in the post you link to. It is not an appropriate tool for Fortran applications.

Ok Steve now I see the difference between those two debuggers when the troubleshooting of Fortran application development must be taken into account.

Melden Sie sich an, um einen Kommentar zu hinterlassen.