Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

kirkd

"User breakpoint called..."

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

I''m using VC++ and doing a bit of dynamic memory allocation. Occassionaly, a "new" operator in a particular function will result in an error box stating "User breakpoint called...blah blah", however, this same function works correctly most of the time. Any ideas? BTW, this error pops up when in DEBUG mode. -Kirk

Share this post


Link to post
Share on other sites
Advertisement
Thanks for the quick reply.

As for sizes, I''m allocating a double with this line:

double *newValue = new double;

Do I have a choice in sizes here?

-Kirk

Share this post


Link to post
Share on other sites
It actually breaks inside one of the standard source files (MS) as a result of calling the new operator to allocate a double. Is it possible that if I have a nasty memory leak, the computer is running out of memory? I''m aware of a small memory leak and I hope it isn''t that drastic!!

-Kirk

Share this post


Link to post
Share on other sites
The code you posted
> double *newValue = new double;

only allocates a single double, you are only accessing a single values aren''t you...

> Do I have a choice in sizes here?
Yes, double *newValues = new double [42];

not forgetting that you need to "free newValues []"

Share this post


Link to post
Share on other sites
Yep, a bit of clarification might be required. Here''s some more code, this time for the entire function.

void Observation::AddDescriptor(double descriptorValue)
{
double *newValue = new double;
*newValue = descriptorValue;

descriptors.push_back(newvalue);
}

Note that descriptors is declared as:

vector descriptors;

and serves as a vector of pointers to doubles. Say that 10 times fast!

This function gets called hundreds of thousands of times over the life of my program and most of the time it works just fine. On very rare occassion, however, I get the error coming from some MS standard code but ultimately traceable back to the first line where *newValue is allocated.

So, in response to Beelzebub, I''m not trying any pointer arithmetic but rather use the pointer to access the value stored within it. Good point on the dynamic allocation of an array, however, I''m not hitting this as an array.




Share this post


Link to post
Share on other sites
if you don''t use the pointed to double for anything else then you could just have a vector of double rather than double*

vector<double>

then you wouldn''t have to delete them all either (you are deleting them aren''t you)

Beezelbub: that should be delete not free. if you use new to allocate you should use delete to deallocate. free should only be used with malloc.

Share this post


Link to post
Share on other sites
Well, for right now, I''d suggest walking back up the stack if your compiler allows you to do so, and see where in *your* code things start to go haywire, because I assure you the underlying code from MS isn''t the problem.

Memory leak is possible. Does it always happen after a certain length of time? Does the memory leak you''re aware of get worse if you shut down before you hit the user breakpoint?

-fel

Share this post


Link to post
Share on other sites
Petewood: I used the pointer because I didn''t know how many I would have to start with. Once I step out of the function will a non-pointer double which has been pushed into the vector still exist without any problems once the function exists? And, yes, I am deleting the pointers sequentially before poping them out of the vector in the destructor.

Fel: Yep, I''ve walked up the call stack from the MS code. I''m certain you''re right and the standard code isn''t the problem, it''s just the symptom. When I walk back up it always originates from that "new" statement. Regarding the potential memory leak issue, it isn''t predictable. Sometimes it happens soon sometimes late.

Odd, eh?

-Kirk

Share this post


Link to post
Share on other sites

  • 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!