OpenGL in Visual Studio 2019 Community

MHONDA · May 25, 2020, 6:54am

This is an OpenGL+MFC 3D graphics application written in Visual C++ and it was working until VS2013. Now I built OK in VS2019 but when I ran, it causes an exception on glLoadName(NULL). I am using VS 2019 VC++ x64 on Windows 10. Is there anything I have to do to run o VS2019 platform? Is there any change in OpenGL?

GClements · May 25, 2020, 12:33pm

You haven’t given us much to go on, but here are some possibilities which spring to mind:

The argument to glLoadName is a GLuint, not a pointer, so NULL doesn’t make much sense. That shouldn’t affect anything unless you’re calling it without a prototype in scope (if there is a prototype in scope, the compiler will convert it to the correct type).
Is the glLoadName call the first OpenGL function being called by the program? If you failed to create and bind a valid context, it will probably crash on the first OpenGL function call.
Could you be creating a core profile context? glLoadName doesn’t exist in the core profile (nor does glRenderMode).
Are you calling glRenderMode(GL_SELECT) first? glLoadName shouldn’t be called other than in selection mode. It should be ignored in other modes, but this might be a driver bug (selection isn’t widely used, and even less so by the software which implementers care about, so it could easily slip through testing).

MHONDA · May 25, 2020, 8:04pm

Thank you for your replay - yes, I do call glRenderMode(GL_SELECT) first.

This program starts fine with OpenGL screens and some graphic maneuver like 3D screen rotaion… only when I try to pick something (which is very fundamental in this program), it crashes.

I changed to glLoadName(0); and got the same exception:

Exception thrown at 0x00007FF8524B1B7A (ig9icd64.dll) in G.exe: 0xC0000005: Access violation reading location 0x00000000000000E0.

I am calling this so that the subsequent items get an bad pick-id (to be ignored)…

This may be confusing but this is a part of the code where it crashed…

	// If re-drawing for pick purpose, give pick id ...   
	// (A) ----- ORIGINAL CODE ------------------------qaz
	//	if (renderMode == GL_SELECT) glLoadName ((GLuint)this);

	if ( renderMode == GL_SELECT )
	{
		//// (B) ----- TRY ONE ------------------------2020-05-18------
		//ULARGE_INTEGER big;
		//big.QuadPart = (ULONGLONG)this; // ok
		//DWORD lo = big.u.LowPart;
		//DWORD hi = big.u.HighPart;
		//glLoadName((GLuint)lo); // only put LowPart (discard HighPart)
		//// glLoadName((GLuint)hi);

		// (C) ----- TRY TWO ------- This is final (Win32 & x64) ---- 2017-09-09
		int pickId = SetElemInPickMap(this); // static map in CElemBase
		glLoadName((GLuint)pickId);
	}


	if ( m_elemType == ET_CIRCLE )
		glCallList(DL_CIRCLE);
	else if ( m_elemType == ET_POINT )
		glCallList(DL_POINT);
	else if ( m_elemType == ET_LIGHT_SOURCE )
		glCallList(DL_LIGHT_SOURCE);
	else
		//  glCallList((GLuint) this);   //	GLuint id = (GLuint)this;  // was 2020-5-18
		{
		int pickId = SetElemInPickMap(this); // static map in CElemBase // new -- 2020-05
		glCallList((GLuint)pickId);
		}
	//	CreateGLcalls (); // if no display list 97-1-5 we need this now???

	// Make sure to clear so subsequent items get NULL pick id
	glLoadName(0); // 2020-05-25 
	glLoadName(NULL); // was 2020-05 -  access violation   NULL); // non-pickable

I was using “this” as a pick-id. It was working fine, until x64. Since OpenGL pick-id is UINT (32), I could not use 64-bit “this” anymore, so now I converted to 32-int using some MAP. And this was working OK in the VS2015 x64 a year ago. Now this is the first time I am testing this code in VS2019 environment. It built OK but when I do a pick, it crashes…

GClements · May 25, 2020, 9:06pm

It’s possible that some other part of the code didn’t get correctly converted from 32-bit to 64-bit and you’ve just been lucky up until now.

If it’s crashing inside the driver (ig9icd64.dll), it’s quite possible that the issue isn’t with the API call in which the crash occurs but with some previous call. You might try adding some glFlush calls to see if that changes the location of the crash.

The reference to “location 0x00000000000000E0” suggests that a small integer (224) is being interpreted as a pointer.

MHONDA · May 25, 2020, 10:14pm

I tried win32 and it crashes the same way…
I added glFlush() before glLoadName and indeed it crashed at glFlush (before glLoadNmae)…

This is where I initialize the pick peration…

