Access violation in draw_text call in 64 bit

I've upgraded from 8.3 to 8.5 as I saw that some access violation bugs that I was seeing might be resolved. They have become less frequent but are still there (I think they are the same or a similar bug).

When running with the debugger this issue is a lot less likely to occur although it still will crash once in a while. The error log file is below.

How can I go about isolating this? As usual, the codebase is not small and I would have trouble reproducing it in a sample.

I also believe line numbers are being mis-reported now as 8.3 showed where the call to a clearwin function was, 8.5 now shows the line number of a loop increment. This might be due to line numbers changing with conditional compilation.

Silverfrost 64-bit exception report on C:\Users\Ryan\Source\Repos\electronoptics\ElectronOptics.CPO3DS\cpo3ds.exe Mon May 20 12:36:27 2019

Access violation (c0000005) at address 7ffb1871a216

Within file CLEARWIN64.DLL In utf8_enabled at address 716 In _win_draw_text_ll at address 219 In _win_draw_text_l at address 26 Within file app.exe in DRAW_TEXT in line 10996, at address 1cc in SETUP3VIEW in line 11557, at address 96b in RUN_PROBLEM in line 19156, at address 712 in SIMPLEX_TRY in line 18419, at address 343d in SIMPLEX in line 20982, at address 1462 in MAINPR in line 8129, at address 25627 in RUN in line 3158, at address 6ec

RAX = 0000000000000000 RBX = 0000000000000007 RCX = 000000001be67d80 RDX = 0000000000000008 RBP = 0000000000000008 RSI = 000000027ffeeff0 RDI = 000000027ffeeff0 RSP = 00000000028b0670 R8 = 0000000000000008 R9 = 000000027ffeeff0 R10 = 0000000008be0000 R11 = 0000000000000fa2 R12 = 0000000000000008 R13 = ffffffffe4010fa2 R14 = 0000000000000008 R15 = 0000000000000008

7ffb1871a216) test_b [3dc+RCX],20

More information;

It does appear that the line numbers are now incorrect, the variables displayed in the debugger are for the function called (draw_text) but the line number shown is off by several hundred.

It appears to be a call to draw_characters@ that is failing, the values passed in are;

call draw_characters@('View:ZY',8,8,8)

This function is called many times before with these parameters before failing so either it is a) internal corruption in the function or b) an array limit being overrun by our code.

Ryan,

I had problems with DRAW_TEXT@, too, in 2017.

I decided to substitute calls DRAW_TEXT@ by DRAW_CHARACTERS@ .

You might want to look at posts

DRAW_LINE@ and DRAW_TEXT@ by DanRRight (Posted: Thu Jan 11, 2018 5:10 am)
Unknown symbols in GUI app link by myself (Posted: Tue Apr 04, 2017 10:29 am)

Moreover it is true that sdbg64 makes problems for the 8.50 environment. I don't even see the source code after having started sdbg64.exe. Using menu --> File --> View File, I may open the ftn95 source file the executable of which I want to debug. However, the debugger highlights a declaration statement and I cannot set any breakpoint (for executable statements the debugger refuses this and displays 'This line cannot be breakpointed').

Regards, Dietmar

Thanks Dietmar,

That had already been done, hence the badly named function draw_text which is a wrapper around draw_characters@. It's the draw_characters that it is getting lost in.

I'll take a look at those posts as well though.

Ryan

