0xC0000005 Access Violation Writing Location Error

[emreka82]

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

[emreka82]

iliyapolak wrote:

Can you post the source code of 3d!MG_CUTCELLREFINE between the line 11 and line 26?

The first 26 line:

 [fortran]

recursive subroutine mg_cutcellrefine(neu,cs)

use class_meshgen

type(cell), pointer :: neu
integer :: cs, i, fng, sng, crfch, crsch, ccr1, ccr2, edgeno, tng, ngcr

if(neu%compcell==0) then
do i=1,8
call mg_cutcellrefine(neu%ch(i)%pp,cs)
end do
else
if(neu%iref==1 .or. neu%inref==1) then

!print*, 2

do i=1,6
!print*, 3
if(associated(neu%ng(i)%pp)) then
!print*, 4
if(neu%ng(i)%pp%level < neu%level) then
!print*, 5
neu%ng(i)%pp%iref = 1
call mg_cutcellrefine(neu%ng(i)%pp,cs)
!print*, 6
end if
end if
end do

[/fortran]

[jimdempseyatthecove]

Your program has an infinite recursion should you enter mg_cutcellrefine(new,cs) with new%compcell==0 and withy new%ch(i)%pp pointing to self.

Or in the false branch of the if(new%compcell==0) if new%level == -0 (0x80000000) and if the %pp's are goofed up.

Add

integer, save :: iRecurse = 0
iRecurse = iRecurse + 1
if(iRecurse .gt. 100) then ! use reasonable max larger than realistic recursion
write(*,*) "BUG, put break point on this WRITE"
endif
...
! at (all) returns
iRecurse = iRecurse - 1
return
end subroutine mb_cutcellrefine

Jim Dempsey

[emreka82]

jimdempseyatthecove wrote:

Your program has an infinite recursion should you enter mg_cutcellrefine(new,cs) with new%compcell==0 and withy new%ch(i)%pp pointing to self.

Hi Jim,

I know that at some point there is infinite recursion but my "neu%ch(i)%pp" pointer is in do loop and it turns 8 times only. How is that turns into an infinite recursion? My cell points are not all neu%compcell==0. So, there has to be some break out of this do loop.

jimdempseyatthecove wrote:

OR in the false branch of the if(new%compcell==0) if new%level == -0 (0x80000000) and if the %pp's are goofed up.

Sorry, but I cannot understand your comment here.

jimdempseyatthecove wrote:

Add

integer, save :: iRecurse = 0
iRecurse = iRecurse + 1
if(iRecurse .gt. 100) then ! use reasonable max larger than realistic recursion
write(*,*) "BUG, put break point on this WRITE"
endif
...
! at (all) returns
iRecurse = iRecurse - 1
return
end subroutine mg_cutcellrefine

I will add this lines in my code and see what happens. Thanks Jim, I will share my outputs.

Emre

[Bernard]

@emreka82

As I suggested and Jim your program has infinite recursion.I think that for now there is no need to continue debugging session.Please add those lines of code as suggested by Jim and post the result.

[Bernard]

>>>I try to apply your suggestions, cannot see ESP EIP or EBP in the code...Also as you can see, it gives a range error. I think that I have a mistake here.>>> There is no need to dump raw stack data , because it is obvious that your code has infinite recursion.If you would like to isolate the starting point in your code when the recursion started itwas recommended to use (in your case gp 64-bit) registers rsp and rip to display the range of the stack where probably the stack overflow started.Secondly such a dump is need when you have for example a large buffer overflow.

[emreka82]

iliyapolak wrote:

>>>I try to apply your suggestions, cannot see ESP EIP or EBP in the code...Also as you can see, it gives a range error. I think that I have a mistake here.>>>

There is no need to dump raw stack data , because it is obvious that your code has infinite recursion.If you would like to isolate the starting point in your code when the recursion started itwas recommended to use (in your case gp 64-bit) registers rsp and rip to display the range of the stack where probably the stack overflow started.Secondly such a dump is need when you have for example a large buffer overflow.

Thanks iliya and Jim, I think I found the starting point of the infinite recursion, it is on the line 22. In the code, a branch of the 6 neighbors (namely neighbor 5) of a cell is taken mistakenly as the 7th child of this neighbor. I don't know why, but will find it and post it here soon (I hope). I will try rsp and rip to find the problematic lines. Thanks for the help and suggestions.

[Bernard]

>>>Thanks iliya>>> You are welcome:) At this point I would like to recommend you to spend more time on learning how to debug your programs.It could be helpful in such a case like yours.

[SergeyKostrov]

>>...How is that turns into an infinite recursion? My cell points are not all neu%compcell==0. So, there has to be some break >>out of this do loop. My comment is related to a proper design and implementation of recursive functions. So, a recursive processing should always stop at some point and it could be called as a Simple Case. In pseudo-codes it looks like: ... FunctionA() Begin If ( Is this a Simple Case? ) __Yes_Solve_it__ Then __No_Redefine_the_Problem_and_Solve_It__( that is, call FunctionA again ) End ... For example, in case of a Merge Sorting algorithm recursive calls should stop when input data set has only 2 elements. Some time ago I did a set of tests and here are results: ... // Evaluation of Max Number of Recursive calls for different C++ compilers and platforms // // Note: These numbers could be different in your environment! // // Windows XP with MSC - DEBUG= 4774 / RELEASE= 86172 // Windows XP with MinGW - DEBUG=130172 / RELEASE=130172 // Pocket PC 2003 with MSC - DEBUG= 817 / RELEASE= 1000 // Smartphone 2003 with MSC - DEBUG= 817 / RELEASE= 1000 // Windows Mobile 5 with MSC - DEBUG= 817 / RELEASE= 1000 // Windows XP with BCC - DEBUG= 64597 / RELEASE= 64597 // Compact OS with TCC - DEBUG= 5898 / RELEASE= 5898 // // before the test application crashes ... Note: Default size of Stack was used in all tests / I didn't try to inclrease the size of Stack

[Bernard]

@Sergey What Operating System "Compact OS" is?

[Bernard]

Good example of properly designed recursive function is fibonacci numbers sequence where terminating conditions are tested against n == 0 and n == 1.