View previous topic :: View next topic |
Author |
Message |
dpannhorst
Joined: 29 Aug 2005 Posts: 165 Location: Berlin, Germany
|
Posted: Wed Mar 08, 2017 9:54 am Post subject: Problem with SDBG64 |
|
|
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 |
|
|
Robert
Joined: 29 Nov 2006 Posts: 449 Location: Manchester
|
Posted: Wed Mar 08, 2017 11:32 am Post subject: |
|
|
Would you have source code files that are in Unicode? |
|
Back to top |
|
|
dpannhorst
Joined: 29 Aug 2005 Posts: 165 Location: Berlin, Germany
|
Posted: Wed Mar 08, 2017 1:09 pm Post subject: |
|
|
I don't think so. I am using Textpad for editing my source code.
How could I detect Unicode files? |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 449 Location: Manchester
|
Posted: Wed Mar 08, 2017 1:19 pm Post subject: |
|
|
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 |
|
|
dpannhorst
Joined: 29 Aug 2005 Posts: 165 Location: Berlin, Germany
|
Posted: Wed Mar 08, 2017 1:40 pm Post subject: |
|
|
I have checked all files of my project. All files are ANSI code. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Thu Mar 09, 2017 1:52 am Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Mar 09, 2017 12:05 pm Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1895
|
Posted: Thu Mar 09, 2017 1:18 pm Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Mar 09, 2017 2:16 pm Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Fri Mar 10, 2017 1:51 am Post subject: |
|
|
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 |
|
|
dpannhorst
Joined: 29 Aug 2005 Posts: 165 Location: Berlin, Germany
|
Posted: Fri Mar 10, 2017 9:34 am Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Fri Mar 10, 2017 11:07 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sun Mar 12, 2017 10:26 am Post subject: |
|
|
Got this message posted by OP at the very beginning of debugging, after which debugger crashed |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Mon Mar 13, 2017 8:57 am Post subject: |
|
|
I have made a note that there are a couple of issues here that are awaiting a response. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1895
|
Posted: Mon Mar 13, 2017 5:46 pm Post subject: Re: |
|
|
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 |
|
|
|