Original post by MichaelT
I got a similar error just last night, in my case it was simply because I released memory that contained data that was overflowing the memory.
I owe you a beer or a rootbeer. Same issue that you had. Thanks!
~Wave
How to stop "Break called from code".
Its not a crash, its an assertion failure. Its the CRT letting you know that theres a bug in your code. If it didn't do this, then it would either crash, or you could get some very nasty and extremely hard to track down bugs later on.
Quote:Original post by Evil Steve
Its not a crash, its an assertion failure. Its the CRT letting you know that theres a bug in your code. If it didn't do this, then it would either crash, or you could get some very nasty and extremely hard to track down bugs later on.
Actually, in my case, it really was a crash not an assertion failure.
Just to complete the thread here's what the problem and solution was. I was doing something fairly stupid in a number of places in my code. The break from thread only came when I moved to XP.
I had a char* storing the path to a texture. And I wanted to transfer it to a another char*. So here's the mistake I made
temp->filename=new char[256];
strcpy(temp->filename,filename);
Now this seems fairly harmless. But the problem was, and I'm sure you can guess, that when the filepath was longer then 256 characters as some desktop paths are it would write past the bounds of the array. Then when I would release the array it would only release what I had allocated leaving some trash in the memory that would get overwritten and cause a breakpoint called from within the code.
Moving from win98 to XP brought out this problem because on WinXP the path is
C:\windows\documents and settings\username\game\blah.ext
while in win 98 it was
C:\windows\desktop\game\blah.ext
fitting easily into my array.
To resolve the issue I just made the size of the char array larger. Although I'm thinking that I probably should've gone with a better solution like:
temp->filename=new char[strlen(filename)];
strcpy(temp->filename,filename);
to make sure my char array is long enough. Some of the C++ masters here can probably comment on that. I will probably go towards a solution like this when I get time to change all the code.
Anyways, thankyou all for the help. And MichaelT for setting me in the right direction.
~Wave
I had a char* storing the path to a texture. And I wanted to transfer it to a another char*. So here's the mistake I made
temp->filename=new char[256];
strcpy(temp->filename,filename);
Now this seems fairly harmless. But the problem was, and I'm sure you can guess, that when the filepath was longer then 256 characters as some desktop paths are it would write past the bounds of the array. Then when I would release the array it would only release what I had allocated leaving some trash in the memory that would get overwritten and cause a breakpoint called from within the code.
Moving from win98 to XP brought out this problem because on WinXP the path is
C:\windows\documents and settings\username\game\blah.ext
while in win 98 it was
C:\windows\desktop\game\blah.ext
fitting easily into my array.
To resolve the issue I just made the size of the char array larger. Although I'm thinking that I probably should've gone with a better solution like:
temp->filename=new char[strlen(filename)];
strcpy(temp->filename,filename);
to make sure my char array is long enough. Some of the C++ masters here can probably comment on that. I will probably go towards a solution like this when I get time to change all the code.
Anyways, thankyou all for the help. And MichaelT for setting me in the right direction.
~Wave
Quote:Original post by MichaelTThe breakpoint you see means that you execute (assuming x86) the assembly instruction "int 3", which is fatal outside the debugger. Thus you won't see an assertion, but really "crash" causing the process to terminate.Quote:Original post by Evil Steve
Its not a crash, its an assertion failure. Its the CRT letting you know that theres a bug in your code. If it didn't do this, then it would either crash, or you could get some very nasty and extremely hard to track down bugs later on.
Actually, in my case, it really was a crash not an assertion failure.
This is a typical indication that either the CRT has detected a bug, or that the that compiler has generated "safety blocks" around your code containing int 3 instructions, and that now gets executed, which clearly is due to a bug.
Quote:Original post by Wavewash
...
temp->filename=new char[strlen(filename)];
strcpy(temp->filename,filename);
to make sure my char array is long enough.
...
that's the idea, however.. it's also still buggy. if filename is , say, 13 chars long, then temp->filename must be 14 chars long; 13 for the length of filename plus one for the terminating null char.
you can (and very well _should_) avoid all this stupid shit, by simply using std::string ... it's far less error prone. :)
Quote:Original post by Wavewash
To resolve the issue I just made the size of the char array larger. Although I'm thinking that I probably should've gone with a better solution like:
temp->filename=new char[strlen(filename)];
strcpy(temp->filename,filename);
Actually, no. What you should ALWAYS, ALWAYS, ALWAYS do when copying from one memory address to another is this:
strncpy(temp->filename, filename, strlen(temp->filename));
This completely destroys the possibility of a buffer overflow. In your code above, it's redundant, but still a good habit to get into.
If you find yourself not doing the right thing out of habit, you could always hack together a quick macro...
#define strcpy(dest, src) strncpy(dest, src, strlen(dest));
Quote:Original post by Nurgle
#define strcpy(dest, src) strncpy(dest, src, strlen(dest));
Thanks for the tip, I'm using that macro now.
~Wave
be warned... that macro isn't very good (like I said, a hack). use sizeof() instead of strlen() for better results (wasn't thinking when I wrote it).
Quote:Original post by Anonymous Poster
....which clearly is due to a bug.
I've tracked down the crashpoint to a location to a loop inside the the _crt.. function. ;) But thanks for the heads up.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement