Sign in to follow this  

How to stop "Break called from code".

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

Apparently somewhere a break is being called in my code. I have no clue when or where it is set but it's there everytime I run. The funny thing is that it doesn't stop on a code line, it stops on some assembly line. I'm not even sure if it's invoked by me since my only code that called for a break is commented out. Does anyone know how to find such a line? I'm using VC++ 6.0. Thanks. ~Wave

Share this post


Link to post
Share on other sites
I tried that AP, and ended up at a line in the code that really didn't help much. The problem is that breaks called from code from a line such as: _crtsetbreakalloc(321); don't really tell you exactly where the break is coming from since they are set at run time.

~Wave

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
_crtsetbreakalloc(321);
is that line is in your code?

Share this post


Link to post
Share on other sites
Quote:
Original post by Wavewash
I tried that AP, and ended up at a line in the code that really didn't help much. The problem is that breaks called from code from a line such as: _crtsetbreakalloc(321); don't really tell you exactly where the break is coming from since they are set at run time.

~Wave


The stack didn't lead up to a line of your own code? Is it happening at start-up/close or something? And when you say break, do you mean an actual breakpoint?

Matt Hughson

Share this post


Link to post
Share on other sites
I meant to say that it's breaking in a system dll. NTDLL seems to be the culprit. I have no idea why it is doing that though. At this site they mention how to handle system dll breakpoint issues. I don't understand it or if it applies to my problem.

Quote:
Original post by Anonymous Poster
And I apologize for being tasty


It's cool, I'm just happy to get a reply.

~Wave

Share this post


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

The stack didn't lead up to a line of your own code? Is it happening at start-up/close or something? And when you say break, do you mean an actual breakpoint?

Matt Hughson


If I move back up the stack far enough it comes to my code where I deleted an array. The breakpoint called from code acts just as a regular breakpoint would but since it is called from code no stop sign is there. It just stops on whatever line. If I keep running through it by pressing f5 I get no issues and it completes executing with no issues.

~Wave

Share this post


Link to post
Share on other sites
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. Then the _crt.. functions crashed when checking for memoryleaks (kind of funny since that is what they are for, MS bug perhaps?) In any case, I allocated correct amount of memory for the data (I just happened to *know* which one, in your case it might be more difficult) and the problem went away. I don't know if this is of any help for you though.

Share this post


Link to post
Share on other sites
Thanks MichealT, this is my first time encountering this sort of thing. I'm looking through my code, I think it's probably something the compiler is getting picky about. Thanks for the tip though.

~Wave

Share this post


Link to post
Share on other sites
[quote]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.[quote]

I owe you a beer or a rootbeer. Same issue that you had. Thanks!

~Wave

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by MichaelT
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.
The 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.

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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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. :)

Share this post


Link to post
Share on other sites
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));

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:

use sizeof() instead of strlen() for better results


It's late so maybe I'm missing something but won't sizeof(dest) usually be the size of a pointer(4 on x86) since dest will be of type char*? That means the macro will not work right if you use sizeof instead of strlen.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nurgle
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));

This really isn't a good idea. If you don't know what the destination buffer currently contains, you can't expect strlen to return its size. Nothing guarantees the buffer is null-terminated (and you can't do destBuffer[destSize-1] = '\0', since there might be a '\0' somewhere else in the buffer, in which case strlen will return a value smaller than the buffer's length).

What you can do:
1. Use std::string.
2. Dynamically allocate the destination buffer (strlen(srcBuffer)+1), and then copy (both strcpy and strncpy will work fine in this case).
3. Use a fixed-size destination buffer, and use strncpy(dest, src, destSize-1). However, in this case, you might truncate some of the string you're trying to copy. Also, note that in this case you must manually set the last byte of the destination buffer to '\0', since strncpy might not do it if the source string is too long.

Share this post


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

This really isn't a good idea. If you don't know what the destination buffer currently contains, you can't expect strlen to return its size. Nothing guarantees the buffer is null-terminated (and you can't do destBuffer[destSize-1] = '\0', since there might be a '\0' somewhere else in the buffer, in which case strlen will return a value smaller than the buffer's length).


See my second post



clicoder:


I wrote a small test app which does sizeof on a char[20], and it works fine (using gcc).

Share this post


Link to post
Share on other sites
Quote:
Original post by MichaelT
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.


No, it really is your fault. The crash in the CRT is because you're doing *something* wrong with memory. Either writing to memory that doesn't belong to you, or overwriting the end of an array or something.

I know it seems strange that the crash is outside your code, but if the CRT was bugged so badly it would have been fixed by now.

Then again, you're using the latest VC6 service pack, right?

Share this post


Link to post
Share on other sites

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