Below is a code snippet where I deliberately cause 2 NullPointerException. The first one is handled. Whereas the second one goes unhandled. I want to create a crash dump on the second exception when a crash would occur.
int* nullPtr = NULL;
try{
x = *nullPtr;
}
catch(...) {
QLOG_WARNING0(QTEXT("catching 1st null ptr exception."));
}
y = *nullPtr;
This does crash the process but the dump is not generated using -e option only.
What options should I use to get the dump?
Or is there a way I could achieve this with debugDiag tool? If so, how?
This is only a sample code. The actual use case I am debugging has a process crashing but I am unable to take dumps for the crash. There are valid handled exceptions where the dump is getting triggerred in case I use the first chance option( - e 1). This is causing procdump to exit before the actual crash occurs.
“No I am open to any other tool.”
Per your comment, there are other ways to trap a dump file. In my answer to Getting detailed crash dumps from a hooked exe,
you’ll see that you can set some registry key settings to trap the dump from an unhandled exception. The settings assume you have Windows Error Reporting enabled. I’ve gone so far as to incorporate those settings into a small utility program that my company uses when debugging difficult customer crashes.
Related
A OSX app crashes when I try to close a socket handle, it worked fine in all the previous platforms, but it appears to crash in Yosemite.
The line where is crashes is
-(void)stopPacketReceiver
{
close(sd);
}
In Xcode it pauses all the threads and show EXC_GUARD exception, what kind of exception is this, any ideas ?
Thanks,
Ahmed
EDIT:
Here r the exception codes that I get
Exception Type: EXC_GUARD
Exception Codes: 0x4000000100000000, 0x08fd4dbfade2dead
From a post in Apple's old developer forums from Quinn "The Eskimo" (Apple Developer Relations, Developer Technical Support, Core OS/Hardware), edited by me to remove things which were specific to that specific case:
EXC_GUARD is a change in 10.9 designed to help you detect file
descriptor problems. Specifically, the system can now flag specific
file descriptors as being guarded, after which normal operations on
those descriptors will trigger an EXC_GUARD crash (when it wants to
operate on these file descriptors, the system uses special 'guarded'
private APIs).
We added this to the system because we found a lot of apps were
crashing mysteriously after accidentally closing a file descriptor
that had been opened by a system library. For example, if an app
closes the file descriptor used to access the SQLite file backing a
Core Data store, Core Data would then crash mysteriously much later
on. The guard exception gets these problems noticed sooner, and thus
makes them easier to debug.
For an EXC_GUARD crash, the exception codes break down as follows:
o The first exception code … contains three bit
fields:
The top three bits … indicate [the type of guard].
The remainder of the top 32 bits … indicate [which operation was disallowed].
The bottom 32 bits indicate the descriptor in question ….
o The second exception code is a magic number associated with the
guard. …
Your code is closing a socket it doesn't own. Maybe sd contains the descriptor number for a descriptor that you once owned but is now a dangling reference, because you already closed your descriptor and that number has now been reused for somebody else's descriptor. Or maybe sd just has a junk value somehow.
We can decode some more information from the exception codes, but most likely you just have to trace exactly where you're doing with sd over its life.
Update:
From the edited question, I see that you've posted the exception codes. Using the constants from the kernel source, the type of guard is GUARD_TYPE_FD, the operation that was disallowed was kGUARD_EXC_CLOSE (i.e. close()), and the descriptor was 0 (FILENO_STDIN).
So, in all probability, your stopPacketReceiver was called when the sd instance variable was uninitialized and had the default 0 value that all instance variables get when an object is first allocated.
The magic value is 0x08fd4dbfade2dead, which according to the original developer forums post, "indicates that the guard was applied by SQLite". That seems strange. Descriptor 0 would normally be open from process launch (perhaps referencing /dev/null). So, SQLite should not own that.
I suspect what has happened is that your code has actually closed descriptor 0 twice. The first time it was not guarded. It's legal to close FILENO_STDIN. Programs sometimes do it to reopen that descriptor to reference something else (such as /dev/null) if they don't want/need the original standard input. In your case, it would have been an accident but would not have raised an exception. Once it was closed, the descriptor would have been available to be reallocated to the next thing which opened a descriptor. I guess that was SQLite. At that time, SQLite put a guard on the descriptor. Then, your code tried to close it again and got the EXC_GUARD exception.
If I'm right, then it's somewhat random that your code got the exception (although it was always doing something bad). The fact that file descriptor 0 got assigned to a subsystem that applied a guard to it could be a race condition or it could be a change in order of operations between versions of the OS.
You need to be more careful to not close descriptors that you didn't open. You should initialize any instance variable meant to hold a file descriptor to -1, not 0. Likewise, if you close a descriptor that you did own, you should set the instance variable back to -1.
Firstly, that sounds awesome - it sounds like it caught what would have been EXC_BAD_ACCESS (but this is a guess).
My guess is that sd isn't a valid descriptor. It's possible an API changed in Yosemite that's causing the place you create the descriptor to return NULL, or it's possible a change in the event timeline in Yosemite causes it to have already been cleaned up.
Debugging tip here: trace back sd all the way to its creation.
On Linux I get nice, healthy, full stack traces. On Windows, however, when something crashes (like a segfault violation), I only get the top one or two lines of the stack, followed by the entry 0x0 (which I cannot expand). This makes it very hard to debug
Probably you should start using WinDBG to debug your program instead of IDE like eclipse. This is very powerful command line tool and its functionality is very similar to GDB.
On Windows, "UnhandledExceptionFilter" function is called when no exception handler is defined to handle the exception that is raised. The function typically passes the exception up to the Ntdll.dll file, which catches and tries to handle it.
EXCEPTION_POINTERS structure does contains the most useful information about what is the exception and where it has occurred which gets passed as one of the parameter of the above function. This information would be used by .exr and .cxr command in WinDBG to get the complete stack trace.
typedef struct _EXCEPTION_POINTERS {
PEXCEPTION_RECORD ExceptionRecord;
PCONTEXT ContextRecord;
} EXCEPTION_POINTERS, *PEXCEPTION_POINTERS;
ExceptionRecord A pointer to an EXCEPTION_RECORD structure that
contains a machine-independent description of the exception.
ContextRecord A pointer to a CONTEXT structure that contains a
processor-specific description of the state of the processor at the
time of the exception.
For complete steps about how to get the complete back trace and analysis from the dump file(like GDB)or debug session, you may want to read and follow the steps mentioned in the following link:
http://support.microsoft.com/kb/313109
In Matlab, there is, as far as I know, no good way to conditionally catch exceptions (correct me if I'm wrong). The only way is to catch the exception, check the identifier, and rethrow the error if this particular error can not be handled. That's acceptable though inconvenient. However, when I use Matlabs dbstop if error, I end up at the ME.rethrow() line. I'm then unable to dbup back to the place where the original error was caused.
function test_excc
try
sub_test()
catch ME
if strcmp(ME.identifier, 'test:notsobad')
fprintf(1, 'Fine\n');
else
ME.rethrow();
end
end
end
function sub_test
sub_sub_test();
end
function sub_sub_test()
if rand>0.5
error('test:error', 'Noooo!');
else
error('test:notsobad', 'That''OK');
end
end
Example usage:
>> test_excc()
Error using test_excc>sub_sub_test (line 21)
Noooo!
Error in test_excc>sub_test (line 16)
sub_sub_test();
Error in test_excc (line 4)
sub_test()
9 ME.rethrow();
K>> dbstack
> In test_excc at 9
Although the Matlab desktop environment prints the entire stack trace back to sub_sub_test, the debugger does not give me the possibility to go up the stack trace and debug inside this function.
I am aware of dbstop if caught error. However, this will debug into any caught error, which may be many if software makes heavy use of exceptions. I only want to stop on uncaught errors, but I want to stop where the error is generated — not where it's rethrown.
My question:
In Matlab, how do I conditionally catch an error (based on error identifier) and debug into the place where the error is originally thrown?
I would guess that you cannot do this. As soon as execution enters the catch statement, dbstack will have to refer to that location inside the catch, so the information necessary to debug at the cause of the error is lost. ME.stack will tell you where the exception came from, but that isn't sufficient to debug at that location.
So I doubt you can solve the problem by doing something clever inside the catch. Looking at the documentation for catch, there also doesn't seem to be a way to do a java-style catch (ExceptionType ME).
There might be some hacky ways to solve this by using debug commands programmatically. For example, S = dbstatus saves the debug state and if there was a way to resume from a saved state, then you could attach this to the exception. But I can't find any documented way to do that.
I'm working on an utility that processes very large data sets. Since there are lots of code it uses to operate, some totally unexpected errors appear while running. So I run it inside Visual Studio debugging session. In most cases I can skip an error or recover from it using immediate window and some manipulation with "Set next statement". But this error can reoccur in future. Is it possible to automatize recovering process without restarting debugging session?
Depending on the structure of your code and the language you are using you may be able to do something similar with Conditional Breakpoint abuse.
The idea is to use the Breakpoint condition to do an evaluation, basically an automated way of doing what you do in the immediate window.
int c = a + b; // some type of calculation
if (c == 5) // your test
{
// ERROR
return;
}
E.g. If you know the test c==5 is what is going wrong you can place a Conditional Breakpoint at that line:
if (c == 5) // your test
With the expression of some correct value:
c = 1
And then you won't go down the error condition path. Of course this doesn't always work, but can be useful in come circumstances.
I have a process suspended at breakpoint under visual studio debugger.
I can attach as many as cdb (Microsoft's console debugger) in non-invasive mode as
cdb -p pid -pvr
How to achieve the same using my own program which uses Debug Engine API.
IDebugClient* debugClient = 0;
(DebugCreate( __uuidof(IDebugClient), (void **)&debugClient );
debugClient->AttachProcess(0,id,DEBUG_ATTACH_NONINVASIVE
|DEBUG_ATTACH_NONINVASIVE_NO_SUSPEND);
This code causes E_INVALIDARG. Is this combination is not allowed ? The one below works, but when it calls GetStackTrace, it returns E_UNEXPECTED.
debugClient->AttachProcess(0,id,DEBUG_ATTACH_NONINVASIVE);
debugControl->GetStackTrace(0, 0, 0, pStackFrames, maxFrames, &framesFilled);
I am interested to attach to a process already at debug break noninvasive way , and get a few local variable from its current stack & some global variable value.
Secondly, can someone point me the function used to dump the content of memory for a symbol iteratively like !stl does. I need to write a plugin to dump one of my vector like structure.
Thanks
I believe there's nothing wrong with
DEBUG_ATTACH_NONINVASIVE|DEBUG_ATTACH_NONINVASIVE_NO_SUSPEND
combination - it is perfectly permissible and is even featured in assert sample.
Otherwise, as far as documentation goes - it is not that detailed. I would suggest debugging your extension with the help of wt (trace and watch data) - it is particularly useful when you need to locate the exact subroutine that is returning an error which might provide you with better insight on the problem.
As for remotely accessing typed data in your apps from an extension, I've found ExtRemoteTyped class (available in engextcpp.hpp in the sdk subfolder) to be very helpful and intuitive to use.