Problem with MFC closing view using OpenGL driver

[robmar]

Okay, you can duplicate this problem, i.e. that when using the OpenGL device, there is a 5 second hang on closing the MFC view (or app), by using the MFC Wavy example here viewtopic.php?p=133188

Add this change, and then run first under D3D9, when the flag is waving, close the app, the shutdown is almost instant.

Run again, break at the code point, move the code position to select the OpenGL driver, and continue. This time, on closing the app, there is a 5+ second delay.

cpp Code: Select all

 
CIrrThread::CIrrThread(void) :
    m_hStop( CreateEvent( NULL, TRUE, FALSE, NULL ) )
{
    m_hWnd = NULL;
    m_hThread = NULL;
    m_dwThreadId = 0;
 
    // Driver defaults
// Set break point here below, run first with d3d driver, see how quickly the app shuts on close, then re-run, select opengl, and then see that it takes 5 seconds to shutdown
        if ( 1 )
            m_sIe.icp.DriverType = irr::video::EDT_DIRECT3D9;
        else
            m_sIe.icp.DriverType = irr::video::EDT_OPENGL;
 
        m_sIe.icp.AntiAlias = true;
         m_sIe.icp.Bits = 32;
 
    // Create events
    m_hStop = CreateEvent( NULL, TRUE, FALSE, NULL );
}
 

I´ve compiled this under Windows 7, VS 2010.

[CuteAlien]

This is about multithreading? Or did you have it also without multithreading? (Debugging multithreaded applications is not really fun...)

[robmar]

I don´t think so.

Although I´ve located the issue in my MFC app where I run Irrlicht in its own thread, if I select the D3D driver it works perfectly, with no 5 second hang on the SendMessage to destroy the view.

So unless the OpenGl driver has an issue with threading, its not related.

The guy that wrote the OpenGL driver for Irrlicht had problems with the external window device contexts, some of his comments are sorta funny, he was pulling his hair out I guess.

Maybe he would have an idea about this, can we ask?

[CuteAlien]

*sigh* don't say things are not related unless you know - especially not when it comes to multithreaded applications. I can guess wild around myself.

At least we have now an example - I try if I can find some time to reproduce this and understand the code, been a long time since I did anything with MFC (who is using this anyway these days... MFC is so dead...).

[robmar]

ahh ha ha, okay, yes, agreed!

actually, MFC has a massive user-base. MS tried to dump it, but they had a riot! Now they´ve even added gesture recognition, you know the Apple-type screen interface, to version 7.0 in Visual studio 2010.

but, there are only two threads, the main MFC message thread, and the irrlicht thread.

And, with the D3D9 driver, everything works perfectly, so there is a working reference model...

...MFC works by messaging, and with the opengl driver, the SendMessage call doesn´t seem to get acknowledged, its thread calls all the shutdown functions, but for some reason it just doeesn´t return for 5 seconds...

I´d happily give $50 bucks to the Irrlicht foundation for anyone to solve that one!! Its gonna be something real obvious and its so frustrating!!

[CuteAlien]

I just spend an hour getting the stuff to compile and start that ... and can't reproduce it. OpenGL or DirectX - when I quit it stops immediately. Sorry, but back to step 1 - I need a example with which I can reproduce the problem. And if you can reproduce it already on your system try to make it simpler. Kick out everything you don't need. If you can reproduce it without threads do so (threads make things so much more tricky to understand - especially when it comes to messages). I know creating a good test-case is often a lot of work (I've sometimes spend days fulltime working just on getting a testcase for hard bugs), but there isn't really another way to even start debugging.

But first step - update your graphic-card drivers. Maybe OpenGL simply has some trouble on your system which are fixed with a newer version.

[robmar]

damn, its rarely easy, is it.

I´m using Irrlicht 1.7.2 official release, Windows 7 64-bit, MFC 7.0, Visual studio 2010, the latest driver from NVidia for the GT 540M, latest OPenGL from NVidia...

I also tried with release 1.8 beta, but still the same.

I can try to reproduce on Win XP and Intel HD graphics, to see if the Wavy sample behaves the same. Will do that tomorrow as its late here now, will let you know.

at least then we can see if its a system-related issue... i guess

[robmar]

So a little progress today! I set-up a PC with ATI HD6310 GPU, Windows 7 64-bit, all updated, and the 5 second hang problem does not occur! Its just very very slow, CPU is maxed out so I guess the 6310 is no match for NVidia´s 540M.

The behaviour of Irrlicht/my app is also occasionally different, as sometimes textures loaded to one mesh jump to another mesh.

Also, on the ATI 6310 driver one of the shaders won´t load, works fine on the NVidia GPU.

I re-installed NVidia drivers this time from ATI, not from NVidia, slightly older version, and this time, good old Visual Studio 2010 is reporting an exception in the NVidia driver (nvoglv32.dll), caused after the SendMessage call in MDIDestroy()!!

So it looks like an NVidia driver issue after all.

Visual Studio 2010 was not, for some unknown reason, alerting that an exception occured, but now, with the different NVidia driver via Acer, it is.

Searched with Google and other OpenGL users were reporting a similar issue back in 2010, also mentioning SendMessage, but so far I´ve not found a solution.

Perhaps another possiblity is that under Windows 7 64-bit (WOW mode), the OpenGL driver is doing something, such that sendmessage crashes... something that under 32-bit mode, or XP didn´t casue a problem.

[CuteAlien]

Next week I might have a new 64-bit system, I can try there again.

[robmar]

That would be good, appreciate any help!

Annoying that VS2010 didn´t alert me of the crash, so many hours digging through code! Typical poor VS debug handling of exceptions, where not even the try-catch blocks work in debug! Arggghhh Microsoft!!

This looks like the NVidia driver is getting called on a dead window, maybe opengl doesn´t know the window has be destoyed... what could it be?

Are there any ATI GPUs that support all features? The HD6310 doesn´t seem fully capable.

[hendu]

It's more likely that your shader is invalid than the 6310 missing a feature (it's a dx11/GL4.2 card afterall). Nvidia's drivers often let invalid shaders pass.