I don`t speculate about which of both routines is hen and which is egg 😉

What I would like to know is if DRAW_TEXT@ is supported at all by ftn95 for 64 bits.

In 2017 I substitued DRAW_TEXT@ by DRAW_CHARACTERS@ while porting a big GUI application from 32 bit to 64 bit because DRAW_TEXT@ simply generated problems/crashes.

From http://www.silverfrost.com/manuals/clearwin.pdf I know that DRAW_CHARACTERS@ is the ClearWin+ alternative to DBOS routine DRAW_TEXT@ and that DRAW_TEXT@ belongs to the category of

functions that could be ported from existing DBOS programs but which should not be written into new programs because there is a better alternative under ClearWin+

For ftn95 64 bit, version 8.50, DRAW_TEXT@ still crashes, see the code following (named test_graphics_window1.for):

      integer i
      integer*4 IHDGR2
      include <clearwin.ins>
      external gr_init_func
      i=winio@('%gr[white,rgb_colours]&',400L,300L)
      i=winio@('%sc',gr_init_func)
      end
      
      integer function gr_init_func()
#IF _WIN64
      include <dbos.ins>
#ENDIF         
      include <clearwin.ins>
      integer*2 j
#IF _WIN64
      CALL DRAW_CHARACTERS@('64 Bit Version',30,220,RGB@(0,0,0))
#ELSE
      CALL DRAW_CHARACTERS@('32 Bit Version',30,220,RGB@(0,0,0))
#ENDIF
      CALL DRAW_CHARACTERS@('DRAW_CHARACTERS@',200,200,RGB@(0,0,0))
#if DRAW_TEXT
      CALL DRAW_TEXT@('DRAW_TEXT@',100,200,RGB@(0,0,0))
#ENDIF
      gr_init_func=1
      end

Compiling this code for 64 bit and activating call DRAW_TEXT@ by means of

ftn95 test_graphics_window1.for /64 /cfpp /Define DRAW_TEXT 1 /link

crashes and displays error list

Silverfrost 64-bit exception report on c:\ds\samples\salford_8.50\test_graphics_window1.EXE  Tue May 21 12:10:13 2019


Access violation (c0000005) at address 7fefd872060

Within file KERNELBASE.dll
In  MultiByteToWideChar at address 160
In  MultiByteToWideChar at address 1B
Within file kernel32.dll
In  GetTextExtentPointA at address 126
Within file GDI32.dll
In  GetTextExtentPoint32A at address E
In  _win_draw_text_ll at address 29D
Within file CLEARWIN64.DLL
In  _win_draw_text at address 1B
Within file test_graphics_window1.EXE
in GR_INIT_FUNC at address a7
Within file CLEARWIN64.DLL
In  _set_mg_return_value at address 883E
In  TranslateMessageEx at address 29D
Within file USER32.dll
In  TranslateMessage at address 1E2


RAX = 0000000000000000   RBX = 0000000000406000   RCX = 0000000000000000   RDX = 000000000240e648
RBP = 0000000000000000   RSI = 000007fffffb001c   RDI = 0000000004a11db0   RSP = 000000000240ef80
R8  = 0000000000405148   R9  = 000000000240f500   R10 = 0000000000000000   R11 = 0000000000000286
R12 = 0000000000065940   R13 = 000000000240f500   R14 = 0000000004a10040   R15 = 0000000002814648

7fefd872060) movzx_b_q       RAX,[RBX]

Compiling the same file but deactivating call DRAW_TEXT@ via

ftn95 test_graphics_window1.for /64 /cfpp /link

works ok as expected. The corresponding 32 bit versions of the same file both work ok as expected.

Regards, Dietmar

Hi John-Silver,

ftn95 option

/Define DRAW_TEXT 1

defines preprocessor symbol DRAW_TEXT to 1 and makes line

CALL DRAW_TEXT@('DRAW_TEXT@',100,200,RGB@(0,0,0))

active for the compile. If you do not define DRAW_TEXT then this line would not be used by ftn95. You might want to check this via commands

ftn95 test_graphics_window1.for /64 /cfpp /lis
ftn95 test_graphics_window1.for /64 /cfpp /Define DRAW_TEXT 1 /lis

Both commands create so called *.lis files which contain the preprocessed code which is used by ftn95. Executing the first of the two creates a lis file which will not contain DRAW_TEXT, executing the second will create a *.lis file containing DRAW_TEXT. Thus I may specify in the command line whether the critical statement calling DRAW_TEXT@ is used or not.

Regards, Dietmar

The two issues raised on this thread are probably unrelated.

Dietmar...

The interface for DRAW_TEXT@ in DBOS.INS is not correct. At the moment I don't know what it should be. Is it possible for you to change to DRAW_CHARACTERS@?

Ryan...

I may need further details in order to work out what is going wrong.

Paul,

I already changed to DRAW_CHARACTERS@ months ago ... so I have no problem ... 😃

As the interface of DRAW_TEXT@ for the 32 bit version works I thought the same should be true for the 64 bit version.

The interface for DRAW_TEXT@ is correct for the 32 bit version, isn't it?

Regards, Dietmar

Dietmar

Yes. DRAW_TEXT@ works without an interface for 32 bit ClearWin+. It is one of a number of old DBOS graphics routines that do not need an interface for 32 bits. If you want to use these old routines for 64 bits then you can include dbos.ins except for the fact that the line in dbos.ins for DRAW_TEXT@ is incorrect.

Apologies everyone, I've not been seeing replies. I'll follow up soon but first I need to open another post on probably unrelated floating point errors.

In the next release DRAW_TEXT@ will be available for 64 bit applications. The fix is in both dbos.ins and clearwin64.dll.

It's not a problem Paul, draw_text was a red herring and was just a function in the user code that called draw_characters@ (or similar).

DRAW_TEXT@ and similar (now undocumented) DBOS routines should not be used in new code. There are equivalent alternatives. At the moment DRAW_TEXT@ will not work in 64 bit compilations even when DBOS.INS is included.

Aha, Paul. Methinks it isn't so much 'new code', but rather attempting to get 'old code' working in a new context.

The failure to transition old facilities is something that upsets loyal, long-term, users, and doesn't matter a jot to new coders.

Eddie

Thanks Eddie. I assumed (perhaps incorrectly) that John-Silver's interest does not relate to legacy code.

Paul, I suspect that I have been sensitized in this respect by my favourite drawing program, CorelDRAW!, not supporting previous version files. Doesn't matter at all to new customers, matters a lot to 'old faithfuls'.

A couple of years ago I found the paperwork from when I attended the launch of Clearwin. I forget now, was it 1992? So the DBOS graphics got superceded a very long time ago. The legacy was perhaps the legacy of a legacy of a legacy!

Eddie

John-Silver,

you might want to look at the online help of ftn95 where /Define and /CFPP are both mentioned.

Sorry for the confusion. Option '/Define DRAW_TEXT 1' together with option 'cfpp' is used to make line

CALL DRAW_TEXT@('DRAW_TEXT@',100,200,RGB@(0,0,0)) 

seen by the compile step (or not). Option /cfpp means that the compiler first preprocesses the code before compiling it. Option '/Define DRAW_TEXT 1' makes that the code following line '#if DRAW_TEXT' up to the next #ENDIF is active after the preprocessor step. This has nothing to do with the semantics of CALL DRAW_TEXT@. It is only used to make the code line containing 'DRAW_TEXT@' be used by the compile step or not.

If option '/Define DRAW_TEXT 1' is missing it is the same as if you would have decommented the line containing 'DRAW_TEXT@'. You need option '/CFPP' because otherwise ftn95 would complain about the #IFDEF.

Regards, Dietmar