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 

Access violation in draw_text call in 64 bit
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Mon May 20, 2019 1:37 pm    Post subject: Access violation in draw_text call in 64 bit Reply with quote

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
Back to top
View user's profile Send private message
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Mon May 20, 2019 2:06 pm    Post subject: Reply with quote

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,Cool

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.
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Mon May 20, 2019 6:13 pm    Post subject: Reply with quote

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

Code:

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
Back to top
View user's profile Send private message
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Mon May 20, 2019 7:39 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon May 20, 2019 8:02 pm    Post subject: Reply with quote

Link to Dan's post:-

http://forums.silverfrost.com/viewtopic.php?t=3689&highlight=drawline+drawtext

Have you got the include 'dbos.ins' in your progrom Ryan ?


Dietmar's post:-

http://forums.silverfrost.com/viewtopic.php?t=3477&highlight=drawline+drawtext

I guess the key thing to take home from these posts was to convert your old proggies to use DRAW_CHARACTERS@, or risk incompatabilities arising on an ad hoc basis (like all programs some level of backward compatability will be retained of course, but for how long depends on the length of a piece of string and the 'virulence of changes introduced over time).

Then aain it could just be the cool dude in shades at the end of your call to DRAW_**** LOL Smile
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon May 20, 2019 8:23 pm    Post subject: Reply with quote

Quote:
That had already been done, hence the badly named function draw_text which is a wrapper around draw_characters@.


I thought the chicken was 'DRAW_TEXT' and it's egg was DRAW_CHARACTERS' and not the other way around and so I don't see how the older bird can be a wrapper around the spring chicken.

If you see what I mean.

In any case the older fowl is way past it's sell-by date as I mentioned in my previous comment , so could pop it's clucks (1) at any time Smile

Note
(1) dutch readers might get this dodgy wordplay, being better as they are at english than even the english ! alstebleif (or something like that ) Smile

Post Scriptum
After looking it up there seems to be widespread ignorance of the precise origin of the idiom I referred to above, at least in the anglophonic web.
e.g. at https://www.phrases.org.uk/meanings/pop-your-clogs.html (the same explanation given in several sources)
We actually of the perfide albion use it in simple terms too as 'to pop your shoes off', e.g. when they're soaking through or hurting your feet ('Ill have to pop me shoes off, they're killing me' (killing, but not in the terminal sense, but in the sense of they might if you didn't relieve the pressure !)

So maybe it's actually of dutch (or other) origin. If anyone knows let us, well me anyway, know too ! We anglo-saxons take these things all too for granted.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue May 21, 2019 11:21 am    Post subject: Reply with quote

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

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
Quote:
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):
Code:

      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
Code:

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

crashes and displays error list
Code:

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
Code:

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
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue May 21, 2019 9:09 pm    Post subject: Reply with quote

Hi Dietmar,

what does : /Define DRAW_TEXT 1
on the command line do exactly ? (I couldn't find documentation for '/Define' command line option)
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Wed May 22, 2019 9:54 am    Post subject: Reply with quote

Hi John-Silver,

ftn95 option
Code:

/Define DRAW_TEXT 1

defines preprocessor symbol DRAW_TEXT to 1 and makes line
Code:

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
Code:

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu May 23, 2019 12:56 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Thu May 23, 2019 1:13 pm    Post subject: Reply with quote

Paul,

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

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu May 23, 2019 3:21 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Thu May 23, 2019 6:04 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri May 24, 2019 8:46 am    Post subject: Reply with quote

In the next release DRAW_TEXT@ will be available for 64 bit applications. The fix is in both dbos.ins and clearwin64.dll.
Back to top
View user's profile Send private message AIM Address
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Fri May 24, 2019 10:40 am    Post subject: Reply with quote

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).
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 -> Support 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