bool CGView::PickOperation(CPoint point)
{
	GLuint selectBuf[BUFSIZE];
	GLint hits;
	GLint viewport[4];

	// Save 2D pick point / 2000-4-22
	m_pickPoint = point;

	glGetIntegerv(GL_VIEWPORT, viewport); // get vpt for PickMatrix
	glSelectBuffer(BUFSIZE, selectBuf); // specify buffer to be used
	glRenderMode(GL_SELECT);
	glInitNames();
	glPushName(NON_PICKABLE);  // set no-pick as initial default

	glMatrixMode(GL_PROJECTION);
	glPushMatrix();  /// PUSH ///

	glLoadIdentity();
	gluPickMatrix((GLfloat)point.x, (GLfloat)(viewport[3] - point.y),
		10.0f, 10.0f, viewport);   // pick aperture

	Setup2ProjectionMode();

	m_renderMode = GL_SELECT;  // start selection mode

	// Force redraw in selection mode
	Invalidate(false);	// worked ok
	CWnd::UpdateWindow();  // this is needed for pick 96-6

	m_renderMode = GL_RENDER;  // end selection mode

	glMatrixMode(GL_PROJECTION);
	glPopMatrix();  /// POP ///
	glMatrixMode(GL_MODELVIEW);  // added for consistency 97-4-25 

	hits = glRenderMode(GL_RENDER);

	bool bHitResult = ProcessHits(hits, selectBuf);
	return bHitResult;
}

MHONDA · May 25, 2020, 10:35pm

glFlush();
glCallList(3);
glFlush();  // crash....

GClements · May 25, 2020, 11:16pm

And have you defined display list 3 with glNewList? If so, check what’s in the list.

Also: this site isn’t a debugging service.

MHONDA · May 27, 2020, 5:47am

Since I was getting an exception right after glCallList, I decided to forgo the display list and put the same gl code. Then I got the same exception after these gl code (after the last glFlush, as below). I do not know what this means…

Exception thrown at 0x00007FFFAB251B7A (ig9icd64.dll) in G.exe: 0xC0000005: Access violation reading location 0x00000000000000E0

My VS2019 environment is pretty badly screwed up…

		glFlush(); // 2020-05-25
//		glCallList(DL_POINT); // crash 2020-05
		//////////////////////////////////////////////////////////2020-05-26
		glPointSize(4.0);
		glFlush(); // 2020-05-25
		glBegin(GL_POINTS);
		glVertex3f(0.0f, 0.0f, 0.0f);
		glFlush(); // 2020-05-25
		glEnd();
		//////////////////////////////////////////////////////////2020-05-26
		glFlush(); // 2020-05-25

GClements · May 27, 2020, 12:22pm

I doubt that it’s the environment. It’s more likely that something in your code is assuming (32-bit) x86 and results in memory corruption on x86-64. With memory corruption, the point where a crash occurs often bears little relation to the location of the bug.

MHONDA · May 27, 2020, 5:07pm

Thank you for your suggestions and guidance.

Again, this 3d graphics program was working (maybe I was lucky as you said) a year ago with Visual Studio 2013 and 2015 environment. At that point, my fix was to correct the way I was using the object’s " this" pointer as the convenient, unique input argument to glLoadName(GLuint), because “this” is now a 64-bit (in x64 setup). That fixed the crash during the pick process. I do not have VS2015 so I cannot test it anymore, but I believe my fix was working for both win32 and x64. I have not touched the code for a year or so. Now, with this free VS2019 Community version, I managed to build the system OK… but crashing after clicking the screen for pick purpose. But before this simple operation, the graphics screen is displayed correctly showing the grid lines and XYZ axes and the like. I can even rotate the scene by a mouse. So OpenGL is working…
I believe memory corruption that you suspect is happening…
Is there a list of standard things I can check to see if my program violates any of these items? I wonder what changed in VS2019 in relation to its working with OpenGL?

GClements · May 28, 2020, 1:33pm

The only things I can suggest are to check that the program compiles without generating warnings, and to look closely at any casts.

If it’s memory corruption, almost anything can change the outcome from harmless to a crash. E.g. changing the order in which local variables are stored, or changing storage between registers and memory.

MHONDA · May 30, 2020, 6:45am

I am trying to simplify the CRASH scenario… Now, I do not see any difference between Win32 & x64 behavior. Both crash when I try to create a GL point by clicking the mouse button. But before that, my program paints the screen with XYZ axes. I can even rotate the axes by mouse move. Then, when I left-click to create a point (simplest scenario), it crashes. But I found yesterday that if I skip this initial XYZ axes draw, the crash does not happen and a point is correctly created on the screen. (The second point crashes though). I am squeezing my brain to understand why forgoing the Axes display changes the crash behavior… The axes are drawn by NewList & CallList, but I am now drawing without a display list, and the same thing happens, so it is not related to glNewList (as I initially suspected). This is a pretty complex program I single-handedly created some 20 yrs ago, and each time I moved to a new Visual Studio platform, I always encountered some sort of problems… Now I am facing this VS2019 porting…

MHONDA · June 9, 2020, 8:09pm

