Crashes in Ogre 1.8.0

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
User avatar
0xC0DEFACE
OGRE Expert User
OGRE Expert User
Posts: 84
Joined: Thu May 21, 2009 4:55 am
x 7

Crashes in Ogre 1.8.0

Post by 0xC0DEFACE »

Hey all.

Last week I upgraded from from 1.7.1 to 1.8.0 and have encountered a number of serious issues which are:
  • Crash when Dragging the windowed application from one monitor to the other
  • Crash when locking and unlocking the computer while running the application
  • Crash when resizing the Application in windowed mode
  • Crash when entering and exiting full screen
None of these crashes were occurring before the upgrade. The first crash also occurs in the Ogre sample browser. All the crashes seem to be related to the same issue.

After some debugging I found that at times in the D3D9HardwareVertexBuffer.cpp file in the lockImpl function the source buffers are null which is causing the crash. See the commented code below.

Code: Select all

		// Case we use system memory buffer -> just return it
		if (mSystemMemoryBuffer != NULL)
		{
			return mSystemMemoryBuffer + offset;
		}
		
		else
		{			
			// Crashing here with mSourceBuffer or mSourceBuffer->mBuffer being null.
			// Lock the source buffer.
			mSourceLockedBytes = _lockBuffer(mSourceBuffer, mSourceBuffer->mLockOffset, mSourceBuffer->mLockLength);

			return mSourceLockedBytes;		
		}
To try to prevent the crash I added some checking here to create the buffers if they don't exist to avoid the null pointer access. See the modified code below.

Code: Select all

		// Case we use system memory buffer -> just return it
		if (mSystemMemoryBuffer != NULL)
		{
			return mSystemMemoryBuffer + offset;
		}
		
		else
		{
			if( mSourceBuffer == 0 || ( mSourceBuffer->mOutOfDate && mSourceBuffer->mBuffer == 0 ) )
			{
				for (uint i = 0; i < D3D9RenderSystem::getResourceCreationDeviceCount(); ++i)
				{
					IDirect3DDevice9* d3d9Device = D3D9RenderSystem::getResourceCreationDevice(i);
					createBuffer( d3d9Device, mBufferDesc.Pool );
				}
			}

			// Lock the source buffer.
			mSourceLockedBytes = _lockBuffer(mSourceBuffer, mSourceBuffer->mLockOffset, mSourceBuffer->mLockLength);

			return mSourceLockedBytes;		
		}	
This changes stopped the crash from occurring in my application as well as in the ogre sample browser, however it results in some assets not reloading correctly ever again.

I believe this is indicative of an issue where the D3D9 Render System in some circumstances is not regenerating necessary buffers when the device changes or resets. I've spent the last two days trying to track this down and am having a lot of trouble so any assistance would be greatly appreciated. Ive attached some images below to show the issue with assets not reloading correctly.

Thanks in advance!

Loading screen. Assets for the loading screen are stored in a bootstrap zip file.
Image
Image

In Scene. In this scene everything seems to be ok however my dynamic ambient and environment cubemaps have failed to be regenerated leading to the scene looking dull. This is a test scene, which explains the giant fish swimming in the air :P.
Image
Image

Ogre Sample Browser. This is after my hack and dragging the window from one monitor to the other. The sample browser displays similar problems to my application.
Image
Image
Pulas
Halfling
Posts: 61
Joined: Sat Oct 29, 2011 9:39 am

Re: Crashes in Ogre 1.8.0

Post by Pulas »

0xC0DEFACE wrote: [*]Crash when Dragging the windowed application from one monitor to the other
I also encountered the same problem with Ogre 1.8. When I switched RenderSystem to OpenGL, the problem disappeared.
User avatar
0xC0DEFACE
OGRE Expert User
OGRE Expert User
Posts: 84
Joined: Thu May 21, 2009 4:55 am
x 7

Re: Crashes in Ogre 1.8.0

Post by 0xC0DEFACE »

I cloned the latest ogre and copied out the latest D3D9 Renderer to make sure I was working with the head version while trying to solve this issue.

Some crashes were clearly because Resource Creation Policy=Create on active device prevents certain buffers from being automatically regenerated resulting in crashes. Switching to Create on all devices stopped a few of those.

To stop some more crashes I had to change Multi device memory hint=Use minimum system memory to Auto hardware buffers management.

With the combination of:
  • Resource Creation Policy=Create on all devices;
  • Multi device memory hint=Auto hardware buffers management; and
  • My fix from above,
I managed to get my application stable again. However the problem with the loading screen being incorrect was still happening. This is related to Vertex buffers for the OgrePanelOverlayElement not being regenerated, and then when my fix from above generates an empty vertex buffer the UV data is incorrect and never gets reloaded. To work around it I ensured that when the vertex buffers for the OgrePanelOverlayElement are created, they are told to use a shadow buffer. This way they will always have a copy in system memory of what should be in their buffer despite devices changing. This is a patch for OgrePanelOverlayElement:

