help debug an access violation

rasa · ‎04-15-2008

In a relatively big program, I get the following error when a particular "print to output files" subroutine is called. I have resisted providing the source code here because it is too long.

This subroutine has intent(in) defined for all variables of the subroutine. No allocatables. All arrays are fixed size and dimension. There are some local variables insubroutine's scope.

In the main program that calls the subroutine, I set a breakpoint and verified that all variables are intact and there is no data corruption. The moment the control enters the subroutine, the following error appears (in the debugger popup) and the program crashes.

In a 64-bit machine:
Unhandled exception at 0x000000014014548d in sassiextract-ver5.exe: 0xC0000005: Access violation writing location 0x0000000000000018.

In a 32-bit machine:
I go through the "chkstk.atm" - I guess the stack blows up.
Unhandled exception at 0x00501717 in sassiextract-ver5.exe: 0xC0000005: Access violation writing location 0x00000010.

In the console window:
forrtl: severe (157): Program Exception - access violation
line no 11 in subroutine file -- where subroutine statement
line no 292 in main file -- where call statement appears

Compiler options: Intel Fortran Compiler 10.1.021
/nologo /Zi /Od /warn:declarations /warn:unused /warn:ignore_loc /warn:truncated_source /warn:interfaces /module:"x64Debug/" /object:"x64Debug/" /traceback /check:bounds /libs:static /threads /dbglibs /c

Any little help or suggestion will be much appreciated. I have hit a brick wall that is beyond my current understanding. Thanks.

TimP · ‎04-15-2008

According to previous advice posted on this forum about /warn:interface (check your spelling), you must also set /gen-interface for that option to take effect. It certainly reads like you need that checking.

rasa · ‎04-16-2008

I added the flag and even added the check for fortran 2003 standards. I got a lot of warnings. They were mostly concerning the use of "" in format statement.

Compiler Options:
/nologo /Zi /Od /gen-interfaces /stand:f03 /warn:all /module:"Debug/" /object:"Debug/" /traceback /check:bounds /libs:static /threads /dbglibs /c

Please note that the GUI sets the flag automatically as "/gen-interfaces" with an "s" at the end.

new error:
Unhandled exception at 0x0000000140144d5d in sassiextract-ver5.exe: 0xC0000005: Access violation writing location 0x0000000000000018.
Unhandled exception at 0x00500f57 in sassiextract-ver5.exe: 0xC0000005: Access violation writing location 0x00000010.

I am definitely missing something "BIG" here. The program just can't crash in a IO subroutine.

Steven_L_Intel1 · ‎04-16-2008

Have you run this under the debugger and see where it stops? The data address is a small integer suggesting maybe that you are passing something by value that should be by reference. Another possibility is that you are corrupting memory elsewhere in the application.

rasa · ‎04-16-2008

This is how the subroutine is defined.

subroutine print_xfer_fns(file_name_header, &
level_of_nodes, &
soil_case_header, &
control_th_header, &
number_of_nodes, &
node_array, &
frequency_step, &
num_freq_points, &
all_frequencies_array, &
num_computed_freq_points, &
computed_frequencies_array)

use ifport
use SEParams
use BroadSpec, only : DP
use XferFnsDef, only : xfer_fns, &
comp_xfer_fns, xfer_fns_max_vals, &
xfer_fns_max_vals_abscissa

implicit none

! Define the passed on variables
character (len = 80), intent(in) :: file_name_header
integer, intent(in) :: level_of_nodes
character (len = 80), intent(in) :: soil_case_header
character (len = 80), intent(in) :: control_th_header
integer, intent(in) :: number_of_nodes
integer, dimension(100), intent(in) :: node_array
real(DP), intent(in) :: frequency_step
integer, intent(in) :: num_freq_points
integer, dimension(4100), intent(in) :: all_frequencies_array
intege r, intent(in) :: num_computed_freq_points
integer, dimension(100), intent(in) :: computed_frequencies_array

The program and the values aregood in the main routine. The moment it enters the subroutine it crashes. Note all intent(in) 's in the subroutine. The other variables that are coming from the module are public (very large arrays).

I will explore whether I am corrupting data somewhere else. Any hints on what to look for (Its a vague question) ?

Could you please tell me why the debugger is stepping through "chkstk.atm" file while entering the subroutine ? It looks like assembly language for me. It could be something linked to the stack memory. Will it be causing the crash?

Steven_L_Intel1 · ‎04-16-2008

chkstk.asm is called at the start of the routine to see if there's enough stack available to allocate local temporaries. You should not see this unless you did a "step into" while already in the routine. It is not itself causing the crash, though if you're already out of stack space it might be that it gets an error trying to check! Does the access violation occur in chkstk.asm?

This is not the sort of problem that lends itself to general recomemndations. It takes good, old-fashioned debugging.

rasa · ‎04-16-2008

On a 32-bit machine it does step into "chkstk.atm".
In a 64-bit machine, the program does not step into "chkstk.atm". However, this is what happens in the call stack.

In the main program:
>sassiextract-ver5.exe!SASSIEXTRACT() Line 278Fortran