Maybe my current PC (DELL) or driver is not good…
I would like to test my CAD program with another PC with a graphic accelerator. To do that, I can put MyCad.exe and some DLLs onto a USB stick. Which OpenGL dlls do I need to put in the USB stick also when I want to run this CAD program on another PC for test? I am assuming his test PC does not have Visual Studio 2019 installed…

GClements · June 9, 2020, 8:42pm

opengl32.dll and glu32.dll are part of the Windows installation. You might need the core MSVC redistributable (vcredist) and/or the MFC redistributable; the target will almost certainly have some version of those but not necessarily the version you’re using.

MHONDA · June 13, 2020, 5:02am

Thank you for the information.

MHONDA · June 13, 2020, 6:55pm

I am refreshing my memory about PICKING operation in OpenGL that I am using…
I do glNewList(555) and glCallList(555). When in SELECT mode, I do glLoadName(555), so I can pick the object in the pick buffer by
int name = (int) *ptr++;

There is nothing wrong about using the same GLuint (555 here) for all 3 - glNewList, glCallList, glLoadName, am I right?

Somehow, my CAD program is crashing upon drawing the OpenGL object when I do a pick operation. (It is drawing just fine if no pick is done.) More specifically, if I do hits = glRenderMode (GL_RENDER), then a subsequent OpenGL rendering (say, glCallList) causes a crash… very strange.

GClements · June 14, 2020, 4:14am

Right.

Have you checked for errors? Also: are the arguments to glSelectBuffer correct? In particular, the size parameter is the number of GLuints the buffer can hold, not the size in bytes.

MHONDA · June 14, 2020, 4:53am

Exception:
Exception thrown at 0x00007FFE359E1B7A (ig9icd64.dll) in G.exe: 0xC0000005: Access violation reading location 0x00000000000000E0

I think the array size is OK…
GLuint selectBuf [BUFSIZE];
GLint hits;
GLint viewport [4];

// Save 2D pick point / 2000-4-22
m_pickPoint = point;

glGetIntegerv (GL_VIEWPORT, viewport); // get vpt for PickMatrix
glSelectBuffer (BUFSIZE, selectBuf); // specify buffer to be used
glRenderMode (GL_SELECT);
glInitNames();
glPushName(NON_PICKABLE);  // set no-pick as initial default

MHONDA · June 14, 2020, 5:00am

I just tried the same scenario with win32/debug: this is the crash —
Exception thrown at 0x79E17B5B (ig9icd32.dll) in G.exe: 0xC0000005: Access violation reading location 0x00000094.

I did another experiment by commenting out glRenderMode(GL_SELECT) — before the glRenderMode(GL_RENDER) that caused a crash. That prevented the crash and an OpenGL objects are drawn nicely on the screen, but now obviously I cannot do selection…_

MHONDA · June 20, 2020, 7:57pm

Now I realized that if I comment out glSelectBuffer (see the code below), I can avoid my cash, just as commenting out glRenderMode(GL_SELECT). Again both cases I cannot do pick operation.
Based on these behavior, I am totally puzzled as to why my original program is crashing in this VS2019…

bool CGView::PickOperation ( CPoint point )
{
	GLuint selectBuf[BUFSIZE];
	GLint hits;
	GLint viewport [4];

	// Save 2D pick point / 2000-4-22
	m_pickPoint = point;

	glGetIntegerv (GL_VIEWPORT, viewport); // get vpt for PickMatrix
//	glSelectBuffer (BUFSIZE, selectBuf); // specify buffer to be used -- 2020qaa qaz5 - if this commented out,no crash 6/20
	glRenderMode (GL_SELECT); // 2020qaz  qaz5 - if this is commented out, no crash (no select either)
	glInitNames();
	glPushName(NON_PICKABLE);  // set no-pick as initial default

	glMatrixMode (GL_PROJECTION);
	glPushMatrix ();  /// PUSH ///

		glLoadIdentity ();
		gluPickMatrix ((GLfloat)point.x, (GLfloat)(viewport[3]-point.y),
		               10.0f, 10.0f, viewport );   // pick aperture

		Setup2ProjectionMode ();

		m_renderMode = GL_SELECT;  // start selection mode

		// Force redraw in selection mode
		Invalidate (false);	// worked ok
		CWnd::UpdateWindow();  // this is needed for pick 96-6

		m_renderMode = GL_RENDER;  // end selection mode

	glMatrixMode (GL_PROJECTION); 
	glPopMatrix ();  /// POP ///
	glMatrixMode (GL_MODELVIEW);  // added for consistency 97-4-25 

	hits = glRenderMode (GL_RENDER); // 2020qaz qaz5 - this causes crash when rendering

	bool bHitResult = false; // 2020 == was ProcessHits(hits, selectBuf);
	bHitResult = ProcessHits ( hits, selectBuf ); // 2020qaz -skip and still crash
	return bHitResult;
}
/////////////////////////////////////////////////////////////////////////////
bool CGView::ProcessHits ( int hits, GLuint buffer[] )
{