Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

Exceptions in OpenGL functions

Stephen_Sutcliffe1
230 Views

I've just rebuilt a project using the latest version of Intel Parallel Studio Fortran 2017 Update 1 and the program crashes at the call to the OpenGL function:

call fgluQuadricDrawStyle(SObj,GLU_FILL)

Unhandled exception at 0x000007F8CC89A138 (glu32.dll) in FEM2000_x64.exe: 0xC0000005: Access violation writing location 0x00000000B5D62D9C.

I've checked that the SObj is the correct variable type (INTEGER*4) and has been initialised using

SObj  = fgluNewQuadric()

so not sure what's causing this. The message seems to suggest that the wrong (32-bit instaed of 64-bit) glu32.dll library is being involved somewhere.

When I revert back to the previous version 2016 in VS2010 the problem goes away. 

Any ideas?

Thanks

 

0 Kudos
9 Replies
Steven_L_Intel1
Employee
230 Views

It won't be a wrong DLL - it is clear that a 64-bit DLL is being used.

What I see is that gluNewQuadric returns a pointer to the Quadric and that gluQuadricDrawStyle wants the pointer passed in. The declarations in IFOPNGL have this as integer*4, which is incorrect for a 64-bit platform. I think you may have gotten lucky with the older compiler.

As a workaround, copy ifopngl.f90 into your project and edit the declarations of these routines to specify INTEGER(K_GLVOID) for the function return and argument rather than integer*4. It looks as if there are other functions that will need this.

I'll take a quick look to see how extensive the problem is.

Steven_L_Intel1
Employee
230 Views

Use the attached - add them to your project. I found that basically all of the Quadric routines were incorrectly declared. I will have this fixed.

 

Stephen_Sutcliffe1
230 Views

Thanks Steve, that's fixed it.

 

andrew_4619
Honored Contributor I
230 Views

confession! I found all the glu quadrics were wrong for X64 a couple of years ago but didn't mention it. Sorry! I don't use the IFORT gl/glu btw, I use Bind(C) versions, all the quad types are by right type C_PTR in my world but I guess you are stuck with "integer pointers" because that would break users existing code.

Steve, I recall there was some move to update some of the windows sdk interfaces and add some new APIs. Have any new interfaces been added recently and/or what is the status of this project? I ask because I have quite a number of additional interfaces but I won't see any conflicts do to obsessive use  of  USE ONLY so it might be appropriate to "tidy up" at some point.

Steven_L_Intel1
Employee
230 Views

17.0 has a thousand or more new APIs - mostly in KERNEL32 but some in other modules. I've just submitted more updates to KERNEL32 to complete it as far as Windows 8.1, at least. (I also discovered and fixed some errors.) I can't tell you what the future might hold here.

It is a daunting and labor-intensive task to do these updates. I automated bits of it but every API needs manual review and may need tweaks.

andrew_4619
Honored Contributor I
230 Views

I just had a delve in kernel32 and it seems there are about 3000 new lines of code added to the 7000 already there! Having a quick in my own stuff the first handful that I checked seem to be there now and pleasingly also now "A" postfix versions for unicode. Cheers!

 

Steven_L_Intel1
Employee
230 Views

Don't get too excited about the Unicode entry points. That's not currently a priority. Also, it's the W-suffix entry points that are Unicode. A is for 8-bit ASCII.

andrew_4619
Honored Contributor I
230 Views

Yes brain fade the "A" is for ANSI I believe, I have implimented quite a few "W"s......

Stephen_Sutcliffe
New Contributor I
230 Views

I have just checked the files in the latest update and the corrections to ifopngl.90, as made by Steve L (retired), do not seem to have been implemented yet. Is it still Intel's intention to review and update these types of inconsistencies in this and any other declaration modules (e.g. Windows API)?.

 

Reply