Errors not caught by CrashRpt

288 views
Skip to first unread message

pogo11

unread,
Feb 24, 2011, 12:31:11 AM2/24/11
to Crashrpt
Hi,

I'm working a project that will require crash reports and I've been
looking at a couple of solutions. Since I'm using Visual Studio,
CrashRpt is a very good fit for what I want. However, there are some
errors that are not caught properly by CrashRpt.


1) Delete already deleted memory

This can be reproduced by changing the segfaulting lines in
crashcon.cpp by :

// Delete already deleted memory.
char* p = new char[1000];
delete [] p;
delete [] p;

I have not been able to catch this error (aside from attaching another
process as a debugger using DebugActiveProcess()). Do you know any
way to catch this error?


2) Stack overflow exception

Even if the unhandled exception filter is supposed to catch this
exception, no report gets generated. My guess is that when in the
exception filter, we must be very careful not to overflow the stack
again. This can be reproduced by changing the segfaulting lines in
crashcon.cpp by :

// Stack overflow.
struct Overflow
{
static int recursive( int a )
{
return ( a < 0 ) ? 0 : recursive( a + 1 );
}
};
std::cout << Overflow::recursive( 0 ) << std::endl;

My solution to this problem is to do as little as possible in the
thread catching the exception and do the actual work in another
thread. So an example exception filter that would handle that case
would be something like :

LONG WINAPI exceptionFilterFunc( EXCEPTION_POINTERS* exceptionInfo )
{
if ( exceptionInfo->ExceptionRecord->ExceptionCode ==
EXCEPTION_STACK_OVERFLOW )
{
// Special case to handle the stack overflow exception.
// The dump will be realized from another thread.
struct ThreadParam
{
// Exception pointer.
EXCEPTION_POINTERS* exceptionInfo;
// Id of the thread to dump.
DWORD threadId;

// Constructor.
__forceinline ThreadParam( EXCEPTION_POINTERS*
paramExceptionInfo , DWORD paramThreadId )
: exceptionInfo( paramExceptionInfo )
, threadId( paramThreadId )
{
}

// Thread procedure doing the dump.
static DWORD WINAPI threadDumpRoutine( LPVOID
threadParameter )
{
ThreadParam* param = reinterpret_cast< ThreadParam*
>( threadParameter );

GenerateCrashDump( param->exceptionInfo , param-
>threadId );

delete param;

return 0;
}
};

// Create another thread that will do the dump.
// Use Win32 functions directly not to use too much of the
stack.
HANDLE thread = ::CreateThread(
0 ,
0 ,
&ThreadParam::threadDumpRoutine ,
new
ThreadParam( exceptionInfo , ::GetCurrentThreadId() ) ,
0 ,
0
);
::WaitForSingleObject( thread , INFINITE );
::CloseHandle( thread );
}
else
{
GenerateCrashDump( exceptionInfo , ::GetCurrentThreadId() );
}

return EXCEPTION_CONTINUE_SEARCH;
}


This solution might be an interesting addition to CrashRpt that would
allow it to generate proper dumps even in that stack overflow case.

Please let me know if you know a solution for the first problem, and
what you think about the second problem and the proposed solution.

Thanks in advance,

pogo11

zeXspectrum

unread,
Mar 4, 2011, 11:47:13 AM3/4/11
to Crashrpt
I tried to reproduce those two problems:

1) My test app just stucks on the second delete []. And no exception
is generated at all.

// Delete already deleted memory.
char* p = new char[1000];
delete [] p;
delete [] p; << Stucks here

I don't know how handle such error, but you can avoid such errors by
following some coding rules. For example, see this
http://crashrpt.sourceforge.net/docs/html/writing_robust_code.html

2) I reproduced the stack overflow exception as you described, and
error report was generated ok. I used CrashRpt v.1.2.8 and Visual
Studio 2005 on Windows 7 SP1. What's your version? Can you provide
more information how to reproduce your problem?

pogo11

unread,
Mar 7, 2011, 12:51:57 AM3/7/11
to Crashrpt
Hi,

On Mar 4, 11:47 am, zeXspectrum <zexspect...@gmail.com> wrote:
> I tried to reproduce those two problems:
>
> 1)  My test app just stucks on the second delete []. And no exception
> is generated at all.
>
> // Delete already deleted memory.
> char* p = new char[1000];
> delete [] p;
> delete [] p; << Stucks here
>
> I don't know how handle such error, but you can avoid such errors by
> following some coding rules. For example, see thishttp://crashrpt.sourceforge.net/docs/html/writing_robust_code.html

Yes, thanks... But I would like to catch them any way... The only
way I found to catch them was to create another process and attach it
as a debugger using DebugActiveProcess()... But I haven't found a way
to catch it within the same process.

> 2) I reproduced the stack overflow exception as you described, and
> error report was generated ok. I used CrashRpt v.1.2.8 and Visual
> Studio 2005 on Windows 7 SP1. What's your version? Can you provide
> more information how to reproduce your problem?

Here are the steps I did :

- Download the latest version (CrashRpt_v1.2.8_r1116.zip)
- Apply the patch at the end of the message
- Open the Visual Studio 2010 solution (I use this version on Windows
Vista)
- Run crashcon in Release mode (so that the stack overflow code
actually gets executed)

Instead of seeing the crash report window, the program will simply
crash.

Hope this helps,

pogo11


--- CrashRpt_v1.2.8_r1116/reporting/crashcon/crashcon.cpp Mon Mar 07
00:41:13 2011
+++ CrashRpt_v1.2.8_r1116.orig/reporting/crashcon/crashcon.cpp Fri Dec
10 22:24:56 2010
@@ -90,16 +90,8 @@
{
}
#else
- // Stack overflow.
- struct Overflow
- {
- static int recursive( int a )
- {
- return ( a < 0 ) ? 0 : recursive( a + 1 );
- }
- };
-
- printf("%d\n", Overflow::recursive( 0 ));
+ int *p = 0;
+ *p = 0;
#endif // _DEBUG

}

zeXspectrum

unread,
Mar 7, 2011, 7:38:58 AM3/7/11
to Crashrpt
Can you attach a screen shot of how it "simply crashes"? Does the
window disappears silently or standard Windows Error Reporting window
appears?

pogo11

unread,
Mar 9, 2011, 12:15:10 AM3/9/11
to Crashrpt
Can't find a way to attach an image to this group... So here it is :

http://misc.martinbisson.com/screen.png

So yes, standard WER window appears...

pogo11

unread,
Mar 14, 2011, 12:35:51 AM3/14/11
to Crashrpt
By the way, I have the same behavior with Visual Studio 2005 and 2010.

Also, I just noticed that my patch is inverted, I inverted the old and
new part... Sorry about that. But you get the idea...

Can you reproduce it? Is my idea to do the dump in another thread a
acceptable solution?
Reply all
Reply to author
Forward
0 new messages