Code: Select all

diff -r 0979eec27b21 OgreMain/src/OgrePanelOverlayElement.cpp
--- a/OgreMain/src/OgrePanelOverlayElement.cpp	Mon Jul 23 16:49:58 2012 -0500
+++ b/OgreMain/src/OgrePanelOverlayElement.cpp	Wed Jul 25 16:53:19 2012 +1000
@@ -102,6 +102,7 @@
 				HardwareBufferManager::getSingleton().createVertexBuffer(
 				decl->getVertexSize(POSITION_BINDING), mRenderOp.vertexData->vertexCount,
 				HardwareBuffer::HBU_STATIC_WRITE_ONLY// mostly static except during resizing
+				,true
 				);
 			// Bind buffer
 			mRenderOp.vertexData->vertexBufferBinding->setBinding(POSITION_BINDING, vbuf);
@@ -289,6 +290,7 @@
                     HardwareBufferManager::getSingleton().createVertexBuffer(
                     decl->getVertexSize(TEXCOORD_BINDING), mRenderOp.vertexData->vertexCount,
                     HardwareBuffer::HBU_STATIC_WRITE_ONLY // mostly static except during resizing
+					,true
                     );
                 // Bind buffer, note this will unbind the old one and destroy the buffer it had
                 mRenderOp.vertexData->vertexBufferBinding->setBinding(TEXCOORD_BINDING, newbuf);
After making those changes to the ogre sample browser it also worked well without crashing or misbehaving.

Now that I have a work around to make the app stable again, I may be able to look into a more correct solution. As before if anyone has any tips I'm all ears!

Matt.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 100

Re: Crashes in Ogre 1.8.0

Post by Wolfmanfx »

Hi,
Can you try rev 3337 (clean checkout) if everything works here if so i may know the root of the problem.
User avatar
0xC0DEFACE
OGRE Expert User
OGRE Expert User
Posts: 84
Joined: Thu May 21, 2009 4:55 am
x 7

Re: Crashes in Ogre 1.8.0

Post by 0xC0DEFACE »

I tried switching to 3337 as you suggested and I can confirm that crashes do not occur in that version.

However after dragging to a new monitor, the screen goes black and stops updating anything but the gui. After this if I resize the window to do something else to trigger a device reset, then everything goes back to normal.

So what do you think the problem might be?
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 100

Re: Crashes in Ogre 1.8.0

Post by Wolfmanfx »

Did you also apply this
Resource Creation Policy=Create on all devices

Every monitor is one d3d9 device.
If this fixes every crash and works like before i have the faulty revision i check on.
User avatar
0xC0DEFACE
OGRE Expert User
OGRE Expert User
Posts: 84
Joined: Thu May 21, 2009 4:55 am
x 7

Re: Crashes in Ogre 1.8.0

Post by 0xC0DEFACE »

Wolfmanfx wrote:Did you also apply this
Resource Creation Policy=Create on all devices
Yes, Resource Creation Policy=Create on all devices was still set.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Crashes in Ogre 1.8.0

Post by Assaf Raman »

Is this resolved? Do we want to fix it? What do we want to fix?
Watch out for my OGRE related tweets here.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 100

Re: Crashes in Ogre 1.8.0

Post by Wolfmanfx »

Hi assaf,

Mattan will check this on the weekend - i think we should resolve this one.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Crashes in Ogre 1.8.0

Post by Assaf Raman »

What is the issue you want to resolve? Crashes or the missing textures?
How do I recreate the crashes easily?
Watch out for my OGRE related tweets here.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 100

Re: Crashes in Ogre 1.8.0

Post by Wolfmanfx »

Sry for delay but here the way to reproduce:

checkout rev: 3343
compile it and start the samplebrowser - the only thing i changed is to be not in fullscreen mode (D3D9 RS of course)
then grab the samplebrowser window and move it to another monitor and everything works - resources gets recreated.

now checkout latest 1.8
compile it and only change the fullscreen option like above - but when you move now the window to the other monitor you get the screenshot above nothing is recreated

This means for me that the default behavior is changed in the first place in 1.7.4 the user did not play with the options and it worked.

Image
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Crashes in Ogre 1.8.0

Post by Assaf Raman »

Was able to recreate - but I need NVIDIA PerfHUD to analyze, ca someone upload PerfHUD that supports windows 7? NVIDIA site is down for weeks and I don't have it on this computer.
Watch out for my OGRE related tweets here.
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel
x 32

Re: Crashes in Ogre 1.8.0

Post by Mattan Furst »

I'm not able to recreate with one screen only and simple device loss. I guess its a problem with recreating the resources on a different device. I should have access to 2 monitor computer tomorrow.

@Assaf Raman
If you can't get perfhud by then I should have access to one too.
it's turtles all the way down
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Crashes in Ogre 1.8.0

Post by Assaf Raman »

Yes, send my the setup of PrefHud.
Watch out for my OGRE related tweets here.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 100

Re: Crashes in Ogre 1.8.0

