|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Tue Jun 04, 2019 3:16 pm Post subject: Incorrect first line of subroutines in debugger under /64 |
|
|
If you want to go to some specific subroutine in debugger, you just Ctrl+F the name of subroutine and you are there. In 32 bit this works fine but the 64bit fails to step in right first line.
To reproduce this annoying bug follow these steps: compile PROG with /debug /64, start program in debugger SDBG PROG.EXE, put the name PROCESSOR_ID in CTRL+F window and hit ENTER. The SDBG will step on wrong line (second or third instead of first) Here is the demo Code: | use mswin
Integer, external :: processor_id
jj= processor_id ()
end
!--------------------------------
integer function processor_id ()
!
! With thanks to John Horspool 2008-04-02
!
use mswin
CHARACTER*400 LDATA
CHARACTER*80 getenv@, IDENTIFIER
CHARACTER*80 CPU_stepping, CPU_description
integer n_processorsTotalGetEnv
character*256 ResultsToSave(10)
integer iVersionOfTesrResFile
LSTR=400
k = REGOPENKEYEX(HKEY_LOCAL_MACHINE, &
'HARDWARE\DESCRIPTION\System\CentralProcessor\0', 0,KEY_READ,MyKey)
CPU_description= ' N/A '
if (MyKey.GT.0) then
k = REGQUERYVALUEEX(MyKey,'ProcessorNameString', &
CORE4(0),CORE4(0),LDATA,LSTR)
! WRITE(*,'(a,a)')' Processor : ', LDATA(1:LSTR)
CPU_description = LDATA(1:min(80,LSTR))
endif
k = REGCLOSEKEY(MyKey)
! write(*,*) getenv@('PROCESSOR_IDENTIFIER')
! write(*,*) 'Number of cores=', getenv@('NUMBER_OF_PROCESSORS')
READ(getenv@('NUMBER_OF_PROCESSORS'),*)n_processorsTotalGetEnv
Write (*,*) ' Number of Processors/cores/threads= ', &
n_processorsTotalGetEnv, ' ', getenv@('PROCESSOR_IDENTIFIER')
Read (getenv@('PROCESSOR_IDENTIFIER'),'(a)') CPU_stepping
processor_id=2
end function
|
Last edited by DanRRight on Fri Jun 07, 2019 6:35 pm; edited 2 times in total |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 446 Location: Manchester
|
Posted: Wed Jun 05, 2019 12:05 am Post subject: |
|
|
Thank you for this observation |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Jun 05, 2019 2:06 pm Post subject: |
|
|
I remember, this has been already observed in a previous email concerning sdbg64. Here another short example named sample2.for:
Code: |
INTEGER*2 plus
INTEGER*2 a,b,res
a=1
b=2
res=plus(a,b)
write(*,*) 'a=',a,'b=',b,'res=',res
stop
end
function plus(x,y)
integer*2 x,y
integer*2 plus
plus=x+y
return
end
|
Build it via Code: |
ftn95 sample2.for /debug /64 /link
|
and start sdbg64 sample2.exe. Now pressing CTRL-F and then entering plus to the "Find Routine" window shows line number 12 in the "Find window". However, confirming the find window (via CR e.g.), sdbg64 positions to line 13 (and makes it grey).
Regards,
Dietmar |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Fri Jun 07, 2019 2:50 pm Post subject: |
|
|
Dan,
I do not get your SDBG problem, but the code example is very interesting.
I would have thought that the following line of code is asking for trouble.
READ(getenv@('NUMBER_OF_PROCESSORS'),*)n_processorsTotalGetEnv
I replaced it with :
IDENTIFIER = getenv@('NUMBER_OF_PROCESSORS')
READ(IDENTIFIER,*)n_processorsTotalGetEnv
I then proceeded to start reading information from the registry, which is very interesting.
I also maintain an environment variable which is the FTN95 version number, which can be retrieved with getenv@('FTN95_Ver')
I shall look more closely at SDBG64 and see what is happening.
Thanks for the example,
John |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Fri Jun 07, 2019 6:21 pm Post subject: |
|
|
Pity that people rarely use the debugger. And the developers do not use their compiler for anything too (teaching, consulting work, doing simulation job etc). This is clear by this example which has tons of bugs in 64bit regime and no one reported them while i do that third time already
Code: |
A=1; B=2; C=3; D=0
If(A.lt.B.and.B.lt.C) D=4
Print*, 'D=',D
END
|
In 32bits debugger works OK. But compiled with /64 and using sdbg64 we get:
1) SDBG64 does not show value of B or C if you hover with the mouse over B or C (in the popup window)
2) Instead it shows the result of logical operation which would be great if
it still somehow showed B and C too, not instead. And if it showed the result of logical operation correctly (the result should be TRUE obviously).
3) If you hover over A, B or C more than ones in sequence, second time this does not show the value. To see the value again, you need to hover your mouse over something else
There are also other problems with SDBG64 i will describe later. One is extremely annoying, all were reported too and some we already tried to resolve but i had no time to complete it.
Dietmar, John, thanks, will look at your examples and modifications when will have time |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Fri Jun 07, 2019 7:10 pm Post subject: |
|
|
Even the 32 big SDBG has a number of quirks.
If you take Dan's example and place the mouse pointer on the 'D' preceding '=' in the PRINT statement, you will see the value of the variable D displayed. SDBG seems to regard part of a (properly quoted) string as a variable.
On the line with the IF statement, with the mouse pointer on 'A', you will see the value of A. With the pointer on the 'B' after '.lt.', you will see the value of the expression A.lt.B instead of the value of just B. If you next move the mouse pointer to the second 'B' on the same line, SDBG will attempt to show you its idea of the value of the expression A.lt.B.and.B, which is nonsense. B is not a logical variable and the AND operator cannot be applied to it.
If you want to be surprised even more, use the following modification of Dan's program. I have just renamed the variables, noting that Fortran keywords are not reserved. The code is legal but certainly not well-formed.
Code: | LT=1; IF=2; AND=3; PRINT=0
If(LT.lt.IF.and.IF.lt.AND) PRINT=4
Print *, 'D=',PRINT
END |
Place the mouse on the keywords If and Print (not the variables with the same names) and you will see the variable values displayed. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sat Sep 07, 2019 4:38 pm Post subject: |
|
|
Dan wrote:-
Quote: | Pity that people rarely use the debugger. |
This is so true.
I think the glitches highlihted on this post are an excellent example because if people did use it more often there would have been more glitch reports and things would have no doubt alreadu�y been ironed out.
As for the glitches themselves this must be linked to how the debuger tracks the mouse cursor and as a result which variable value it picks up rather than the variable values themselves somehow being in error (I hope).
I als�ways remain amazed how you guys pick up some of these glitches.
My hat tips to you.
Even more tipping of the titfa is in order for the way you take the time to report even the most minor of glitches - many people no doubt would just ignore a 'wrong' value popping up as they dragged the mouse and left it over a variable for a fraction too long. _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
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
|