|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
Andre
Joined: 19 Jan 2017 Posts: 14
|
Posted: Fri Sep 29, 2017 4:00 pm Post subject: Problems with code when internal subroutines are present |
|
|
I am observing a strange behavior using allocatable arrays in the presence of internal subroutines.
Consider the following program:
Code: |
program main
implicit none
integer*4 :: n = 5
real*8, allocatable, dimension(:,:) :: array
allocate(array(6,n))
end program
|
I compiled it with Code: | ftn95 /full_debug main.f90 /checkmate /link | and started it using the debugger
The program simply allocates an array(6,5), as shown by the debugger in the "Vars" window.
There, the exact output is: Code: | ARRAY = REAL*8 (6, 5) |
Adding /64 yields the same result.
So far, so good.
Now I simply add an empty internal subroutine (for completeness I will provide the whole code again):
Code: |
program main
implicit none
integer*4 :: n = 5
real*8, allocatable, dimension(:,:) :: array
allocate(array(6,n))
contains
subroutine subsub
end subroutine
end program
|
Using the same compiler options in 32 bit and examining with sdbg still yields the same output for the allocated array.
However, if I compile the second code with /64, suddenly the array bounds are complete nonsense. In my particular case, the output was
Code: | ARRAY = REAL*8 (0:21844080, 20752:20757) |
but I expect these values to vary (these bounds are definitely trash).
Interestingly, I was not able to produce an access violation in this small example and even the lbound/ubound and size intrinsic functions seem to work fine (despite the debugger output...). Admittedly, I did not try too hard either. By the way, checkmate does not complain at all (is it yet implemented in 64 bit??).
However I think that this might be some sort of compiler bug since one of our applications is crashing with spurious out-of-bounds errors/access violations when compiled with 64 bits and whenever internal subroutines are being used, while it did work fine in 32 bit. Actually these crashes along with this problem lead to the idea of examining the behavior of ALLOCATE in presence of internal subroutines.
Thanks for your help!
Have a nice weekend!
Last edited by Andre on Mon Oct 02, 2017 7:57 am; edited 1 time in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sat Sep 30, 2017 3:01 am Post subject: |
|
|
Your program does nothing, apart from the allocate.
Put a statement after the allocate, so you have a point after where sdbg can review what has happened, such as:
Code: | program main
implicit none
integer*4 :: n = 5
real*8, allocatable, dimension(:,:) :: array
allocate(array(6,n))
array = 1
contains
subroutine subsub
end subroutine
end program |
I would at least enhance the program to check the allocate and give subsub an address to work on.
Code: | program main
implicit none
integer*4 :: n = 5
integer*4 :: stat
real*8, allocatable, dimension(:,:) :: array
allocate(array(6,n),stat=stat)
write (*,*) 'allocate array : stat=',stat
array = 1
contains
subroutine subsub
write (*,*) 'in subsub'
return
end subroutine
end program |
If the error is SDBG64 can't handle a program that does nothing, I can cope with that. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sat Sep 30, 2017 3:26 am Post subject: |
|
|
Ok, I tried my revised code version with sdbg64 Ver 8.10 (12/2/2017) and it gave incorrect array dimensions, when using F7 to step through the program. I should install some of the updates since Feb 17 and see what happens.
If compiled with /debug /64 /link, the following program runs in sdbg64 reporting the correct dimensions with the write statements, but displays the incorrect dimensions in the "Variables:" window.
Code: | program main
implicit none
integer*4 :: n = 5
integer*4 :: stat
real*8, allocatable, dimension(:,:) :: array
allocate(array(6,n),stat=stat)
write (*,*) 'allocate array : stat=',stat, ' : size=',size(array)
write (*,*) 'lbound =',lbound(array)
write (*,*) 'ubound =',ubound(array)
array = 1
contains
subroutine subsub
write (*,*) 'in subsub'
return
end subroutine
end program |
I have updated sdbg64.exe to ver 8.10.11 (Sat Sep 16, 2017)and
1) reports correct dimensions with write statements
2) it still provides incorrect array dimensions in "Variables:" window
3) it now closes the screen when selecting EXIT (Ver 8.10.9 would not close) |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Sun Oct 01, 2017 4:08 pm Post subject: |
|
|
If you remove subsub it debugs okay.
I'll take a look at it. |
|
Back to top |
|
|
Andre
Joined: 19 Jan 2017 Posts: 14
|
Posted: Mon Oct 02, 2017 7:42 am Post subject: |
|
|
John, I wanted to give a minimal example and in fact, the code that I posted resulted from subsequently removing statements from a more complex code. I removed the bits that didn't seem to have any effect on the outcome. But apparently you have also observed that same strange behavior.
While the issue might be related to sdbg (I am using the latest version as provided in the link from this discussion), still I observe that code containing internal subroutines starts to show weird behavior in 64bit while it worked fine for 32bit (no matter if built for release or debug). Let me give you a better (and far more critical) example for this. (Unfortunately I am not allowed to post the code in question here and anyway it would be too large to post the full contents).
I think that the following snippet cleary shows the unusual behavior:
Code: |
SUBROUTINE rb_restpos_g (mmb, c_trans, c_rot, iter, ierror, crash)
!...
integer(singI) ,INTENT(in) :: mmb, c_trans, c_rot
integer(singI) ,INTENT(out) :: iter
integer(singI) ,INTENT(out) :: ierror
logical, INTENT(out) :: crash
! ...
write (*,*) 'Before call: loc(mmb)=', loc(mmb)
CALL estimate (1)
! ...
CONTAINS
! ...
SUBROUTINE estimate (state)
integer(singI), INTENT(in) :: state
write (*,*) 'Within call: loc(mmb)=', loc(mmb)
! ...
END SUBROUTINE estimate
END SUBROUTINE rb_restpos_g
|
When I compile in 32bit (the application is a ClearWin+ application), the output is:
Code: |
Before call: loc(mmb)= 18794008
Within call: loc(mmb)= 18794008
|
and the rest of the code works as expected. In 64 bit, the same code outputs:
Code: |
Before call: loc(mmb)= 16650768
Within call: loc(mmb)= 128849018994
|
and the code fails with an access violation if I try to read mmb. This clearly shouldn't happen, or am I overseeing something?
Last edited by Andre on Mon Oct 02, 2017 8:02 am; edited 1 time in total |
|
Back to top |
|
|
Andre
Joined: 19 Jan 2017 Posts: 14
|
Posted: Mon Oct 02, 2017 7:58 am Post subject: |
|
|
I changed the topic message to reflect that the problem is not only related to allocatable arrays. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|