Re: Error meaning in STL
SteveB wrote:
We are currently running scalabilty tests using LoadRunner and have 30
concurrent users. We have isolated the problem to a single section of
code but it becomes more problematic as the section of code is
inherited and could be called from different areas.
Sorry to sound so vague but we are still testing - what I really wanted
to know was if the problem was more likely to be hardware related or if
the fact the internal STL functions were causing the problems.
Typically, I'd expect sys-internal functions to be multithreading-safe and
MP-safe, in case you have multiple CPUs, but the more CPUs you have the
less tested this probably gets and errors happen.
What I would try is to replace the standardlibrary in order to rule out its
influence. You could either do just that, using e.g. STLport or a newer
Dinkumware lib, or upgrade to VC8 which also includes a newer Dinkumware
library. In both cases, you get a diagnostic mode (compile-time switch)
that does some additional checks. As example, using an invalid index into a
string yields undefined behaviour according to the standard (in order not
to tax correct code with the overhead of checking) but those checked
standardlibs catch such errors at the price of being slower.
What is kind of worrying is that the exception handling we use is not
trapping the errors.
Well: if you try to catch an access violation with a "catch(std::exception
const& e)" you are out of luck anyways, this is not a C++ exception! You
can catch it with "catch(...)" but that only works with some MS Windows
compilers (AFAIK) and is generally non-portable. IMHO it also rather serves
to hide than to discover and fix bugs.
In terms of the environment we have replicated this on multiple app
servers, all runngin Windows Server 2003 and SQL Server 2005.
In fact I rather meant the environment you compiled with. After all, there
is a dozen of MS compiler[version]s out there that are actively used.
good luck!
Uli