Heap corruption on closing the window

Problems building or running the engine, queries about how to use features etc.
Post Reply
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Heap corruption on closing the window

Post by Klaim » Tue Sep 10, 2013 2:23 pm

I'm seeing a very strange bug but I'm not sure if it's my setup that is wrong or it's something Ogre is doing or anything other.

Basically, I have a window created by Ogre in windowed mode on Windows 7 64bit, I've seen this problem in Ogre 1.9 current 1.9 branch changes and some previous revisions from 2-3 months ago .

The problem is: while debugging the app which have been built in Debug or ReleaseWithDebugInfo modes,
if I close the window by clicking on the red cross -and exclusively this way-, I have some chances (it depends on timing I guess) to get a heap corruption error and breakpoint in Visual Studio debugger.

It is very strange because the error happen when Ogre tries to destroy the window. My current understanding is that the window have already been closed by the system, Ogre should not close it again. However, Ogre didn't close it before, so maybe it's really specific to the way I closed it?

Anyway I have no idea where to search for this problem now. I checked that I'm not trying to close the window twice, but I don't even do it once (Ogre does it, but only when it's too late).
I have another way to kill the app by pressing Escape, which basically destroys all systems including Ogre, in which case there is no problem. I suppose that in this case Ogre destroy the window before it is destroyed by another system.

Anyone else seeing this problem?
I should try to setup a repro case see if it's specific to Ogre, but I don't have time yet.
0 x

scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 2

Re: Heap corruption on closing the window

Post by scrawl » Tue Sep 10, 2013 3:22 pm

Does it occur in the sample browser? If not, I guess we'll need to see some of your code.
0 x

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Heap corruption on closing the window

Post by Klaim » Tue Sep 10, 2013 3:53 pm

scrawl wrote:Does it occur in the sample browser? If not, I guess we'll need to see some of your code.
Good idea, however I'll need to compile them but don't have time right now, so I'll update here when I can.
0 x

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Heap corruption on closing the window

Post by Klaim » Thu Sep 12, 2013 6:02 pm

I managed to compile Ogre 1.9 Sample Browser and can't reproduce the bug so far.
The windowed mode have a slightly different configuration in Sample Browser than in my app so I'll first try the same configuration see if it changes something.
Otherwise the problem is in my code, but it's a bit obscure.
0 x

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Heap corruption on closing the window

Post by Klaim » Fri Sep 13, 2013 10:20 pm

Ok I found part of the source of the problem but not totally.
This story is very strange:

First, I tried to identify exactly cases when the problem occurs in my app. The good thing was it was systematic.
The heap corruption breakpoint triggered by Visual Studio gives info that are not useful until you use WinDbg tools, which I don't have installed yet - will do later, another thing to learn...
After a lot of trials and removing code, I figured that the problem only occured in graphic thread, with graphic related code after the closing of the window.
Then I narrowed to this:

- the window have to be closed through the close button (which trigger window release in message pump algorithm provided by Ogre apparently), exiting the application any other way will not trigger the heap corruption (!!!??!!???!!);
- the error only appear if this code is called through the lifetime of the application:

Code: Select all

auto node_mesh = Procedural::CylinderGenerator()
.setHeight( 0.5f )
.setNumSegBase( 8 )
.setRadius( 0.5f )
.realizeMesh( "netrush-node-graphics" );
So at first I thought that maybe something was wrong with Ogre Procedural, but then I recalled that I have similar other Ogre Procedural code that I can keep alive and not have an error when closing the window.
I tried to replace this code by using a prefab cube, which not trigger the problem, as expected.

Then I realized that this snippet of code what called touthands times, once for each entity instance (!!!). It's temporary code, but still it's doing to much!
So, just in case, I refactored it in a function that calls this once and keep the mesh name on the first call, then on other call will just retrieve the mesh from the MeshManager.

Code: Select all

Ogre::MeshPtr node_mesh()
		{
			static const auto mesh_name = [] {
				auto mesh = Procedural::CylinderGenerator()
					.setHeight( 0.5f )
					.setNumSegBase( 8 )
					.setRadius( 0.5f )
					.realizeMesh( "netrush-node-graphics" );
				return mesh->getName();
			}();
			return Ogre::MeshManager::getSingleton().getByName( mesh_name ).dynamicCast<Ogre::Mesh>();
		}
Then the problem vanished. Fixed.

So, either the problem comes from something that OgreProcedural is doing, OR building the same mesh with the same name several times does provoke this error.
I tried to force the creation of the mesh (using the same code than before) only twice, but it didn't trigger the problem.

Code: Select all

Ogre::MeshPtr node_mesh()
		{
			static const auto mesh_name = [] {
				auto mesh = Procedural::CylinderGenerator()
					.setHeight( 0.5f )
					.setNumSegBase( 8 )
					.setRadius( 0.5f )
					.realizeMesh( "netrush-node-graphics" );
				Procedural::CylinderGenerator() // create it twice... no problem
					.setHeight( 0.5f )
					.setNumSegBase( 8 )
					.setRadius( 0.5f )
					.realizeMesh( "netrush-node-graphics" );
				return mesh->getName();
			}();
			return Ogre::MeshManager::getSingleton().getByName( mesh_name ).dynamicCast<Ogre::Mesh>();
		}
As I've fixed my problem and it seems related to bad usage of the code, I'll stop here investigating, but frankly it's a bit scary. :shock:
Last edited by Klaim on Sat Sep 14, 2013 1:16 am, edited 1 time in total.
0 x

scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 2

Re: Heap corruption on closing the window

Post by scrawl » Fri Sep 13, 2013 11:41 pm

Sounds scary indeed. You should consider using a memory error detector such as valgrind on linux (don't know what the equivalent tools on windows are), it can detect heap corruption and other things.
0 x

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Heap corruption on closing the window

Post by Klaim » Sat Sep 14, 2013 1:15 am

scrawl wrote:Sounds scary indeed. You should consider using a memory error detector such as valgrind on linux (don't know what the equivalent tools on windows are), it can detect heap corruption and other things.
First, I will never reuse valgrind, it have too much false positive, and totally miss tons of errors.
Second, I can't compile on linux unfortunately for now, I mean I should be able with some changes , I designed the code for, but it would mean efforts I can't focus on right now.
Third, through the Going Native sessions they talked about LLVM/Clang providing tools better than Valgrind but in exchange you need to use special compilation command and flags. I would try to use them but only once I start trying to target linux/macosx

I think making a repro case and using WinDbg in my case would be easier than trying now a conversion to unix + compiling with clang, but I also don't have time to do that immediately, I'll try either one later.
0 x

Post Reply