View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Tue Sep 14, 2010 12:52 pm Post subject: "Active DO-loop index altered" |
|
|
I get sometimes this hidden error and it takes a lot of scratching to find this specific index which is in violation. Is it possible to make it clearly named in SDBG showing exactly which index and in which subroutines are altered ?
Like today for example...In some circumstances some chain of subroutines with a lot of stuff inside alter something in other ones which call them. 5am at the morning and i am still not there... . The debugger stopped on "call temporary_yield@()" line an is silent like catched war partisan . That probably means that actual violation happened long ago and became exposed just when temporary_yield@ was called....such a damn nasty bug... This bug (and another which may change the color of the plotted curve) lives in this code for a long time....10 years probably...will try tomorrow, it annoys me too much lately. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Sep 16, 2010 9:26 am Post subject: |
|
|
Tried to make a small prototype which reproduces this bug but failed and also got even more questions. Failed because the way i suspected this error occurred does not work at all (see below). And the question is following: is this way of changing the main loop index legitimate?
Code: |
common i
do i=1,10
call subr
enddo
end
subroutine subr
common i
i=100
j=1000
k=10000
end
|
This code works with no complaints! I have nothing against of it, and even like it, but is this standard conforming? And now i am even more confused. How my specific error was generated by the compiler?
Last edited by DanRRight on Mon Sep 20, 2010 5:43 am; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Thu Sep 16, 2010 11:57 am Post subject: |
|
|
You need to compile this with /check to get a runtime failure. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri Sep 17, 2010 2:21 am Post subject: |
|
|
Dan,
I've had problems with this bug, as in one case it took some time (years) to find the source of the error, when the do index is in common.
I've since tried to remove this structure or at least ensure that do indexes are only "intent (in)" if used in a subroutine call.
A possible bug to be avoided.
John |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Fri Sep 17, 2010 5:32 am Post subject: |
|
|
You're right Paul i forgot /check so this example above is the right example to demonstrate what i think is missing in debugger
I am trying to say that the debugger does not tell explicitly that index i has been changed inside subroutine. Though which index is used in this simple is obvious, but in large code with the chain of spaghetti code and subroutines it is hard to find what and where anything was changed by index coincidence. Specifically because the fact that index will be changed inside some subroutine will be exposed to user much later the moment it was actually changed
So far my kazak attack fails.... i can not find any indexes violated in my own large code subroutine where code stopped coinciding to one in calling it program....Nor in other subroutines called before. The code aborted by the way not on exit from the subroutine like in example above, but on some intermediate sentence inside subroutine which has nothing incriminating in it.
I hope this can be programmed to show indexes explicitly in debugger and this difficult type error will be gone forever. |
|
Back to top |
|
|
|