The above statement represents the call () statement in main program.

When I do a step into, I see the file containing subroutine and the exception is thrown immediately (same error message as the one described in earlier post). The exception is thrown in the following statement. There is an "Yellow" arrow.

sassiextract-ver5.exe!__intel_alloc_bpv() + 0x85 bytes

The next statement in stack has a green arrow. The program never reaches the following statement.
>sassiextract-ver5.exe!PRINT_XFER_FNS(CHARACTER(80) FILE_NAME_HEADER='n417 ', INTEGER(4) LEVEL_OF_NODES=0, CHARACTER(80) SOIL_CASE_HEADER='best-estimate ', CHARACTER(80) CONTROL_TH_HEADER='Hard ', INTEGER(4) NUMBER_OF_NODES=1, INTEGER(4) NUMBER_OF_NODES=1, INTEGER(4) NODE_ARRAY={...}, REAL(8) FREQUENCY_STEP=2.441406250000000E-002, INTEGER(4) NUM_FREQ_POINTS=4092, INTEGER(4) ALL_FREQUENCIES_ARRAY={...}, INTEGER(4) NUM_COMPUTED_FREQ_POINTS=75, INTEGER(4) COMPUTED_FREQUENCIES_ARRAY={...}, .tmp..T196__V$c2=, .tmp..T200__V$c5=, .tmp..T203__V$c7=) Line 11 + 0x55 bytesFortran

I think I should try to increase the stack memory size for the program. How do I do that? Is there a possibility that a stack error will occur in a machine with 16GB ram ? I use only 280MB of RAM so far for this executable.

Steven_L_Intel1 · ‎04-16-2008

The amount of RAM you have is not relevant. You can try changing the stack size in the linker property System > Stack Reserve.

If you get stuck, send the whole project to Intel Support and we'll take a look.

rasa · ‎04-16-2008

Thanks Steve and Tim. Its about time to learn my programming errorsfrom Intel engineers (Intel Support Issue no: 477928).

rasa · ‎04-19-2008

I was able to fix the problem. I am more or less convinced that this is a bug in the Intel 10.x compiler. An earlier version of this code used to work fine with 9.x compilers.

In my code, I have blocks of repeated code that basically do the same thing but for a different array index (read ugly).

Repeated programming block:

 if(xfer_fn_output_flags(1)) then
 open (w01, FILE=TRIM(xfer_fn_file_names(1)),STATUS='REPLACE')
 write(w01,'(A)') ' T R A N S F E R F U N C T I O N V A L U E S'
 write(w01,'(a)') ' X-DIRECTION AMPLITUDES DUE TO X-DIRECTION INPUT CONTROL MOTION'
 write(w01,2013) number_of_nodes, num_freq_points, num_computed_freq_points, frequency_step
 write(w01,'(A,//)') ' M A X I M U M V A L U E S (X X)'
 write(w01,'(16X,<(number_of_nodes)>A16)') (header_strings(ii),ii = 2,(number_of_nodes+1))
 write(w01,'(16X,F16.4)') (xfer_fns_max_vals(jj,1),jj=1,number_of_nodes)
 write(w01,'(//,A,//)') ' T R A N S F E R F U N C T I O N S (X X)'
 ! write the titles for the nodes
 write(w01,'(<((2*number_of_nodes)+2)>A16)') (header_strings(ii),ii = 1,((2*number_of_nodes)+2))
 
 do ii = 1,num_freq_points
 if(ii .LE. num_computed_freq_points) then
 ! print everything
 write(w01,'(F16.4,F16.4,F16.4,F16.4)') all_frequencies_array_hz(ii), &
 (xfer_fns(jj,1,ii),jj=1,number_of_nodes), &
 computed_frequencies_array_hz(ii), &
 (comp_xfer_fns(jj,1,ii),jj=1,number_of_nodes)
 else 
 ! do not print the computed frequecy values
 write(w01,'(F16.4,F16.4)') all_frequencies_array_hz(ii), &
 (xfer_fns(jj,1,ii),jj=1,number_of_nodes)
 end if
 end do !ii
 close(w01)
 endif ! print XX results flag

There are nine blocks in the subroutine and basically each block is the same except for array index. Replace 1 with 2, 3, to 9.
i.e. variable xfer_fn_output_flags(1) by (2), (3),  (9); xfer_fns(jj,1,ii) by (jj,2,ii) and so on.

The code does not run with more than three blocks (with indices from 1 to 9) 
in my machine. It does not matter if the blocks are 1,2,3 or 3,5,7 or some other three.

Now I managed to do all these repetitive 9 blocks with one do loop iterating the indices from 1 to 9. There is no more access violation error problem and the program runs fine.

Any idea why this is happening?

Steven_L_Intel1 · ‎04-19-2008

I spent some time with this program yesterday. It is failing in a routine __intel_alloc_bpv@4 which is called at the beginning of routines that contain Variable Format Expressions, which this routine does. It is not failing in the stack check routine.

As best as I can tell, something has corrupted the data structures used by the heap allocation manager. I have not yet been able to find out what. I will look at the code you changed and see if I can spot a problem.