What steps will reproduce the problem?
1. Call crAddFile2 with a pattern, e.g. "log\\*"
2. Call crAddFile2 again with a different pattern, e.g. "data\\*"
3. Trigger an application crash
What is the expected output? What do you see instead?
Crash reporting should work as described in the manual. CrashSender crashes
instead with an access violation.
What version of CrashRpt are you using?
1.4.2
What is your version of Visual Studio?
2008
What is your version of Windows operating system?
7
Please provide any additional information below.
I have debugged the issue and tracked it down to an error raised in
CCrashInfoReader::UnpackCrashDescription(), line 640-644 where the condition
m_pCrashDesc->m_uFileItems!=eri.m_FileItems.size() is checked and evaluates to
false. Reason is that the pattern's "file name" is "*" for both of the above
example patterns and is used as a key in the eri.m_FileItems map.
The actual access violation happens as a result of a dereferenced NULL pointer
somewhere in CErrorReportSender::Finalize() during destruction of
CErrorReportSender. As far as I could see this problem has already been
reported earlier. The core issue here is that it should be possible to use
crAddFile2() with different filename patterns as mentioned above.
Original issue reported on code.google.com by bernd.wa...@googlemail.com on 11 Sep 2014 at 11:47
Original issue reported on code.google.com by
bernd.wa...@googlemail.comon 11 Sep 2014 at 11:47