PDA

View Full Version : Reasons for wglMakeCurrent to crash the program



dawn
05-26-2006, 08:05 AM
It's a pretty delicate problem, i guess ...

We are developing an application that's a kind of memory hungry (up to 1Gb) that displays various 3D scenes on the screen.

The problem is that, sometimes, on various machines (both ati and nvidia cards), the app crashes because of the MakeCurrent call. Sometimes it's just fail to set the DC and RC, doesn't crash, but, obviously doesn't display anything on the screen. Somehow, it "looses" the context.

I must specify that *all* gl calls are from the same thread and MakeCurrent is there every frame because of "future" developments (multiple outputs).

Our app runs inside internet explorer as an activex.

So, i will not ask you what is the problem (pretty hard without (explaining) the code), but to hear from you some ideas for this problem.

PS: also, on a specific machine, when the used memory is high (around 1Gb), all of the rendering goes messy ... wrong textures, wrong triangles. No gl errors thrown. If it's a memory problem, should give a out_of_memory error, right ?

jide
05-26-2006, 09:19 AM
MakeCurrent should not crash even when used each frame. Did you ensured that if you comment the MakeCurrent, the program does not crash anymore (I understand you can do it since it is for future uses) ?

Maybe the problem can come from IE + activex. Is it possible for you to test it out of those applications (mainly as a pure program) ? For this kind of program, needing a lot of memory and graphical stuffs, I would have choosen to make it a program, not an object of another program. But you might need it anyway.

You should also give more details. Does 1GB of used memory is enough for the available RAM ? Or does the program swaps ? Do you use some aperture size...

Humus
05-26-2006, 09:03 PM
What does that 1GB mean? In total, or measured on the application side? If you say load 1GB of textures, have a copy on the application side and one of the driver side you'll get 2GB. Keep in mind that the maximum amount of address space for a 32bit application is 2GB, so it could be the case that the application plus the driver is running out of address space, causing malloc() to return NULL, which could easily lead to a crash somewhere. If you have access to Win64 and are able to compile a 64bit executable you could try to see if the problem exists there.

dawn
05-27-2006, 02:02 AM
1GB is for the whole application ... it's not gfx resources. Indeed, we run into problems with malloc returning NULL, and there were due the fragmentation of the memory. These were fixed, but still i cannot get understand why "some" memory issues will result into MakeCurrent problem.

Testing is pretty hard, since it's happening once in a while, after leaving the application running for a long time.

As for the ActiveX stuff, yeah, it's happening only there. We have a version of the app, "standalone" and everything is fine.

Anyway, maybe there are memory problems, maybe the activex stuff it's not entirely correct, but why these are resulting into makecurrent problem ?

That's why i was asking you for ideas, because "debugging" led us to nothing. It's something like this: somebody has an application and makecurrent crash. What can it be ? (without refferincing the code).

jide
05-27-2006, 03:24 AM
So, you have it ! activex seems to be the guilty here. I'm pretty sure it has not been made for such memory hungry uses.
About the memory addressing, you're not going out of bounds but if your system is already using a lot of memory. If 1GB is your 'application size when running', then you must take in account memory management, ie do some swapping. I really hope you don't need so much memory all along your program run.
Finally did you tested to comment MakeCurrent ?