forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Start using debuggers, people
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sun Jun 03, 2018 3:25 am    Post subject: Reply with quote

Dan,

Are you going to make the same mistake 100 times a day for the rest of your life ? ...
Imaging how much time you are wasting having a coffee each day; and all the time you have spent moving all over the world.

You should start using implicit none and get rid of most of those bugs. You must be able to do that in less than 300 days !

I'm off for a coffee, as I just found a "bug" that's been bothering me for 4 years. By your analysis, will I have more time now ?

John
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Jun 03, 2018 4:24 am    Post subject: Reply with quote

John,
Of course we waste hell amount of time on humongous amount of cr#% in the world. Sometimes we can not do anything with it sometimes we can.

I use /UNDEF, which is better then implicit none, John, how may time I repeat this in 3 decades on all Fortran newsgroups and no one hear that?

I copy/paste large variables (and they usually all large for self-documenting) not typing them again and again so there is no source of error for static variables. Also I use new compilation options /NO_TRUNCATE which removes the main source of errors catched by the "implicit none" - i.e. getting over 72/132 character limit. So my mouse trap is pretty powerful.

It's the logic errors which are the main source of bugs in large codes not just damn static typos. To move even most stupid step ahead in large code (add some new obvious feature for example) i need to review if this will not interfere with the whole older stuff I added for 30 years which is why I make most of errors. All heavily used codes essentially grow and grow and at some point become unmanageable. Even if I have done that 100 times adding new feature is like a head surgery in the web of the source code.

And also the code development is the main source of lost time not run time for those who make codes in physics. BTW, today Saturday just started, but I already have done 30-40 compilations.

To get a proof that /undef is more powerful then "implicit none" take any large code made by someone which never used /undef but used only "implicit none" and make a fun of its author showing how many bugs his code has. I guarantee the code's author will spend a month in total #$%^& trying fixing all that.


Last edited by DanRRight on Sun Jun 03, 2018 10:08 am; edited 2 times in total
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sun Jun 03, 2018 6:52 am    Post subject: Re: Reply with quote

DanRRight wrote:
To get a proof that /undef is more powerful then "implicit none" take any large code made by someone which never used /undef but used only "implicit none" and make a fun of its author showing how many bugs his code has.

Dan. this is a good idea. I shall try it with my graphics code. Is /64 /undef supported, as I have just started using /64 /check ?
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Mon Jun 04, 2018 11:02 am    Post subject: Reply with quote

Robert,

thanks for the link to the zipfile containing a new version of sdbg64.exe which fixed the problem of setting a variable within sdbg64.

Regards,
Dietmar
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 444
Location: Manchester

PostPosted: Tue Jun 05, 2018 8:34 am    Post subject: Reply with quote

I put a new version up at that link. It closes the executable much faster. It misses out some cleanup code. Can people report any issues when closing down the debuggee.
Back to top
View user's profile Send private message Visit poster's website
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Jun 05, 2018 8:45 pm    Post subject: Reply with quote

Dan, what am I supposed to see with your Hello 'program' ?
As I see it nothing happens it just lags the only line in the program.
_________________
''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 ... Smile "
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Wed Jun 06, 2018 12:39 pm    Post subject: Reply with quote

Robert,

with version 8.30.2 of sdbg64 I now run into problems when opening some of the debugger's "Window" menu. When trying to debug
Code:

      integer*4 idum
     
      idum=5
      write(*,*) 'idum=',idum
      end

(the example I mentioned above)
    opening submenu "Variables" has no effect,
    opening submenu "Common blocks" opens no window and makes sdbg64 hang.


Has anyone else observed similar problems with this version of sdbg64?

Regards,
Dietmar
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 444
Location: Manchester

PostPosted: Thu Jun 07, 2018 8:01 am    Post subject: Reply with quote

Doesn't the variables window open automatically?
Back to top
View user's profile Send private message Visit poster's website
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Thu Jun 07, 2018 8:45 am    Post subject: Reply with quote

Robert,

no, the variables window does not open automatically.

The problem is even worse now.

After having started the sdbg64 debugger (version 8.30.2) once, the variables window did not open automatically.

The next start of sdbg64 did not even show the source window of the debuggee, this was the case for sdbg64 version 8.30.2, version 8.30.1 and 8.30.

I have no idea what might have happened with respect to my build/sdbg64 environment with respect to yesterday.

Regards,
Dietmar
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 444
Location: Manchester

PostPosted: Thu Jun 07, 2018 8:50 am    Post subject: Reply with quote