Post by Wolfmanfx »

I did a bit debugging seems to be introduced with depth sharing patch.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Crashes in Ogre 1.8.0

Post by Assaf Raman »

I just need to compare the state - before and after - using prefhud.
Watch out for my OGRE related tweets here.
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel
x 32

Re: Crashes in Ogre 1.8.0

Post by Mattan Furst »

Found how to fix the bug. Not sure I found the reason.
When loading in "Create on all devices" mode. a memory buffer should hold the buffer of vertex and index buffers in the cpu memory so it can be reuploaded when a new device is created. This does not occur.

In OgreD3D9HardwareVertexBuffer.cpp and OgreD3D9HardwareIndexBuffer.cpp you have the lines:

Code: Select all

if (mUsage & HardwareBuffer::HBU_WRITE_ONLY && D3D9RenderSystem::getResourceManager()->getAutoHardwareBufferManagement())
{			
	[Create memory buffer]
}
If changed to

Code: Select all

if ((mUsage & HardwareBuffer::HBU_WRITE_ONLY) || D3D9RenderSystem::getResourceManager()->getAutoHardwareBufferManagement())
{			
	[Create memory buffer]
}
The bug disappears. I want to check why this happened before I confirm this as a fix. I'll try to push it for tommorow. If someone wants to do it in the mean time your welcome.

It might be better to just add my latter patch I added to the trunk which removes duplicate memory buffer (the mSystemMemoryBuffer and mShadowBuffer) from the system instead of fixing this bug. Its the same are of code.
it's turtles all the way down
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 100

Re: Crashes in Ogre 1.8.0

Post by Wolfmanfx »

@Mattan
I just tested https://bitbucket.org/sinbad/ogre/chang ... cb07e9dd96 which does not solve the problem it for me.
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel
x 32

Re: Crashes in Ogre 1.8.0

Post by Mattan Furst »

I think that the if there is still incorrect.

in the patch it again says

Code: Select all

(((usage & HardwareBuffer::HBU_WRITE_ONLY) != 0) && 
			D3D9RenderSystem::getResourceManager()->getAutoHardwareBufferManagement()))
when it probably should use "or" (||) function. The patch just removed an unnecessary second buffer. I guess I copied the logic from a bad code.

I'm sorry I wasn't more clear. I was working on the bug at work (I have dual monitors there) and I needed to leave. The reason I didn't fix anything is that I wanted to check through the history when was the "((usage & HardwareBuffer::HBU_WRITE_ONLY) != 0) && " was added or when was it started creating errors, and I didn't have yet time to do so.

I should have specified that the latter patch I did was not suppose to be the fix. I only thought it might be because I thought I might have copied the logic from a bug free code.
it's turtles all the way down
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel
x 32

Re: Crashes in Ogre 1.8.0

Post by Mattan Furst »

From what I now see in the history the and (&&) operand hasn't changed since the code was created. Since this code has worked in the past it means that it is not the problem. That probably means that when a new device is created and Ogre tries to extract the buffer from the device it was previously created on and update it to a new device it fails along the way for some reason.

I'll try to find the real bug tomorrow.
it's turtles all the way down
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel
x 32

Re: Crashes in Ogre 1.8.0

Post by Mattan Furst »

To Wolfmanfx , 0xC0DEFACE

I found out I've been working on a none bug. If you set the "Multi device memory hint" option to "Auto hardware buffers management" the black screen effect disappears and Ogre is rendered correctly.

Is there a way to produce a bad device behavior in Ogre's SampleBrowser without this option on?
it's turtles all the way down
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 100

Re: Crashes in Ogre 1.8.0

Post by Wolfmanfx »

@mattan
The problem is that in 1.7.4 we did not to change any setting and it worked out of the box.
Also the poster pointed out these settings before that it somehow works - but then again the default behavior is changed.

But below the line should we enable this option by default?
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel
x 32

Re: Crashes in Ogre 1.8.0

Post by Mattan Furst »

But below the line should we enable this option by default?
I don't consider myself high enough in the Ogre team to make that call. But if it was up to me I'd say we should keep it as is.

The "Auto hardware buffers management" causes a lot of extra memory to be allocated even though in most cases it is not needed (most programs, I'm guessing, use full screen or a single screen anyway). I think we should just add it to 1.8 release notes and that's it.
it's turtles all the way down
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: Crashes in Ogre 1.8.0

Post by bstone »

Yeah, I think that's the good point and something I and a few other Ogre users observed: the D3D9 RS footprint could easily be around 350% of the OpenGL RS for one and the same application - just because D3D9 RS in 1.7.4 always allocated and kept hardware buffer copies in system memory, no matter what its buffer usage flags were.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Crashes in Ogre 1.8.0

Post by Assaf Raman »

Well, GL doesn't have lost device...
I guess we can "reload" the none dynamic resources if needed.
In d3d11 there is no more lost device, so we will not have that extra memory there...
Watch out for my OGRE related tweets here.