very odd... _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

I get the assertion _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) right after I get done splitting some polys in the mapper I am working on. I suppose I can start cutting out code, and I will, but I figured I’d ask here if anybody knew what was going on. This is very strange. MSVC++ docs say:

CAUSE
The CWinApp destructor in MFC included with Visual C++ 4.2 and 5.0 now frees the data assigned to the member variables shown above by passing the pointer to the free() function. Doing this prevents memory leaks, which would occur if an MFC regular DLL were dynamically loaded and unloaded.

But this is WAAAAY off the mark. Im currently using a console app for the mapper (and will turn off the console later), and I intend for the program to be cross platform compatible so I don’t have any “windowsisms” in my code, not even Hungarian Notation. Oh, yeah, and I thought it would be worthwhile to mention that I am using GLFW for the system oriented stuff.

Thanx for your assistance

Rob

[This message has been edited by 147-2 (edited 02-09-2003).]

It simply means that the memory that is being free’d has already been free’d. Or it could mean that the pointer to the memory is from another heap.
Are you allocating memory in one DLL/exe and freeing it in another DLL/exe?
Anyway, this is a standard compiler error - so why post the question in the Advanced OpenGL Discussion & Help forum? Is this the only newsgroup you know of? If so, then may I suggest you go to http://www.google.com/ and then into the “Groups” tab. From there you’ll find lots of newsgroups which will be more relevant to your question than this OPENGL newsgroup.

Ah, because all of the documentation concerning this error had to do with something quite specific- dealing with how certain Windows components interact… Which is 180 degrees off from what I was doing, so I figured I’d ask in the place where people understand the coding I HAVE done, which is 99.999% Open GL.

Turns out there was a delete that snuck into the code in a place I didnt expect it to. I copied a container, when the copy destructed, it deleted a ptr that I had. Ive never seen a segfault do THAT before.

[This message has been edited by 147-2 (edited 02-09-2003).]

Your code is 99.999% OpenGL? What does it do besides draw triangles?
What do you mean by “people here understand the code you HAVE done”? They understand what variables your apps contain? they understand every single malloc you do? Without actually seeing any code?
You paste all your compiler errors to this newsgroup do you? If you do, then I’m sorry - these people obviously have much more tolerance than I’m giving them credit for.

I don’t mean to be nasty, it’s just that your answer is certainly not good enough to justify your original question, in my opinion.
It’s all to do with context, you see…but then again, my “look at this Flash stuff” post isn’t much more appropriate.

You have something in your program which corrupts the memory heap of your process.

You can use a tool like Purify to find exactly where it happens. If it’s always the same location (check in the debugger) you can also use a data breakpoint to figure out where it gets modified.

Double-free, or too small allocation, or sloppy memcpy/memset usage are the most common causes for this kind of problem.

Yes I found it. It turns out I had a container class that was being passed by value, with a “standard” copy constructor operating at the function call. This caused the class, upon closure of the function to call its destructor. It contained a block of data that therefore got deleted. This deleted data was yet again deleted when the original container was deleted at the end of the loop. Don’t delete a deleted object :stuck_out_tongue: It is strange that I didnt just get a regular old exception. That is what I don’t understand at this moment.

Hmmm… there was a reply that stated a general un-knowlege about the code that I have written. I have seen a lot of people post about problems here and get working answers, regardless of what the problem was, and usually regardless of a general lack of knowlege of their code. If I use ANSI functions like fprintf() maybe I dont need to talk about that, especially if it has nothing to do with what part of the code is causing problems. I was getting a problem I had never seen here, and didnt look like any memory exception to me. I was just wondering whether anybody else had ever run into that little problem, thats all.

Rob

[This message has been edited by 147-2 (edited 02-10-2003).]