It might we worth having a look at the sdbg64.ini file to see if it has any corrupted values in it. On my machine it is at:

C:\Users\Robert\AppData\Roaming
Back to top
View user's profile Send private message Visit poster's website
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Thu Jun 07, 2018 10:37 am    Post subject: Reply with quote

Robert,

thanks for the hint. I did not find any suspicious data in my current sdbg64.ini file, however, I overwrote it with a backup from 2017. This helped to be able to debug again and see windows

    call stack
    variables


per default. Some observations:

1.
First line of file sdbg64.ini is

[Debugger-Win32]

which seems to be strange for a 64 bit debugger.

2.
Where do I find information about the semantic of sdbg64.ini?

3.

Some time ago I complained about not being able to see the version information window after having clicked menus "Help" and "About Debugger..." in sdbg64. This is still a problem and I wonder if this problem might be related to my sdbg64.ini file.

4.
To me it is unclear what caused the problem to the previous sdbg64.ini files which seemed to be wrong.

Regards,
Dietmar
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Thu Jun 07, 2018 11:47 am    Post subject: Reply with quote

Robert,

in connection with a problem previously mentioned I ran in another problem when trying to change an integer*8 variable from within sdbg64.

Code:

      integer*4 idum
      integer*8 idum8
     
      idum=5
      idum8=4294967296
      write(*,*) 'idum=',idum
      write(*,*) 'idum8=',idum8
      end
     

Now I stopped the debugger after the idum8 assignment and tried to change idum8 using the command tool of sdbg64 and command
Code:

let idum8 = 1

; this resulted in value
Code:

-3689348818177884159

for idum8 which was not what I expected.

By the way, it would be nice if I could have had the chance of copying the idum8 value to the clipboard from one of the windows displaying variable idum8 in sdbg64.

Regards,
Dietmar
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 444
Location: Manchester

PostPosted: Fri Jun 08, 2018 4:52 pm    Post subject: Reply with quote

I have updated sdbg64 to handle the let statement with integer*8 variables. I have also added a Copy onto the context menu for the single line inspectors.
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Jun 10, 2018 9:53 am    Post subject: Reply with quote

Robert, Thanks for 3 sec delay fix. Please look at other suggestions/problems of SDBG64 above.

And one more bug to fix: when compiler/SDBG64 gets overflow or denormal variable it crash with access violation instead of error report like SDBG is doing
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Mon Jun 11, 2018 12:00 pm    Post subject: Reply with quote

Robert,

thanks for the update to the let statement and the addition of the copy to the context menu. I have downloaded this new version (8.30.3) from the web link you mentioned above. Using the let command I could set variable idum8 to 1 as expected.

However, command

Code:

let idum8 = 2147483648

still does not work in my opinion. This command results in
Code:

idum8: -2147483648

which I think is not correct.

Note: 2147483648 equals 2**31 which is 1 more than MAX_INT (2147483647). For variable idum (which is of type INTEGER*4) this result is ok and it is shown by sdbg64 for idum after having executed the let statement:
Code:

idum: -2147483648

However, idum8 is of type INTEGER*8 !!!

I changed the original test programme to sdbg_test1.for:
Code:

      integer*4 idum
      integer*8 idum8,idum88
      idum=2147483647
      idum8=2147483647_4

      idum88=2147483648
      write(*,*) 'idum=',idum
      write(*,*) 'idum8=',idum8
      write(*,*) 'idum88=',idum88
     
      idum8=idum8+1
      write(*,*) 'idum8=',idum8
      end

and compiled it using command
Code:

ftn95 sdbg_problem1.for /debug /64 /link

Executing sdbg_problem1.exe resulted in output lines
Code:

idum=  2147483647
idum8=           2147483647
idum88=           2147483648
idum8=           2147483648

This shows that idum8 and idum88 work in the code and executable as expected.
Moreover: the ftn95 command mentioned above resulted in
Code:

WARNING - Constant is out of range for INTEGER(KIND=3) - has been promoted to
    INTEGER(KIND=4)

Finally I tried using assignment
Code:

idum8=2147483647_8

which however resulted in
Code:

*** Invalid KIND specifier
0006)       idum88=2147483648
WARNING - Constant is out of range for INTEGER(KIND=3) - has been promoted to
    INTEGER(KIND=4)
    1 ERROR, 1 WARNING  [<main program> FTN95 v8.30.0]
*** Compilation failed



I wonder if sdbg64 still has a problem here.

Regards,
Dietmar
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
Jump to:  
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