View previous topic :: View next topic |
Author |
Message |
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Mon May 20, 2019 1:37 pm Post subject: 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 |
|
Back to top |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Mon May 20, 2019 2:06 pm Post subject: |
|
|
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,
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Mon May 20, 2019 6:13 pm Post subject: |
|
|
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 |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Mon May 20, 2019 7:39 pm Post subject: |
|
|
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 |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon May 20, 2019 8:02 pm Post subject: |
|
|
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 _________________ ''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 ... " |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon May 20, 2019 8:23 pm Post subject: |
|
|
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
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 )
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 ... " |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Tue May 21, 2019 11:21 am Post subject: |
|
|
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 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 |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue May 21, 2019 9:09 pm Post subject: |
|
|
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 ... " |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed May 22, 2019 9:54 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Thu May 23, 2019 12:56 pm Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu May 23, 2019 1:13 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Thu May 23, 2019 3:21 pm Post subject: |
|
|
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 |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Thu May 23, 2019 6:04 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Fri May 24, 2019 8:46 am Post subject: |
|
|
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 |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Fri May 24, 2019 10:40 am Post subject: |
|
|
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 |
|
|
|