In c++, how to catch if memory of the buffer is full so that to avoid the crash of the application.
Printable View
In c++, how to catch if memory of the buffer is full so that to avoid the crash of the application.
Which buffer ?
Means how to catch buffer overflow :-)
WHAT BUFFER?Quote:
Originally Posted by tonagu
Keep a count of the number of elements written to the buffer. When you reach the buffer limit, stop.
How u count the buffer memory ?
Buffer here means "stack memory "
So what will your application do if the stack memory is exhausted? Call another function? (which is impossible, since the stack is exhausted). Once the stack memory is gone, you're finished -- the application is supposed to crash.Quote:
Originally Posted by tonagu
Maybe you can code a structured exception handler to report the crash a little better, but the application still crashes.
Regards,
Paul McKenzie
Hi,
Have a look : here.
In this thread you'll find code to handle the stack overflow exception.
And in my test case: It worked fine.
But I want to recommend to carefully re-think your strategy anyway: As Paul McKenzie wrote: If there isn't any stack available it is hard to do anything senseful. But it is still possible to return from a recursive function and tell the user something like: "Sorry, I wasn't able to solve your (math) problem, but I tried really hard.".
With regards
Programartist
Ingo Bochmann
I have another question related to this:
Are there any facilities for generating an interrupt when a specific memory address is written?
For instance, if I have a vector class in which I add one element at a time and want to enter an interrupt routine when I write outside the allocated array. In this interrupt routine I need to reallocate the array to avoid a crash.
The purpose would be to avoid having to check the bounds on each write, thus increasing performance slightly.
I know a debugger can "break on memory write", but I suppose there is quite an overhead in using this technique. How does the debugger accomplish this?
Do you really think that 1 'if' statement is gonna matter ?Quote:
The purpose would be to avoid having to check the bounds on each write, thus increasing performance slightly.
Don't u know processors have a hard time optimizing conditional branching :DQuote:
Originally Posted by Skizmo
That if statement may be >50% of the execution time in my vector.add() function.
Insert a billion elements on a machine with infinitely fast memory subsystem and there will be a measurable difference...
Why not just fix the code?Quote:
Originally Posted by zerver
There are many functions that tell you the current size of the vector before you write to it.
My opinion -- you're not going to gain anything from doing this, and secondly, writing outside the boundaries of a vector is undefined behaviour. There is no guarantee that the code will crash.Quote:
The purpose would be to avoid having to check the bounds on each write, thus increasing performance slightly.
Edit:
I see that you're talking about your own class. Then why not just allocate the memory right from the start?
Regards,
Paul McKenzie
Well, I don't have to write outside the array. If I can catch the write to the last allocated memory address, I can reallocate from there.
So, I would still like to know how a debugger is able to catch "write to memory location X".
Regards / Z
Hopefully you realize that this slows down your application.Quote:
Originally Posted by zerver
Regards,
Paul McKenzie
Well, I can't realize something if I have no idea about how it's implemented. But you are right that I strongly suspect there is a penalty - otherwise it would be in widespread use among performance freaks such as me :cool:
Yeah, but I don't think you have a billion elements, and I don't think you have infinitely fast memory, so .. who cares :DQuote:
Insert a billion elements on a machine with infinitely fast memory subsystem and there will be a measurable difference...
Check out Creating Guard PagesQuote:
Originally Posted by zerver
The way a debugger may implement 'break on memory write' is as followsQuote:
Originally Posted by zerver
1. Set the memory protection on the (virtual memory) page of interest.
2. Trap the interrupt that is generated.
3. Check if the specified memory address has been written; if yes break; else continue.
I do not know if any CPU mechanism that can break on a specific memory address write. Breaking on a page basis is possible. This I suspect is the reason why 'break on this memory write' is not practically feasible - the thing would cause an interrupt on write to any of the memory addresses on that page and some other piece has to then check if the accesses memory is what someone wanted to be interrupted about; even with small page size (say 2K) that may be costly.
Ah, excellent. Many thanks!
This means that if you always make sure to allocate at least two pages more than you currently need and then set up the memory protection accordingly, this technique could actually be used to reallocate a growing array.
And if I understand correctly, performance will not be negatively affected in this case since no other code will write to the protected page. When the interrupt is triggered you disable the protection, reallocate and finally protect the new page.
At least the technique is interesting from a technical standpoint.