Adding custom properties with same name results in CrashSender.exe assertion failure.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. crAddProperty( "name", "value1")
2. crAddProperty( "name", "value2")
3. crGenerateErrorReport(...)

What is the expected output? What do you see instead?

After stepping through CCrashInfoReader::UnpackCrashDescription, it looks like 
the two properties are packed correctly.  However, when unpacking, the second 
property value overwrites the the first (eri.m_Props[sName] = sValue) as is 
expected in a std::map.  However, earlier, CrashHandler::PackProperty has 
incremented m_pTmpCrashDesc->m_uCustomProps.  This causes an assertion failure 
at CrashInfoReader.cpp:640.

I'm not certain of the correct behavior.  I can certainly work around the 
issue, as the duplicate Custom Property was a side-effect of my allowing the 
user to trigger manual error reports.  I was setting a Custom Property to 
indicate the error report was user-instantiated.  So, if the user reports two 
errors in the same session, the bug is triggered.  But I could certainly see 
less unorthodox usages triggering it.

What version of CrashRpt are you using?
1.402

What is your version of Visual Studio?

2010, compiling x64 project

What is your version of Windows operating system?

Windows 7 64-bit

Please provide any additional information below.

Original issue reported on code.google.com by dangth...@gmail.com on 19 Sep 2013 at 5:08

[GoogleCodeExporter]

Looks like it could be related to #205

Original comment by dangth...@gmail.com on 19 Sep 2013 at 5:09

[GoogleCodeExporter]

I experience this problem also (using 1.402) when using 
crGenerateErrorReport(...) to generate multiple error reports.  The challenge 
is that you want to effectively update\replace the same property (or file or 
regkey) on each error report.  For instance:

  crAddProperty( "timeAppBeenRunning", "<a formatted string>");

dangth is spot on with his description that the counters (ie. m_uCustomProps) 
for properties (or file or regkey) bump when overwriting an existing property.  
dangth did not mention it for his experience, but when CrashSender assertions 
and aborts it does not clean up all it's locking mechanism and this results in 
the calling app generating the error report to hang at WaitForSingleObject:

  File:          CrashHandler.cpp
  Function:      LaunchCrashSender()
  Line (~1683):  WaitForSingleObject(m_hEvent, INFINITE)

 -David

Original comment by mrdavidf...@gmail.com on 2 Oct 2013 at 3:49

[GoogleCodeExporter]

David,

That's exactly the runtime behavior I saw when running in release mode.  I had 
to recompile CrashRpt and attach a debugger to get to the assertion.  In the 
end, I ended up writing my own wrapper class which stores it's own copies of 
any key/values and filenames being monitored.  Then, after a report is 
triggered, the class "resets" CrashRpt by calling crUnininstall() then 
crInstall().  Kind of gross, but it works.

-Dan

Original comment by dangth...@gmail.com on 2 Oct 2013 at 12:47

[GoogleCodeExporter]

Hi Dan,

Thanks for the suggested workaround.  Much appreciated.

-Dave

Original comment by mrdavidf...@gmail.com on 2 Oct 2013 at 4:08

[GoogleCodeExporter]

I removed the integrity checks code from the end of 
CCrashInfoReader::UnpackCrashDescription() method, so now it will not trigger 
assertions. Fixed this in trunk. You can check if you have time.

Original comment by zexspect...@gmail.com on 6 Oct 2013 at 3:51

[GoogleCodeExporter]

This issue was closed by revision r1636.

Original comment by zexspect...@gmail.com on 6 Oct 2013 at 3:53

• Changed state: Fixed