char* text = new char[CHAT_LINE_WIDTH];
sprintf( text, "Say: %s", m_pCurrMsg );
m_pArial18->DrawText( 300, SCREEN_HEIGHT - 175, CHAT_COLOR, TEXT( text ) );
delete [] text; // Crashes here
User breakpoint called from code at 0xblahblahblah
Author
Over the course of developing my game, I have run into this error/crash/annoyance many times. What does it mean? All I know is that my game is breaking into directx code and I have no idea what is going on.
The following code is the latest culprit:
The delete is what is crashing the game. Maybe I''m just tired after a long day, but I don''t see anything wrong with that code. I copied and pasted it from somewhere else in my game that was working so what''s going on? How can I eliminate or recover from these damn "user" breakpoints?
where exactly is the breakpoint? from the information you''ve provided, you''re most likely corrupting memory with your font class.
Author
Well, I'm using the font class that comes with some of the samples in the dx8sdk so if that's broken...
What happens is that it breaks into some disassembly code. If there's a breakpoint, it isn't mine and I don't see it. My call stack window looks like this:
NTDLL! 77f97704()
NTDLL! 77fced7c()
NTDLL! 77fb6695()
NTDLL! 77f935f9()
KERNEL32! 77e9dff9()
_CrtIsValidHeapPointer(const void * 0x04d3e8f8) line 1697
_free_dbg(void * 0x04d3e8f8, int 1) line 1044 + 9 bytes
operator delete(void * 0x04d3e8f8) line 49 + 16 bytes
UI::Render() line 170 + 15 bytes
.....
Usually I'm not so lucky. It generally will only show NTDLL! and some hex.
wtf
[edited by - beoch on November 5, 2002 12:47:18 AM]
What happens is that it breaks into some disassembly code. If there's a breakpoint, it isn't mine and I don't see it. My call stack window looks like this:
NTDLL! 77f97704()
NTDLL! 77fced7c()
NTDLL! 77fb6695()
NTDLL! 77f935f9()
KERNEL32! 77e9dff9()
_CrtIsValidHeapPointer(const void * 0x04d3e8f8) line 1697
_free_dbg(void * 0x04d3e8f8, int 1) line 1044 + 9 bytes
operator delete(void * 0x04d3e8f8) line 49 + 16 bytes
UI::Render() line 170 + 15 bytes
.....
Usually I'm not so lucky. It generally will only show NTDLL! and some hex.
wtf
[edited by - beoch on November 5, 2002 12:47:18 AM]
My guess is m_pCurrMsg is bigger than (CHAT_LINE_WIDTH - 6), and you''re overwriting the debug info stored at the end of the heap block.
(and by bigger I mean either a longer string, or not null terminated, or something of that ilk.)
-scott
(and by bigger I mean either a longer string, or not null terminated, or something of that ilk.)
-scott
I had the same kind of trouble. Check the debug setting in the Direct Control Panel Applet. Then, run the app in the debugger and you will probably see Direct X breaking and some useful info in the debug spew.
Laurent
Laurent
Author
Well, I see lots of spew but nothing really useful. 
I am pretty sure from the output (ie: HEAP[Multiplayer.exe]: Heap block at 04DB57C0 modified at 04DB59F8 past requested size of 230) and the above suggestions that I am somehow overwriting the debug info or something like that. But I don't know how that could be happening. I've done this same thing a million times before in console apps and the like with no problems. Direct Input seems to be screwing me somehow. I think I'm going to change my whole approach and use strings or something like that instead of char*'s. This is too irritating.
[edited by - beoch on November 8, 2002 8:05:04 PM]
I am pretty sure from the output (ie: HEAP[Multiplayer.exe]: Heap block at 04DB57C0 modified at 04DB59F8 past requested size of 230) and the above suggestions that I am somehow overwriting the debug info or something like that. But I don't know how that could be happening. I've done this same thing a million times before in console apps and the like with no problems. Direct Input seems to be screwing me somehow. I think I'm going to change my whole approach and use strings or something like that instead of char*'s. This is too irritating. [edited by - beoch on November 8, 2002 8:05:04 PM]
What I would do is try to pinpoint the problem by changing the code around. For example, you could:
1.) Comment out the call to DrawText and see if it happens again.
2.) Try displaying the text in a messagebox or printing it to file instead of drawing it.
3.) Remove the variable from the text by commenting out the sprintf and using strcpy (text, "hello world"); and see if that makes it crash.
Hope that helps.
1.) Comment out the call to DrawText and see if it happens again.
2.) Try displaying the text in a messagebox or printing it to file instead of drawing it.
3.) Remove the variable from the text by commenting out the sprintf and using strcpy (text, "hello world"); and see if that makes it crash.
Hope that helps.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
