|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Apr 28, 2018 12:33 pm Post subject: Summary, WINIO@ bug: there are no OPENGL bugs |
|
|
I tested Wahorger's program (with the stack probes removed, see below for source) with versions 6.35, 7.20 and 8.30 of the compiler. With all the compilers, we see the bug associated with 32-bit WINIO@ calls; each call to WINIO@ leaves the stack pointer ESP reduced by 4 bytes. To see this, compile with /debug, open the resulting program in SDBG, put breakpoints on the lines with the WINIO@ calls, open the registers window, and observe the ESP value before and after stepping over each of the two WINIO@ calls.
After discovering this bug, I went back to a number of bug reports submitted by users concerning graphics. I built the test codes that they submitted with the 32-bit compiler and watched the stack as I stepped over WINIO@ statements: I saw that 4 bytes are lost per call, every time.
If the correct OpenGL interface module is used (not opengl$ -- that is for compilers other than FTN95), there is no stack related problem with OpenGL calls.
There is no stack problem in 64-bit mode. The second WINIO@ call has more than 4 arguments, so the stack does get used.
Perhaps some users will be misled by the "64 bit Clearwin+" entry in the current FTN95 help file, since it pertains to non-FTN95 compilers.
Code: | winapp
program bw
use clearwin
use opengl
implicit none
integer, external :: winio@
integer :: i,ctrl
integer(kind=7) :: window_handle
i=winio@('%es%ca[Simple OpengGL Sample]&')
i=winio@('%sp%ww[not_fixed_size]%og[static]%hw%lw',0, 0, 400, 400,window_handle,ctrl)
CALL glClearColor (0.0, 0.0, 0.0, 0.0)
CALL glClear(GL_COLOR_BUFFER_BIT)
CALL glColor3f(1.0, 1.0, 1.0)
CALL glMatrixMode(GL_PROJECTION)
CALL glLoadIdentity()
CALL glOrtho(0d0, 10d0, 10d0, 0d0, -1d0, 1d0)
call glnewlist(1,gl_compile)
call glBegin(GL_LINE_STRIP)
call glVertex2f(0.,0.)
call glVertex2f(10.,10.)
call glEnd()
call glEndlist()
call glCalllist(1)
call glFinish()
call swap_opengl_buffers@()
call glCalllist(1)
call glFinish()
call swap_opengl_buffers@()
pause
end |
The source code used to produce the two modules:
Code: | module opengl
include <opengl.ins>
end module
module clearwin
include <clearwin.ins>
end module |
Last edited by mecej4 on Sun Apr 29, 2018 1:21 pm; edited 2 times in total |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Apr 29, 2018 5:28 am Post subject: |
|
|
After correcting the opengl.ins issues (local copy with edits), I got the following results.
1. Three routines in opengl.ins are not found in the opengl32.dll. This is odd, but Dan doesn't use these three calls for his routines, so still working on this.
Quote: |
glClearColor
glClear
glColor3f
|
The routines do have a proper declaration in opengl.ins, but do not apparently exist in the opengl32.dll file in the c:\Windows\system32 folder that the linker uses (by default). I find this odd because these three routines are part of the original OpenGL baseline. But, I took them out, and things still work, so......
2. Taking those calls out leaves me with no issues with the OpenGL calls remaining. No stack issues with OpenGL calls whatsoever. This is VERY helpful to me, and I thank all of you for weighing in.
3. There exists a conflict between "USE MSWIN" and "INCLUDE 'opengl.ins'", specifically the routines in the opengl.ins file (right at the bottom) namely:
Quote: |
!
! Win32 API functions converted from wingdi.h
!
STDCALL WGLUSEFONTOUTLINES 'wglUseFontOutlinesA' (VAL,VAL,VAL,VAL
&,VAL,VAL,VAL,REF):LOGICAL*4
STDCALL SWAPBUFFERS 'SwapBuffers' (VAL):LOGICAL*4
STDCALL WGLUSEFONTBITMAPS 'wglUseFontBitmapsA' (VAL,VAL,VAL,VAL)
&:LOGICAL*4
STDCALL WGLSHARELISTS 'wglShareLists' (VAL,VAL):LOGICAL*4
STDCALL WGLMAKECURRENT 'wglMakeCurrent' (VAL,VAL):LOGICAL*4
STDCALL WGLGETPROCADDRESS 'wglGetProcAddress' (STRING):INTEGER(7)
STDCALL WGLGETCURRENTDC 'wglGetCurrentDC':INTEGER(7)
STDCALL WGLGETCURRENTCONTEXT 'wglGetCurrentContext':INTEGER(7)
STDCALL WGLDELETECONTEXT 'wglDeleteContext' (VAL):LOGICAL*4
STDCALL WGLCREATECONTEXT 'wglCreateContext' (VAL):INTEGER(7)
|
In my modified opengl.ins file, I took these declarations out (commented), and no compile errors.
mecej4, I have not yet created a .MOD file. Thanks for the process! |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2820 Location: South Pole, Antarctica
|
Posted: Sun Apr 29, 2018 9:29 am Post subject: |
|
|
Bill,
I made search in my codes briefly and found glColor3f, glClear was still used (see links below ). But in one place i found my comment that glColor3f conflicted with transparency bit when you set the color 4-byte RGBT value where T is for transparency. That was so long ago i forgot any details. Probably this was a result of try-and-see.
Interesting that the part you commented is conflicting with something. This could be the reason that this part was on and off in opengl.ins for years and i complained about its extraction because wglUseFontBitmaps is used for displaying 3D fonts.
http://forums.silverfrost.com/viewtopic.php?t=1606&highlight=wglusefontbitmaps
http://forums.silverfrost.com/viewtopic.php?t=3074&highlight=font+opengl |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sun Apr 29, 2018 3:04 pm Post subject: Re: |
|
|
wahorger wrote: |
1. Three routines in opengl.ins are not found in the opengl32.dll.
glClearColor
glClear
glColor3f
The routines do have a proper declaration in opengl.ins, but do not apparently exist in the opengl32.dll file in the c:\Windows\system32 folder that the linker uses (by default). I find this odd because these three routines are part of the original OpenGL baseline. |
I looked at the opengl32.dll in my W10X64 system32 and syswow64 directories, and both do contain all three of the routines that you listed.
What are the date, file size and version number of your opengl32.dll? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Sun Apr 29, 2018 5:34 pm Post subject: |
|
|
Don't forget that SLINK probably does not automatically scan openGL32.dll. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sun Apr 29, 2018 7:50 pm Post subject: |
|
|
mecej4, you said:
Quote: | After discovering this bug, I went back to a number of bug reports submitted by users concerning graphics. I built the test codes that they submitted with the 32-bit compiler and watched the stack as I stepped over WINIO@ statements: I saw that 4 bytes are lost per call, every time. |
can you give a list of the posts concerned please ? Ta. _________________ ''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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Apr 30, 2018 12:27 am Post subject: |
|
|
John S:
1. Rudnei's example code, in four pieces, at http://forums.silverfrost.com/viewtopic.php?t=3744&highlight=winio
2. Your example code, in two pieces, at http://forums.silverfrost.com/viewtopic.php?t=3769&highlight=npcplex2v2a2test3
3. DanRRight's example code, in two pieces at http://forums.silverfrost.com/viewtopic.php?t=3788&highlight=module+allsubsbremms, after fixing the bugs in it
In fact, you can pick any code that contains WINIO@ calls. The bug is perfectly reproducible and simple in nature. It is also easy to work-around, pending a proper fix from Silverfrost. After n calls to WINIO@, add CALL ADJESP(n). The fix-up is done in assembler code, given below, which can be assembled using NASM (obtained from https://www.nasm.us/ ), and linked to your FTN95 code with SLINK.
If you are a victim of stack-anxiety, you can add CALL ADJESP(1) after every call to WINIO@.
Code: | ; call adjesp(n) -- add 4*n to esp
;
; nasm.exe -f win32 adjesp.asm
;
global _ADJESP
SECTION .text
_ADJESP:
pop eax ; return address
pop ecx ; arg, contains number of 32-bit words to 'pop'
mov ecx, [ecx]; count of 32-bit words to pop
lea esp, [esp + 4*ecx - 4]; -4 since caller will pop arg
jmp eax |
Last edited by mecej4 on Mon Apr 30, 2018 11:02 am; edited 1 time in total |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Apr 30, 2018 4:45 am Post subject: |
|
|
Paul, it seems to scan C:\Windows\System32\OpenGL32.dll. It is listed in the linker map. That doesn't mean, however, that those routines are actually there. On my laptop, there are two different Opengl32.dll files, two very different sizes, and date/time stamps within a couple of hours of each other. All in the Windows folder under various sub-folders.
Still looking. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Apr 30, 2018 5:18 am Post subject: |
|
|
The two opengl32.dll files, if in windows\system32 and windows\syswow64, are 64 and 32 bit versions, so only one of them will be used with one of your programs. The one in system32 will be used in a 64-bit program.
It is possible to have an import library (for a DLL) that was produced from an earlier version of the DLL, so that there is a mismatch in the externals named in the two. The fact that some symbols are not in the DLL will be noticed when an attempt is made to load the DLL and access the routine; not at link time.
Last edited by mecej4 on Mon Apr 30, 2018 10:28 am; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Apr 30, 2018 8:23 am Post subject: |
|
|
mecej4
Many thanks for this report. The ESP adjustment for 32 bit calls to winio@ has been corrected for the next release of FTN95 (the adjustment was correct for FTN90 and apparently overlooked when porting to FTN95).
I aim to provide an interim version of FTN95 available shortly for those who would like to test recent fixes.
The incorrect ESP adjustment is unlikely to cause a stack overflow because calls to winio@ require runtime user interaction and so will always be limited in number. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Apr 30, 2018 10:56 am Post subject: |
|
|
It is very pleasant to see such a rapid resolution of a rather complicated compiler bug compounded by usage errors. Thanks, Paul.
I think that at this point there are no unanswered questions relating to stack corruption caused by calls to WINIO@ or OpenGL routines. It would be reassuring to have Bill Horger confirm this, after he corrects his full application program to use the correct OpenGL module (OPENGL, not OPENGL$).
The stack will still lose 4 bytes/WINIO@ call but, as Paul has noted, this should not lead to noticeable errors. This defect, too, will be removed in the interim release of the compiler, and Bill Horger will probably be one of the first users to employ that release. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Apr 30, 2018 12:42 pm Post subject: |
|
|
I have looked at files with the name opengl$.mod.
On my machine I have a file with this name (perhaps from an old installation) in Silverfrost\FTN95\include. This was compiled with 32 bit FTN95 and no longer serves any purpose (I suspect that this file was never released).
Also I have a file with this name in SilverFrost\FTN95\include\gFortran. This was compiled with 64 bit gFortran and is for use with 64 bit gFortran (my understanding is that, for 64 bits, STDCALL is no longer distinct from CDECL so the source code is correct). |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Apr 30, 2018 2:53 pm Post subject: |
|
|
Paul, thanks for taking a look at the includes.
Resolved: Routine names missing at link time. I have tried to replicate the issue with the routine names not linking to the executable. I have tried this on two different platforms, and cannot replicate. I am convinced it was my error, although I may never know the root cause.
In regards to the winio@ ESP issues, I agree that the likelihood of having a stack corruption is very small as to be infinitesimal. The only stack issues of this magnitude that I have had occur have been when the ESP register is affected for tens to hundreds of thousands of times.
mejec4, thanks for your efforts on previous version of FTN95! For me, most of my winio@ calls are in subroutines, and ESP gets restored to the proper value upon return, so the issues does not "propagate" for me.
And, Paul, thanks for providing the fix!
When you have a product that is mature, it gets harder and harder to find bugs. I know in my own code, I had a minor bug that lay dormant for 20+ years, only to rear its head when I used the routine in a new context. These are tough to find without user provided information. This forum, and these people, are really good at drilling down to find these!
Thanks to you all! Proceeding with OpenGL! |
|
Back to top |
|
|
|
|
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
|