Re: Problem with std::vector bounds checking in VS 2005
sdiverdi schrieb:
On Oct 3, 10:44 pm, Norbert Unterberg <nunterb...@newsgroups.nospam>
wrote:
Your porblem is not the bounds check but how the runtime library handles the
asserts. What basically happens is that the assert call shows the dialog
allowing you to hit abort, retry or cancel. Problem is that this does not halt
the application, only the current thread, and for GUI apps it is even worse
because that dialog contains its own message loop letting even the current
thread continue to run. This can mess up the logic of your application,
generating additional failures in unrelated pieces of code, or even run into the
same assert recursively.
Hmm, okay. I don't explicitly create any threads in this program -
are separate threads still a concern in this case?
It could be if your framework creates "secret" helper threads in the background.
The solution depends on what type of application you are worling on: GUI or
Console. There are some API functions to change the default behaviiour. Have a
look at _CrtSetReportMode or _set_error_mode for a start.
Looking at my project settings, I see that subsystem is unset (not
console or window), but I don't get a text console when I run in
visual studio, so I had assumed it was a GUI application. This is
with wxWidgets for the GUI, if that makes a difference.
So it is a GUI application. I was asking because the runtime library contains
different code paths for the different application types (like printing the
"assertion failed" message to the console for a console application)
Looking at _CrtSetReportMode's documentation on MSDN, I see that it
says the default behavior is "Assertion failures and errors are
directed to a debug message window." which is what I want and what I
guess I'm experiencing. For _set_error_mode, the default behavior on
assert seems to be a message box w/ abort, retry, or ignore buttons,
which again is what I'm getting and what I want.
In most cases I would be interested in the first failur cause and have the
application stop on the first assert ever. To do this, I set a break point on
the assert function itself. Either load the crt\src\assert.c file in the
debugger and set a breakpoint on the opening brace of the function _assert or
_wassert, or just write an assert(false) at the beginning of your function,
select the retry button, and locate _(w)assert on the call stack.
You do have the runtime library source code installed, don't you?
I'm not sure what you mean by putting assert(false) at the beginning
of "my function" - I'm talking about detecting out of bounds errors
within an entire program here. I can't just step through the entire
program, esp since it's interactive and the errors depend on
interactive behaviors.
I meant putting an assert(false) at the beginning of your application. This is a
reliable way to force an assertion failure without any any threads or GUI
handlers in the background, giving you a chance to hit "retry" and letting the
debugger point you to the assert() source code (if you have installed one). This
enables you to find the place to set a breakpoint without manually browsing
through the RTL source codes.
I don't have the runtime library source installed. I guess I could do
that and put a breakpoint on assert, but that really seems to be
overkill - there isn't a way in visual studio to simply have it break
on assert? This seems like pretty basic functionality to want in an
IDE. I guess if there's no easier way, this is what I'll have to do,
but I had hoped for something like a debug setting I needed to fix.
I had looked for a easier solution like you ask for, but I have not found one.
THat's why I suggested manually setting the breakpoint. And this is one of the
few cases where having RTL sources installed would help. GUI apps with MFC
virtually requires having the MFC sources installed (because without them you
would not see the causes of the many ASSERTion failures you get).
Norbert