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?

Would you have source code files that are in Unicode?

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

How could I detect Unicode files?

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.

I have checked all files of my project. All files are ANSI code.

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

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

      CALL SETTRV(32_2)
      END

and sdbg64_test1.for

      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

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?

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

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

sdbg64_test1.for

      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

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

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.

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

Got this message posted by OP at the very beginning of debugging, after which debugger crashed

I have made a note that there are a couple of issues here that are awaiting a response.

Quoted from DietmarSiepmann 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.

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

Of course I am using /ALTkinds for SALFORD compiles.

Regards, Dietmar

There is a more recent build of sdbg64 here: http://www.ftn95.co.uk/ftn95/ftn95-8.10/sdbg64.exe

Hopefully it will solve your problems using non ASCII characters in your source files.