SDBG64 quits abruptly when asked to open a source file

The following zip file contains three source files and three include files, all of which together amount to less than a hundred lines.

 https://www.dropbox.com/s/5a849rsjvn0uwty/smpdbg.7z?dl=0

After downloading and extracting, please compile with /64 /debug, and link the three object files.

Open the resulting EXE in SDBG64, then click on File, View File. Select prelim.f from the file menu. At this point, on most attempts, I find that SDBG64 closes all windows and quits after about three seconds, with no messages of any kind.

I do not know if the problem is caused by SDBG64 or the debug information in the EXE. Omitting blkdta.obj in the link step yields an EXE that displays normal behavior inside SDBG64.

Here is a very short reproducer. I think that the presence of BLOCK DATA is causing a malfunction in SDBG64.

File main.f:

      program mainprg
      common /xx/x(5)
      call sub(x)
      end program

File sub.f:

      subroutine sub(x)
      dimension x(5)
      print '(5F6.1)',x
      return
      end

File blk.f:

      block data
      common /xx/x(5)
      data x/1.0,2.0,3.0,4.0,5.0/
      end

Compile all three files using /64 /debug and link. Open the EXE with SDBG64, use the File, View File menu items and open blk.f. SDBG64 quits after a couple of seconds.

P.S. If someone tries this short reproducer and sees the contents of blk.f without SDBG64 quitting, please tell me the versions of FTN95 and SDBG64 that you use.

What is the status of BLOCK DATA for FTN95 /64 ? I recall that there was some restrictions on this, but can't find where this is listed. Was it related to slink64 or to the size of common using block data ?

I remembered this discussion regarding /save and /zeroise for 64-bit compilations: https://forums.silverfrost.com/Forum/Topic/3694 . On 20 Feb 2020 (02/20/2020 in US format!), Paul wrote:

/ZEROISE has now been fixed for the next release after v8.61.

/64 /UNDEF /ZEROISE will preset SAVEd variables to zero.

John, is this the topic that you recall, or was it something different and specific to Block Data?

There was another thread in which Eddie described a very useful artifice to ensure that needed initialisations in Block Data were not lost because the user inadvertently left out its OBJ file from the list of files presented to the linker:

Give a name to the Block Data program unit, and declare that name EXTERNAL in the main program unit.

Yes, I did mention that method, but I have no idea whether it works with all compilers. It wasn’t an original idea of mine, but I got it from a blog once maintained by Les Hatton. Incidentally, I also never used EXTERNAL until I started to use Clearwin+, and I’ve never used it in any other context.

I have never actually used BLOCK DATA, mainly because I used several older or subset compilers that did not support it. I do, however, usually do all initialisations in a particular subroutine, which for convenience I call BLOCK_DATA ! The great advantage of having everything in a subroutine is that you can call it several times. You may need to do this, for example, in a single-document-interface program when the user selects File|New. (MDI is too hard for me – and if the programs are small enough, you can always launch multiple instances of it).

Eddie

The problem here was to do with the fact that block data has no executable statements so sdbg64 followed a bad pointer. This has been fixed and the latest sdbg64 can be download from the sticky link at: https://forums.silverfrost.com/Forum/Topic/3780

Thanks, Robert!

The new 8.64 version of SDBG64 works correctly not only with the two reproducers but also with the unabridged program, which spans 142 source files + 22 include files.