Sign in to follow this  

[.net] Strange Bug in VS.NET Compiler?

This topic is 4807 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey, I've got a "funny" bug and do not know, what to do with it. First the code:
		public bool RenderSprite(int spritenum, int pos_x, int pos_y, Rectangle portion, float scale)
		{
			if (SpriteDevice == null) 
			{
				OutputDebug(new Exception("SpriteDevice is null"));
				return false;
			}
			try
			{
				Rectangle temp = portion;
				if (scale != 1.0f)
				{
					temp.Height = (int)(temp.Height * scale);
					temp.Width = (int)(temp.Width * scale);
				}
				Texture temp2 = (Texture)Textures[spritenum];
				if (temp2 == null)
				{
					OutputDebug(new Exception("Texture @ Index " + spritenum.ToString() + " is null!"));
					return false;
				}
				//int i = 0;
				SpriteDevice.Draw2D(temp2, portion, temp, new Point(pos_x, pos_y), Color.White);
				return true;
			}
			catch (Exception ex)
			{
				OutputDebug(ex);
				CheckforReset();
				return false;
			}
		}

	public bool RenderSprite(int spritenum, int pos_x, int pos_y, Rectangle portion)
		{
			return RenderSprite(spritenum, pos_x, pos_y, portion, 1.0f);
		}

The problem is: When i call the upper method, no Texture will be displayed. If i delete the outcomment-tags in front of the int i = 0; above the Draw2D method, it does draw the texture! When i now call the overwritten second method (that does nothing else but calling the method above), it will display no texture! BUT: If i outcomment the int i = 0; and call the second method again, it will paint the texture. Anyone any idea, why?? Thanks for your help! This is driving me nuts... Metzler

Share this post


Link to post
Share on other sites
Do you actually use i? The compiler should give a warning about it being unused, but I agree that it certainly is a curious problem.

Share this post


Link to post
Share on other sites
My guess would be that some sort of stack corruption is going on, if the compiler even decides to build "i" into the program. A rebuild maybe?

Just for fun, try setting i to temp.Height or temp.Width and see if anything happens.

Share this post


Link to post
Share on other sites
No, i do not use i. Thats one of the funny things :)
(actually i got it to work by completely killing the scale part of the code, i didnt use it anyway ;)).
Another really funny thing was: I had about 3 calls to the render-function. So, depending on which "configuration" i used, it sometimes showed the bitmap, sometimes didnt. The Bitmap that was to be shown was the first one in the render queue. If i sat the Bitmap to the last position in this queue, it suddenly rendered the bitmap, depending on the position, my mouse was at, although there was no relationship btw. the variables, i used for the mouse pos and the position, i wanted the bitmap to be drawn at... Never seen anything like that b4...
Felt kind of a flight-sim: When i moved the mouse upwards, the bitmap went down, when i moved the mouse to the left, the bitmap went right etc.... Really really strange...

Share this post


Link to post
Share on other sites
This sounds very odd. If this was a compiler bug, the sheer number of regression tests we have should have caught it I think. Draw2D takes a pointer for its 4th parameter right (the one you're creating an object on the heap for)? You can just pass the constructor, and it gets created on the stack instead. I really don't know what's going on. What version of VS are you using?

Share this post


Link to post
Share on other sites
Visual Studio .NET 2003 on Windows XP SP2.
I yesterday installed the .NET 1.1 SP1. Didnt help...
If you want, i can send you the project (just for the fun of it ;))
Perhaps you can tell me, where the problem is...

Edit: Setting i to temp.Width seemed to kill the "flight-sim" behavior...
@CpMan: Stupid question, but what do you mean with just passing the constructor?

[Edited by - Metzler on October 12, 2004 4:55:19 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Metzler
Hey,

I've got a "funny" bug and do not know, what to do with it.
First the code:


SpriteDevice.Draw2D(temp2, portion, temp, new Point(pos_x, pos_y), Color.White);



Sure, send it to me and I'll try it later tonite if I get a chance.

When you call Draw2D, you pass a point object to it by calling "new Point(pos_x, pos_y)". This creates a new Point object on the heap and you'll need to "delete" it later. Furthermore, the signature of your Draw2D should be Draw2D(...,...,..., pointer, ...). You can instead, pass it like this:


SpriteDevice.Draw2D(temp2, portion, temp, Point(pos_x, pos_y), Color.White);


This creates the Point istance on the stack instead, and you won't have to worry about memory leaks because it will get automatically destroyed when it goes out of scope.

Share this post


Link to post
Share on other sites
Quote:
Original post by CpMan

SpriteDevice.Draw2D(temp2, portion, temp, Point(pos_x, pos_y), Color.White);


This creates the Point istance on the stack instead, and you won't have to worry about memory leaks because it will get automatically destroyed when it goes out of scope.

It's C#, so you have to use new. It won't even compile without. Don't worry, the point will be created on stack despite the "new". "new" is used with value-types for uniformity.

Regards,
Andre

Share this post


Link to post
Share on other sites
Hey, I'm getting some mixed behavior all around, but I at least am repro'ing your error. What's your MSN/AIM address so we can work on this together?

Share this post


Link to post
Share on other sites
There is definately some stack corruption or SOMETHING, I have no idea. For instance, taking the Draw2D out of the try-catch blocks shows the image, but it slides back and forth with the mouse. Commenting out the int i = 0; line then will cause it to stay still. In release mode, results vary also. However, I'd be hard pressed to say this is a compiler bug. I'm going to look elsewhere.

Matt

Share this post


Link to post
Share on other sites
Hrmm..I'm stumped at the moment. It feels like stack corruption, but I can't pinpoint a location or reason. Furthermore, searches on the internet regarding stack corruption only reveal unmanaged callbacks. Perhaps this has something to do with D3DX? I'll keep looking.

Matt

Share this post


Link to post
Share on other sites
I had a wierd problem with the compiler last night actually.
I am using M$ C# 2003 with .NET 1.1.

I had an inheritance hierarchy like:

DirectXEngines.ResourceItemBase
DirectXEngines.D3DGraphicsEngine.VideoResourceItemBase
DirectXEngines.D3DGraphicsEngine.MeshBase
RockPaperScissors.ThreeD.Mesh
RockPaperScissors.ThreeD.MeshRenderer

I realised that it might be a good idea (something I overlooked in the design) to have an override of OnInvalidate which checks the memory pool of the resource before calling an abtract OnOnInvalidate.
I implemented this in VideoResourceItemBase, but was rather surprised when I didn't get an error in the texture resources in my graphics engine or in Mesh.
Instead, when Mesh.OnOnRestore called an abstract PostLoadOperation in MeshRenderer, I got a runtime exception saying that OnOnInvalidate was not implemented.

How very strange.
I was going to investigate further, but had to get on with coursework (sooo much here in the UK) and when I got back to it I forgot EDIT: to keep the code :EDIT and just implemented it in Mesh. I did then get errors for not implementing it in my Effect and TextureBase resources.

[Edited by - DrGUI on October 17, 2004 3:50:29 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by CpMan
Can you post code for the override?

Sorry, as I put in the edit of my post, I forgot to keep the code, but it was something like:

VideoResourceItemBase:

public abstract void OnOnInvalidate();

Mesh:

public override void OnOnInvalidate()
{
//Invalidate mesh
}

I hope that helps, sorry.

Share this post


Link to post
Share on other sites

This topic is 4807 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this