Jump to content
  • Advertisement
Sign in to follow this  
Boder

Visual Studio Broke, Pissed At C++

This topic is 3881 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

This just may be it. Those magical unknown bugs that pop up and vanish for no reason...yeah. So I was making a lot of changes to a project belonging to another person, and the heap started crapping out on me. I got a little panicky, but I changed back everything, manually. Clean, rebuild, clean, rebuild. No luck. Then I used SVN revert. Now everything is exactly as it was before. I deleted all the little user files that VS creates and cleared the Application Data folder. I restarted the computer. I rebuilt. And the heap crapped on me again. This is what it's giving me.
---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!

Program: ...
File: dbgheap.c
Line: 1279

Expression: _CrtIsValidHeapPointer(pUserData)

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
---------------------------
Abort   Retry   Ignore   
---------------------------
//from here
SDL_free( final->pixels );
Before I randomly got incompatible iterator types when i changed
//this
	for( SpriteList::iterator itr = objects.begin(), itr_end = objects.end(); itr != itr_end; ++itr )
	{
		(*itr)->Update();
	}
// to this
	for( SpriteList::iterator itr = objects.begin();
                itr != objects.end();
                ++itr )
	{
		(*itr)->Update();
	}

It just doesn't make any sense. Add to that the annoying LIBCMT and MSVCRT defaultlib messages (is there any way to find out what library is doing this). Furthermore this project has every single file including every single header, making compiling take forever. That's why my strategy was to change as much as possible before building and debugging (which is the worst possible strategy). I wanted to fix that problem, but there are like 50 cpp files and each one includes a header, that includes another header, and another and they all include the master global, so I never know which headers a file needs. DAMMIT. Spent hours trying to fix it, got the heap corruption, and now it's all reverted. I think it's time for game maker.

Share this post


Link to post
Share on other sites
Advertisement
Things might go screwy if any of the update functions of the objects there are modifying the container you're iterating through.

Share this post


Link to post
Share on other sites
I forgot to add that at the same time, Visual Studio stopped being able to tell that the project was up-to-date before debugging and kept asking "Do you want to build it?"

After I restarted I turned off my anti virus program too. I'm figuring it's a C runtime corruption from a hard drive error. Or a random collision of bits precisely colliding based on time and spatial factors causing an antimatter rift in the computer's essence.

Share this post


Link to post
Share on other sites
Hmmmmmm fragile.

Compiling the release version, I have to ignore LIBCMT, but in the debug version it just gives two warnings, no errors.

Running the release version is fine.

Then suddenly running the debug version is good.

This is the exact same code. Normally it's the debug version working and the release failing.

Share this post


Link to post
Share on other sites
You shouldn't have to be ignoring library. Doesn't SDL request that you use the [Debug] Multithreaded DLL build of the CRT?

Share this post


Link to post
Share on other sites
I got this on some of my code... but at least VS tells you you have a heap error (usually, dev-cpp gdb is less than helpful :P)

It's just one of Microsoft's little bugs that they'll never get round to fixing :S

Share this post


Link to post
Share on other sites
Yep I'm using that for SDL, so I wonder what library is causing the trouble.

Libpng and zlib statically. So either CEGUI or Boost.

It uses boost filesystem and I used the installer for VC2005, but I don't know how it gets linked because it's not part of the project settings that I can see.

Is this a problem with a static or dynamic library? Can a program use DLLs that each use different runtimes?

And now it likes to crash on me when I'm adding files to the project - don't really see how it's stable enough for a professional environment. At least when it crashes it keeps running and you can save and quit. It's weird that it can't just handle the exception and keep running.

Share this post


Link to post
Share on other sites
Quote:
Original post by Boder
Can a program use DLLs that each use different runtimes?


Yes, I believe so. You'll be wanting to check the things that you're linking statically to.

There's an option in the linker settings, I believe, to display how it searches libraries for symbols - might help you figure out which library is pulling in the wrong runtime. Failing that, just build them from source yourself.

Share this post


Link to post
Share on other sites
Quote:
Original post by Boder
Furthermore this project has every single file including every single header, making compiling take forever. That's why my strategy was to change as much as possible before building and debugging (which is the worst possible strategy).


Add all the includes into stdafx.h instead and just include that in all the source-files. Precompiled headers is a good thing.

Does it run as it's supposed to when it's reverted to original? Did it run as supposed before you started changing stuff?
You seem to have an overrun buffer somewhere, overwriting a heap pointer, considering it crashed when it tries to free the SDL framebuffer.
I use Boundschecker for things like this. It's quite expensive, but i'm sure there are free alternatives. Isn't there a build option to check for overruns?

Share this post


Link to post
Share on other sites
I guess it is corrupting the heap, but the release runtime doesn't mind it or something.

For the record, it's freeing a normal SDL_Surface's pixels and not the framebuffer. It was strange to me.

I'll ask the project lead to see if he can replicate the error, because he has probably never started out clean with a debug build before.

And it was surprisingly hard to find heap debug tools, I think it is a case of you get what you pay for.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!