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 

Problem with SDBG64
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
dpannhorst



Joined: 29 Aug 2005
Posts: 156
Location: Berlin, Germany

PostPosted: Wed Mar 08, 2017 9:54 am    Post subject: Problem with SDBG64 Reply with quote

Every time when I start a debug session with SDBG64 I get this message:

http://www.dpannhorst.de/download/ErrorMessage.jpg

After pressing "Ignorieren" (Ignore) multiple times SDBG64 opens the source code window.

Sometimes between the sessin the message appears again.

What is the reason of this message on my machine?
Back to top
View user's profile Send private message Visit poster's website
Robert



Joined: 29 Nov 2006
Posts: 204
Location: Manchester

PostPosted: Wed Mar 08, 2017 11:32 am    Post subject: Reply with quote

Would you have source code files that are in Unicode?
Back to top
View user's profile Send private message Visit poster's website
dpannhorst



Joined: 29 Aug 2005
Posts: 156
Location: Berlin, Germany

PostPosted: Wed Mar 08, 2017 1:09 pm    Post subject: Reply with quote

I don't think so. I am using Textpad for editing my source code.

How could I detect Unicode files?
Back to top
View user's profile Send private message Visit poster's website
Robert



Joined: 29 Nov 2006
Posts: 204
Location: Manchester

PostPosted: Wed Mar 08, 2017 1:19 pm    Post subject: Reply with quote

If you look at the encoding for the file. Usually it is in File|Save or similar. I was wondering if it was saved in Unicode and had characters above 255 (that is what the assert suggests). Some Latin characters can do this.
Back to top
View user's profile Send private message Visit poster's website
dpannhorst



Joined: 29 Aug 2005
Posts: 156
Location: Berlin, Germany

PostPosted: Wed Mar 08, 2017 1:40 pm    Post subject: Reply with quote

I have checked all files of my project. All files are ANSI code.
Back to top
View user's profile Send private message Visit poster's website
DanRRight



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

PostPosted: Thu Mar 09, 2017 1:52 am    Post subject: Reply with quote

I also had this ones or twice though forgot to make a note when it happened (but clearly not at the start of SDBG64).

Robert, are you responsible for the SDBG64? Then plz take my other notes about SDBG from Clearwin+ thread
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 69

PostPosted: Thu Mar 09, 2017 12:05 pm    Post subject: Reply with quote

Hello,

in this context I have had a problem, as well, with sdbg64 which crashes when trying to step into a subroutine. I created a sample consisting of two files, sdbg64_test.for
Code:

      CALL SETTRV(32_2)
      END

and sdbg64_test1.for
Code:

      SUBROUTINE SETTRV (IDUM)
      INTEGER*2 IDUM
      IDUM=167   !+
      RETURN
      END       


. The second,sdbg64_test1.for, contains the German umlaut which is E4 (228) in ASCII.
Now compiling, linking and debugging for 64 bit, results in an error when trying to step into SETTRV (via sdbg64). A window with titlebar "Microsoft Visual C++ Runtime Library" pops up displaying "Debug Assertion failed!" and further on "Expression: c>= -1 && c <= 255". Doing the same with respect to the 32 versions for compiling, linking and debugging, I can step into subroutine SETTRV from sdbg and everything works fine. The same is true for the 64 bit scenario if I remove character from the code.

We are trying to port a bigger application and I am afraid we have lots of German umlaute in the coding ...

The version of ftn95 is
Version: 8.10.0
Built: Sat Feb 11 12:23:39 2017

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



Joined: 31 Oct 2006
Posts: 609

PostPosted: Thu Mar 09, 2017 1:18 pm    Post subject: Reply with quote

Apart from the debugger issues, there is another issue with your test code that I hope you are aware of: you are passing a constant expression as the argument to the subroutine, which is attempting to change the value. If you fix this bug, do you still see the debugger problem?
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 69

PostPosted: Thu Mar 09, 2017 2:16 pm    Post subject: Reply with quote

Oops, sorry, you are write, I was not aware of that, just copied some code.
Fixing this bug does not help. E.g.
sdbg64_test.for
Code:

      integer*2 idum
     
      idum=2_2
      CALL SETTRV(idum)
      END


sdbg64_test1.for
Code:

      SUBROUTINE SETTRV (IDUM)
      INTEGER*2 IDUM,C
      C=IDUM   !+
      RETURN
      END


shows just the same behaviour as with the original (mistaken) code.

Thanks and regards,
Dietmar
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1706
Location: Sydney

PostPosted: Fri Mar 10, 2017 1:51 am    Post subject: Reply with quote

Your use of the following worries me greatly, especially as you are a FTN95 user !!
idum=2_2
CALL SETTRV(32_2)

"32_2" is not portable and extensive use would be a nightmare, should you use another compiler. This is a hidden trap waiting to catch you out.

What would you expect 32_4 to give ?

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



Joined: 29 Aug 2005
Posts: 156
Location: Berlin, Germany

PostPosted: Fri Mar 10, 2017 9:34 am    Post subject: Reply with quote

I'm still interested to get a solution for my problem with SDBG64. All my files seem to be ANSI code. I get this message for some of my projects, not for all. Sometimes the message appears during the debug session also.
Back to top
View user's profile Send private message Visit poster's website
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 69

PostPosted: Fri Mar 10, 2017 11:07 am    Post subject: Reply with quote

John,

as far as I remember, we have introduced the notation 32_2 and 32_4 to distinguish between 2 byte and 4 byte integer constants when using INTEL compilers (for Windows and Linux operating systems). We then used this notation, as well, for the SALFORD version of the code to be compiled and were happy to have a common notation for 2 byte and 4 byte constants in both the INTEL and the SALFORD compile environment.

I would like to emphasize the previous entry: I am interested in a solution of my problem with sdbg64.

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



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

PostPosted: Sun Mar 12, 2017 10:26 am    Post subject: Reply with quote

Got this message posted by OP at the very beginning of debugging, after which debugger crashed
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 4689
Location: Salford, UK

PostPosted: Mon Mar 13, 2017 8:57 am    Post subject: Reply with quote

I have made a note that there are a couple of issues here that are awaiting a response.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 609

PostPosted: Mon Mar 13, 2017 5:46 pm    Post subject: Re: Reply with quote

DietmarSiepmann wrote:
John,

as far as I remember, we have introduced the notation 32_2 and 32_4 to distinguish between 2 byte and 4 byte integer constants when using INTEL compilers (for Windows and Linux operating systems). We then used this notation, as well, for the SALFORD version of the code to be compiled and were happy to have a common notation for 2 byte and 4 byte constants in both the INTEL and the SALFORD compile environment.

The point that John Campbell made is worth noting. The kind number suffixes _2 and _4 are not portable, and unless you use the /ALTkinds option, the meaning given by FTN95 is at variance with that given by Intel Fortran. In particular, the kind number 4 corresponds to 64-bit integers rather than 32-bit integers, as you intended, if you forget to use /ALT.

Try the following test program with the two compilers. Make runs using FTN95 with and without the /ALT option and compare the outputs.
Code:

program ds
implicit none
integer(2) :: i2
integer(4) :: i4
!
i2=32_2
i4=32_4
print *,i2*i2*i2
print *,i4*i4*i4*i4*i4*i4*4
end program
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 1, 2  Next
Page 1 of 2

 
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