Archived

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

"User breakpoint called..."

This topic is 5505 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
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
quote:
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


Yes, if ''desciptors'' is a member of the Observation class then it will exist until the Observation object is destroyed. Anything you''ve pushed back into it will be kept. The vector will resize itself to fit however many doubles you push into it. You could equally use a deque (double ended queue) if all you''re doing is pushing and popping. A stack would be best. However there isn''t one in vc++6.0 stl. There are in gcc and stlport I believe)

peace

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
i had this error once, and it dogged me for hours ''cause i had never gotten it before.

turns out i was overrunning an array that had been allocated just above the var i was getting the breakpoint on, not overrunning the var''s buffer itself.

Share this post


Link to post
Share on other sites
Hmmmm...that is interesting....maybe I''m accessing something that''s been deleted (dynamic allocation and deleted) and it''s crunching into this code...hmmmm.....


Share this post


Link to post
Share on other sites
petewood: yep you''re correct, a drunken typo. delete is diffenently the way forwards.

No more thoughts on why you''re getting the runtime error. But a thought on speed... new and delete have a large amount of overhead, if you''re calling the functions "hundreds of thousands of times" you''d be better off allocating hundreds (or thoudsands) of your base type in one go and having a simple method of determining if each element is in use (a structure of bool used and double value) - have a look at how particle code handles this.

Share this post


Link to post
Share on other sites
Thanks for the tip. I didn''t realize new and delete were so costly. I haven''t noticed any problems with speed, thought. Whew!!

-Kirk

Share this post


Link to post
Share on other sites
quote:
Original post by Beelzebub
No more thoughts on why you''re getting the runtime error. But a thought on speed... new and delete have a large amount of overhead, if you''re calling the functions "hundreds of thousands of times" you''d be better off allocating hundreds (or thoudsands) of your base type in one go and having a simple method of determining if each element is in use

The obvious way of doing this would be to use a standard container, such as std::vector, and to reserve however much space you think you will need. Using vector in conjunction with boost::shared_ptr would probably have done the job without the OP ever encountering the problem he now has.

Share this post


Link to post
Share on other sites