If you don't get enough error output from irrlicht, see AMD shaderanalyzer.

[robmar]

Thanks for the tip, thats a handy tool. I´ve compiled the shaders with it, and even the Irrlicht sample HLSL one, and some warnings and errors were produced, such as no "main" entry point, but with the HLSL files there are two entry points, normally mainVS and mainPS, so I think that error may not actually be an error as such. (I can send you or post the shader if you´d like to see it).

As to the crash occuring in the NVidia driver library, nvoglv32.dll, there are numerous crash reports from users that have the NVidia Optimus technology with Intel/Nvidia setup, such as this one http://sourceforge.net/projects/glfw/fo ... ic/4373156 and this http://forums.nvidia.com/index.php?showtopic=220478.

I installed the latest driver from Acer for the 5750G laptop with 540M GPU, this was version 8590 (downloaded 18/04/2012). With this version, my app closes the window with teh usual 5 seconds hang, but thereafter trying to run irrlicht again in opengl mode just hangs the app. I have to force a close and restart.

I then installed the NVidia 540M driver, version 296.10, and that again has the 5 second hand, but I can re-run Irrlicht from within the app without a total hang occuring. So this is the best option at the moment.

It certainly looks like it is a driver issue, but maybe also it could be fixed by a change to the opengl irrlicht driver.

[CuteAlien]

I know I'm repeating myself over and over... but so far I still don't seem to get through to you. The way to find bugs is reducing the problem to the minimal code to reproduce it. Unless you do that we won't get closer to a solution. A general rule is - if you need more than 50 lines you haven't found it yet.

As long as you work with huge applications like the MFC sample linked above there can be so many things going wrong that even guessing where the problem is doesn't make much sense. Divide and conquer - split your application until it can't be reduced anymore by a single line. Only then you can talk about starting(!) to hunt such a bug.

I promise I won't mention it again. But I also won't bother looking again at this until you have at least done that first step.

[robmar]

I included the driver info incase someone else comes across the same issue.

And, I think that the Wavy sample is about as simple as it gets.

A simple MFC app with irrlicht. I am using threading as is the wavy sample, so thats part of the test setup.

I mean I have to produce the error, not reduce it until its not the same thing.

If I remove the threading and it works, thats no good, I need multithreading, as do many apps.

[CuteAlien]

Well, no it's not good enough as long as other factors can be the reason. If you remove the threading and it works you know it's a problem with messages+threads. If it does still not work you know it's another problem. If you kick out the wave stuff and it works it might have been some bug in there (maybe there's simply something messing with memory?). Etc... you do not debug until you have localized your bug and at least I do not know another method beside divide and conquer except for trivials bugs where it's obvious with just looking at it what's going wrong.

Sorry, but this is simply the way to figure out non-trivial bugs. Unless you have a better method I would recommend to just try it. I mean why waste lot of time when in the end you might find out that there simply was an one-off-error in an array in the flag code which was messing with memory for example? All you do is guessing around so far- and that is because unless you have localized the origin of the bug there is nothing anyone can do except guessing around. I mean really - this is the first step you usually do - why don't you just try it?

edit: By the way - which Irrlicht version are you using? Because I noticed the MFC-example no longer compiles with trunk.