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 

Speaking of stacks....
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat Apr 28, 2018 12:33 pm    Post subject: Summary, WINIO@ bug: there are no OPENGL bugs Reply with quote

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
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Sun Apr 29, 2018 5:28 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Apr 29, 2018 9:29 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sun Apr 29, 2018 3:04 pm    Post subject: Re: Reply with quote

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


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

PostPosted: Sun Apr 29, 2018 5:34 pm    Post subject: Reply with quote

Don't forget that SLINK probably does not automatically scan openGL32.dll.
Back to top
View user's profile Send private message AIM Address
John-Silver



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

PostPosted: Sun Apr 29, 2018 7:50 pm    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Apr 30, 2018 12:27 am    Post subject: Reply with quote

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
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Mon Apr 30, 2018 4:45 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Apr 30, 2018 5:18 am    Post subject: Reply with quote

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


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

PostPosted: Mon Apr 30, 2018 8:23 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Apr 30, 2018 10:56 am    Post subject: Reply with quote

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


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

PostPosted: Mon Apr 30, 2018 12:42 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Mon Apr 30, 2018 2:53 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 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