crash with Intel 945GM on Vista

I have a repeatable crash in the latest driver for the Intel 945GM. Here’s the outline of what I’m doing:

Create window and GL context 1
Create window and GL context 2
Share textures between the two contexts (wglShareLists)
Make context 2 current
Create and upload a texture object
Render a triangle
Destroy window/context 2
Make context 1 current
Delete the texture object (glDeleteTextures)

That should work, right?

Is there any developer channel for reporting bugs to Intel?

there are plenty of threads here about Intel graphics and that they are amazingly unstable. couple of threads are by me actually. :slight_smile: maybe a search on the forums will help you out. one thing that would bother me right away is that you already updated to latest drivers.

Have you tried your application on another hardware? Check if your code comply with the msdn recommandations here:

Have you tried your application on another hardware?

Yes, and there’s no crash. Also, if I make it use the generic Microsoft driver instead of the Intel driver, there’s no crash.

Check if your code comply with the msdn recommandations here

There’s no threading going on in my test program, if that’s what you mean.

I have not playing myself with several RC in the same program so I don’t know if what you are doing is the correct a safe way but reading you it looks like a driver bug and it is not surprising from intel one.

the only thing you could probably do if you care about your app running on Intel is to use GLIntercept log to see where it crashes. this will give you some hints where to start digging. also GLIntercept can warn you about various GL errors which might be ignored on one driver and crash on other.

I know where it crashes, the glDeleteTextures call at the end of the outline in my first message. I guess I could have made that clearer.

I tried running it with GLIntercept, with the full-debug options, and didn’t see anything about errors in the logs.

By the way, I was told by Intel support that the 945GM is at end of life, i.e., there will be no further driver updates unless a miracle happens.

“Share textures between the two contexts” might be the problem with context. i never used wglShareLists but multiple context need alot of care to make them work properly. most of the time a driver bug indicates a bug in your code though and if nothing else gets released you have to rethink it. maybe you should delete the textures under context 2 where you created them or delete them in an alternate way one by one or with one call (array).
btw, i had to change line stipple pattern once to avoid a BSOD, funny like that.

Make context 2 current
Create and upload a texture object

What’s the point of sharing when you load a texture to the 2nd RC?
Logic is wrong here.

You load all your textures to 1st RC. This one is shared among all RCs.

If you decide to use wglShareLists(), always load and delete textures from the 1st RC.
Leave the other RCs alone.

In this simplified example, there is no particular point. In general, I do use textures in multiple contexts, and as far as I know you can’t share just some textures among contexts.

I just re-read the docs on wglShareLists, and I don’t see anything to support what you’re saying. It just makes the contexts share display list and texture space. Sounds pretty symmetrical to me. The statement

When the last rendering context of a shared display-list space is deleted, the shared display-list space is deleted.

seems to support my belief that there’s nothing special about the first context.

I’ll grant that it’s not unheard-of for an implementation to deviate from its documentation.

Well then, you’re implying that there is absolutely no difference between:

wglShareLists( RC1, RC2 )
wglShareLists( RC2, RC1 )

and I’m saying, yes, there is a difference. And no, I don’t completely trust the docs on wglShareLists.
I do what works for me.

I’m not saying that. The docs do say that when you call wglShareLists( RC1, RC2 ), RC2 should not contain any existing display lists, so of course I do it just after creating RC2. But after sharing has been put into effect, I don’t know why there should be any asymmetry.