Dtrace for memory overflow? - c++

I want to write a Dtrace so that i can analyse if overflow_error is happening in a process
i am executing . I just know that this is an error thrown as std::overflow_error. I don't have much idea about how to write a D-Trace . I need some beginner guide and if someone can let me know how to write it . The process name i am running is say superbug_returns . How can i write a D-Trace for it analyzing if above scenario is happening or not? I am working on solaris

It would be probably much easier to run the program in the debugger (dbx), and have it stop on thrown exceptions.

I second the suggestion to try the debugger with this - there's usually a command to break-on-C++-exception. It's simpler to go that way.
If you insist on DTrace:
A few years ago, Sun published a whitepaper how to use DTrace with C++ - read that.
It's not trivial to apply the techniques described there to the "trace exceptions" usecase, unfortunately, because exception throwing/handling is in the C++ runtime and done through internal (nonexposed) function calls. In gcc-compiled code, throw ... becomes __cxa_throw(...) whereas in SunStudio-compiled code (which uses a different name mangling scheme) a function (unmangled / mangled):
void __Crun::ex_throw(void*,const __Crun::static_type_info*,void(*)(void*))
__1cG__CrunIex_throw6Fpvpkn0AQstatic_type_info_pF1_v_v_
is called. Note that this depends on your compiler version; SunStudio changed their mangling scheme / C++ runtime at some point in the past. In both cases though, std::... would be passed as argument, so it you'd want to DTrace for a specific exception class only you'd need secondary filtering (a D probe predicate that tests whether the exception thrown is really the one you're interested in). You'd need to find out what args to the above function[s] correspond to std::overflow being thrown and filter for those.
Without your actual object file, I can't give more advice than that. For a start, try:
gcc:
dtrace -n '
pid<your-process-pid>::__cxa_throw:entry
{
#exloc[ustack()] = count();
}'
SunStudio:
dtrace -n '
pid<your-process-pid>::__1cG__CrunIex_throw6Fpvpkn0AQstatic_type_info_pF1_v_v_:entry
{
#exloc[ustack()] = count();
}'
to find places in your code where exceptions are being thrown (Ctrl+C to terminate the DTrace gives you the statistics). Then iterate from there (try to dump the args, see if you can identify std::overflow, filter for that by adding a /arg0 == .../ or similar to the probe).

Related

How can a CPtrList->RemoveHead() cause an CInvalidArgumentException?

This question is quite similar to this previous one, this time I'd like to get more acquainted with the subject, or at least with its documentation:
I'm dealing with a process crash, due to a CInvalidArgException, while performing a RemoveHead() of a CPtrList object, containing 6 entries.
The wrong piece of source looks as follows:
pSingle = (SET_PARAMETER*)plMultiple->RemoveHead();
The call stack is as follows:
mfc110u.dll!AfxThrowInvalidArgException(void)
mfc110u.dll!CObList::RemoveHead(void)
Application.exe!SingleThread(void * pArg=0x0000006800000000) Line 673
In order to understand what's happening, I'm having a look at the official Microsoft documentation website about CPtrList(CObList) RemoveHead(), but I don't find any reference towards a CInvalidArgException.
Just for a small comparison: for Java programmers, there's a documentation which explains every exception you might encounter while programming (e.g. Official documentation mentions all exceptions, which might be thrown while executing a method).
I'd like to know if there is something similar for C++ (STL) programmers?
Thanks in advance
Checking the source code for CObList we see that the first line is:
ENSURE_VALID(this);
This macro is defined as:
#define ENSURE_VALID(pOb) ENSURE_VALID_THROW(pOb, ::AfxThrowInvalidArgException() )
Which is in turn defined as:
#define ENSURE_VALID_THROW(pOb, exception) \
do { ASSERT_VALID(pOb); if (!(pOb)){exception;} } while (false)
In other words, it will cause an assertion in debug mode, and in release mode it will call AfxThrowInvalidArgException which is what you are seeing.
In short, plMultiple is null.

Is it possible to trap errors from C printf()?

I have a C++ program for which validated API users (not interactive users, so there is no major security/integrity exposure here) can pass a parameter that becomes a format string for printf() (actually, for vsnprintf()). Of course, bad format specifiers make the program blow up. I have documented that and it is acceptable -- but is there any way to trap printf() errors rather than having the C runtime assert?
Environment is pretty much standard Posix (z/OS XLC, FWIW).
Use sigsetjmp()/siglongjmp().
Call sigsetjmp() prior to using the potentially bad format, and install a custom handler for SIGSEGV and SIGBUS that calls siglongjmp() with the context from the sigsetjmp() call.
Just be sure to use restore the signal handlers after you don't need them lest a SIGSEGV somewhere else cause some unexpected results.
Example here:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/sigsetj.htm
Please see to BOOST format library - http://www.boost.org/doc/libs/1_58_0/libs/format/
The format library provides a class for formatting arguments according to a format-string, as does printf, but with two major differences :
format sends the arguments to an internal stream, and so is entirely type-safe and naturally supports all user-defined types.
You can use C++ exception with this library.
I was tempted to recommend a simple C++ style try/catch:
. . .
try
printf(...)
catch (...)
printf("An error happened handling your printf string!")
...
But I figure you tried that and have a reason why it doesn't meet your needs.
The deeper alternative is an LE Condition Handler - it's essentially a callback routine that gives you control any time an exception occurs, and it includes a way to resume execution after an error. Read more by Googling CEEHDLR or see the "Handling error conditions, exceptions, and signals" section of the XL C/C++ Programming Guide.
In a pinch, you can also wrap your calls to printf() with ESTAE/ESPIE macros to trap the error before the runtime sees it...yes, it takes a few lines of assembler, but many times it's possible to get way more granular this way.
Best of luck!
Answering title:
if(printf("...") < 0)
{
perror("printf error message");
exit;
}
Addition.
Working example
wchar_t wide[2];
wide[0] = 129;
wide[1] = 0;
if(printf("%ls", wide) < 0)
perror("detect error");

Am I allowed to throw an exception inside MPI-parallelized code?

These are some general questions I am facing while designing the error handling for an algorithm that is supposed to run in parallel using MPI (in C++):
Do Exceptions work inside code that is executed in parallel? Is the behaviour defined?
How do they work? Does that differ for different implementations?
Is it good practice - or should I use return codes?
In an ideal world, you can use them to do what you ask. By "ideal world" I mean one where you have your choice of MPI implementation and are able to administer it yourself (instead of convincing the cluster owner to reconfigure it for you). The minimal configuration for exceptions will include the: --with-exceptions flag, and possibly a few more.
I've used LAM most often, and by default exceptions are disabled. I believe this is the default for other implementations as well.
They work in the same vein as 'vanilla' C++ exceptions. And they do work inside parallel executed code.
At some point in your startup code, you want to enable them:
MPI::COMM_WORLD.Set_errhandler ( MPI::ERRORS_THROW_EXCEPTIONS );
(if your library isn't configured to allow exceptions, this is probably a bad idea -- behaviour "undefined" according to LAM)
And then:
try { /* something that can fail */ }
catch ( MPI::Exception e ) {
cout << "Oops: " << e.Get_error_string() << e.Get_error_code();
MPI::COMM_WORLD.Abort (-1) ;
}
As for it being good or bad practice, I can't really say. I haven't seen extensive use of them in code written by hardened MPI hackers, but that may be because the code is generally more C than C++ in my experience.
A middle ground between error codes and exceptions may be error handlers, in a nutshell you can assign functions that will be called when a particular error (designated by code) occurs. This might be an option if you can't get your administrator on board with enabling exceptions.
Exceptions work the same in an MPI code as with a serial code, but you have to be extremely careful if it is possible for the exception is not raised on all processes in a communicator or you can easily end up with deadlock.
MPI_Barrier(comm); /* Or any synchronous call */
if (!rank) throw Exception("early exit on rank=0");
MPI_Barrier(comm); /* rank>0 deadlocks here because rank=0 exited early */
All error handling methods have this problem, it is difficult to recover from errors that do not occur consistently across a communicator. In the case above, you could perform an MPI_Allreduce so that all ranks choose the same branch.
My preference is for calling error handlers and propagating them up the stack since this tends to give me tho most useful/verbose error message and it's easy to catch with a breakpoint (or the error handler can attach a debugger to itself and send it to your workstation in an xterm).
Whether or not exceptions will work during parallel execution depends on your compiler and MPI library implementation. If you want portable behavior, I'd avoid throwing exceptions in that context.
If you want more detailed information about errors than just a numeric return code, you can of course return and/or pass around error strings or other objects (within the same process or through MPI, of course).

Crashing C++ application including ada dll does not generate core dump

How do I get a C++ application including a loaded ada shared library to generate a core dump when crashing?
I have a C++ application which loads a ada shared library, inside the ada code I get a stack overflow error which causes program termination along with the console output:
raised STORAGE ERROR
No core dump file is generated even thou I have issued a "ulimit -c unlimited" before starting the application.
Same thing happens if I send a kill SIGSEGV to the application.
Sending kill SIGSEGV to another application that does not use the ada dll generates a core dump file just the way I want it to.
Found some information here: http://objectmix.com/ada/301203-gnat-fstack-check-does-work.html
UPDATED!
As mentioned by Adrien, there is no contradiction, -s sets the stack limit while -c sets the core file limit.
Still the problem remains. I checked the flags when building the ada library and the fstack-check flag was not set, so it should generate a core dump.
Althou I haven't tried it yet, it seems somewhat strange.
It mentions the -fstack-check compiler option + setting the GNAT_STACK_LIMIT variable but at the same time refers to the ulimit command which seems like a contradiction, setting "ulimit -c " is the only way I know of getting a core dump to be generated at the time of crash, if this infers with the fstack-check option then we have a catch 22.
Now, almost 2 years later (still working at the same company as Kristofer did when he asked the question), was the question raised again - and finally I think that I understands why no core-dump is generated!!
The problem is caused by the Ada run-time, which by default implements a signal handler for some POSIX-signals (for Linux: SIGABRT, SIGFPE, SIGILL, SIGSEGV and SIGBUS). For GNAT/linux the signal handler is called __gnat_error_handler in a-init.c, which looks something like this:
static void
__gnat_error_handler (int sig)
{
struct Exception_Data *exception;
char *msg;
static int recurse = 0;
...
switch (sig)
{
case SIGSEGV:
if (recurse)
{
exception = &constraint_error;
msg = "SIGSEGV";
}
else
{
...
msg = "stack overflow (or erroneous memory access)";
exception = &storage_error;
}
break;
}
recurse = 0;
Raise_From_Signal_Handler (exception, msg);
}
This handler is "process wide", and will be called by any trigged signal, no matter from which part of the process it originates from (no matter if coded in Ada/C/C++...).
When called, the handler rises an Ada-exception and leaves it to the Ada runtime to find an appropriate exception handler - if no such handler is found (eg. when an SIGSEGV is generated by any part of the C++-code), the Ada-runtime falls back to just terminate the process and just leave a simple printout from __gnat_error_handler (eg. "stack overflow (or erroneous memory access)").
http://www2.adacore.com/gap-static/GNAT_Book/html/node25.htm
To prevent Ada-runtime from handling a POSIX-signal, and convert it to an Ada-exception, it is possible to disable the default beahviour by using
pragma Interrupt_State (Name => value, State => SYSTEM | RUNTIME | USER);,
eg. to disable handling of SIGSEGV, define
Pragma Interrupt_State(SIGSEGV, SYSTEM);
in your Ada-code - now the system's default behaviour will be trigged when a SIGSEGV is raised, and a core-dump will be generated that allows you to trace down the origin of the problem!
I think this is a quite important issue to be aware of when mixing Ada and C/C++ on *NIX-platforms, since it may mislead you to think that problems origins from the Ada-code(since the printout indicates an exception generated from Ada) when the real source of the problem lays in the C/C++-code...
Although it is probably safe to disable the Ada-runtime default handling of SIGSEGV (I guess no sane programmer using this in any "expected" error handling... Well, maybe used in aviation software or similar, when some sort of "last resort" functionallity needs to be maintained to avoid something really bad from happening..) i guess a bit caution should be taken then "overriding" the Ada-runtime handling for signals.
One issue may be the SIGFPE-signal, which also raises an Ada Constraint_Error-exception by default. This type of exception may be used by the Ada-code as an "excpected behaviour".
Disabling SIGFPE by Pragma Interrupt_State may seriously affect the execution of the Ada-code, and crash your application during "normal circumstances" - on the other hand will any division by zero in the C/C++-code trig the Ada-exception handling mechanism, and leave you without any real trace of the origin of the problem...
This looks to me like a really good use for your AdaCore support. You aren't liable to find a whole lot of folk outside that company who are that familiar with the implications of the interactions between Gnu Ada's runtime and C++'s.
I would suggest for debugging the Ada code that you try putting in a last-ditch exception handler around everything, which in turn dumps the exception stack. Most vendors have some way of doing that, usually based off of Ada.Exceptions.Exception_Information and Ada.Exceptions.Exception_Message.
I found a discussion from a security perspective (finding malware). Basically there are 10 signals that you can try, SIGSEGV is only one of them.
It seems you can simply call sigaction(SIGSEGV, 0, SIG_DFL); to restore the default signal behavior.

Finding out the source of an exception in C++ after it is caught?

I'm looking for an answer in MS VC++.
When debugging a large C++ application, which unfortunately has a very extensive usage of C++ exceptions. Sometimes I catch an exception a little later than I actually want.
Example in pseudo code:
FunctionB()
{
...
throw e;
...
}
FunctionA()
{
...
FunctionB()
...
}
try
{
Function A()
}
catch(e)
{
(<--- breakpoint)
...
}
I can catch the exception with a breakpoint when debugging. But I can't trace back if the exception occurred in FunctionA() or FunctionB(), or some other function. (Assuming extensive exception use and a huge version of the above example).
One solution to my problem is to determine and save the call stack in the exception constructor (i.e. before it is caught). But this would require me to derive all exceptions from this base exception class. It would also require a lot of code, and perhaps slow down my program.
Is there an easier way that requires less work? Without having to change my large code base?
Are there better solutions to this problem in other languages?
You pointed to a breakpoint in the code. Since you are in the debugger, you could set a breakpoint on the constructor of the exception class, or set Visual Studio debugger to break on all thrown exceptions (Debug->Exceptions Click on C++ exceptions, select thrown and uncaught options)
If you are just interested in where the exception came from, you could just write a simple macro like
#define throwException(message) \
{ \
std::ostringstream oss; \
oss << __FILE __ << " " << __LINE__ << " " \
<< __FUNC__ << " " << message; \
throw std::exception(oss.str().c_str()); \
}
which will add the file name, line number and function name to the exception text (if the compiler provides the respective macros).
Then throw exceptions using
throwException("An unknown enum value has been passed!");
There's an excellent book written by John Robbins which tackles many difficult debugging questions. The book is called Debugging Applications for Microsoft .NET and Microsoft Windows. Despite the title, the book contains a host of information about debugging native C++ applications.
In this book, there is a lengthy section all about how to get the call stack for exceptions that are thrown. If I remember correctly, some of his advice involves using structured exception handling (SEH) instead of (or in addition to) C++ exceptions. I really cannot recommend the book highly enough.
Put a breakpoint in the exception object constructor. You'll get your breakpoint before the exception is thrown.
There is no way to find out the source of an exception after it's caught, unless you include that information when it is thrown. By the time you catch the exception, the stack is already unwound, and there's no way to reconstruct the stack's previous state.
Your suggestion to include the stack trace in the constructor is your best bet. Yes, it costs time during construction, but you probably shouldn't be throwing exceptions often enough that this is a concern. Making all of your exceptions inherit from a new base may also be more than you need. You could simply have the relevant exceptions inherit (thank you, multiple inheritance), and have a separate catch for those.
You can use the StackTrace64 function to build the trace (I believe there are other ways as well). Check out this article for example code.
Here's how I do it in C++ using GCC libraries:
#include <execinfo.h> // Backtrace
#include <cxxabi.h> // Demangling
vector<Str> backtrace(size_t numskip) {
vector<Str> result;
std::vector<void*> bt(100);
bt.resize(backtrace(&(*bt.begin()), bt.size()));
char **btsyms = backtrace_symbols(&(*bt.begin()), bt.size());
if (btsyms) {
for (size_t i = numskip; i < bt.size(); i++) {
Aiss in(btsyms[i]);
int idx = 0; Astr nt, addr, mangled;
in >> idx >> nt >> addr >> mangled;
if (mangled == "start") break;
int status = 0;
char *demangled = abi::__cxa_demangle(mangled.c_str(), 0, 0, &status);
Str frame = (status==0) ? Str(demangled, demangled+strlen(demangled)) :
Str(mangled.begin(), mangled.end());
result.push_back(frame);
free(demangled);
}
free(btsyms);
}
return result;
}
Your exception's constructor can simply call this function and store away the stack trace. It takes the param numskip because I like to slice off the exception's constructor from my stack traces.
There's no standard way to do this.
Further, the call stack must typically be recorded at the time of the exception being thrown; once it has been caught the stack has unrolled, so you no longer know what was going on at the point of being thrown.
In VC++ on Win32/Win64, you might get usable-enough results by recording the value from the compiler intrinsic _ReturnAddress() and ensuring that your exception class constructor is __declspec(noinline). In conjunction with the debug symbol library, I think you could probably get the function name (and line number, if your .pdb contains it) that corresponds to the return address using SymGetLineFromAddr64.
In native code you can get a shot at walking the callstack by installing a Vectored Exception handler. VC++ implements C++ exceptions on top of SEH exceptions and a vectored exception handler is given first shot before any frame based handlers. However be really careful, problems introduced by vectored exception handling can be difficult to diagnose.
Also Mike Stall has some warnings about using it in an app that has managed code. Finally, read Matt Pietrek's article and make sure you understand SEH and vectored exception handling before you try this. (Nothing feels quite so bad as tracking down a critical problem to code you added help track down critical problems.)
I believe MSDev allows you to set break points when an exception is thrown.
Alternatively put the break point on the constructor of your exception object.
If you're debugging from the IDE, go to Debug->Exceptions, click Thrown for C++ exceptions.
Other languages? Well, in Java you call e.printStackTrace(); It doesn't get much simpler than that.
In case anyone is interested, a co-worker replied to this question to me via email:
Artem wrote:
There is a flag to MiniDumpWriteDump() that can do better crash dumps that will allow seeing full program state, with all global variables, etc. As for call stacks, I doubt they can be better because of optimizations... unless you turn (maybe some) optimizations off.
Also, I think disabling inline functions and whole program optimization will help quite a lot.
In fact, there are many dump types, maybe you could choose one small enough but still having more info
http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx
Those types won't help with call stack though, they only affect the amount of variables you'll be able to see.
I noticed some of those dump types aren't supported in dbghelp.dll version 5.1 that we use. We could update it to the newest, 6.9 version though, I've just checked the EULA for MS Debugging Tools -- the newest dbghelp.dll is still ok to redistribute.
I use my own exceptions. You can handle them quite simple - also they contain text. I use the format:
throw Exception( "comms::serial::serial( )", "Something failed!" );
Also I have a second exception format:
throw Exception( "comms::serial::serial( )", ::GetLastError( ) );
Which is then converted from a DWORD value to the actual message using FormatMessage. Using the where/what format will show you what happened and in what function.
By now, it has been 11 years since this question was asked and today, we can solve this problem using only standard C++11, i.e. cross-platform and without the need for a debugger or cumbersome logging.
You can trace the call stack that led to an exception
Use std::nested_exception and std::throw_with_nested
This won't give you a stack unwind, but in my opinion the next best thing.
It is described on StackOverflow here and here, how you can get a backtrace on your exceptions inside your code without need for a debugger or cumbersome logging, by simply writing a proper exception handler which will rethrow nested exceptions.
It will, however, require that you insert try/catch statements at the functions you wish to trace (i.e. functions without this will not appear in your trace).
You could automate this with macros, reducing the amount of code you have to write/change.
Since you can do this with any derived exception class, you can add a lot of information to such a backtrace!
You may also take a look at my MWE on GitHub, where a backtrace would look something like this:
Library API: Exception caught in function 'api_function'
Backtrace:
~/Git/mwe-cpp-exception/src/detail/Library.cpp:17 : library_function failed
~/Git/mwe-cpp-exception/src/detail/Library.cpp:13 : could not open file "nonexistent.txt"