Closed GoogleCodeExporter closed 9 years ago
OK it seems like there can be only 3 properties:
<CustomProps>
<Prop name="AnotherOne" value="7.0" />
<Prop name="AnotherTest" value="7.0" />
<Prop name="GraphicsInfo" value="No information available" />
<Prop name="" value="" />
<Prop name="" value="" />
<Prop name="" value="" />
</CustomProps>
I just added two more properties, now the first 3 are cleared.
Original comment by cron...@gmail.com
on 31 Oct 2012 at 9:11
Tested with v1.4.0, same behaviour.
In case you are wondering, this is what I do to add the properties:
QString suiteVersion = QString("%1.%2").arg(QString::number(major)).arg(QString::number(minor));
crAddProperty(L"Suite", suiteVersion.utf16());
This works in v1.3.0 (used in our previous release).
Original comment by cron...@gmail.com
on 31 Oct 2012 at 9:34
Original comment by zexspect...@gmail.com
on 7 Nov 2012 at 5:52
I tried to reproduce with v.1.4.0, but it works OK for me. Here what I did. I
added the following code to WTLDemo.cpp:
nResult = crAddProperty(_T("AnExampleProperty"),_T("Property value"));
ATLASSERT(nResult==0);
nResult = crAddProperty(_T("VideoCard"),_T("nVidia GeForce 9800"));
ATLASSERT(nResult==0);
nResult = crAddProperty(_T("HDDSerialNumber"),_T("1234512345098765"));
ATLASSERT(nResult==0);
nResult = crAddProperty(_T("MACAddress"),_T("11.11.11.11"));
ATLASSERT(nResult==0);
nResult = crAddProperty(_T("UserName"),_T("TheUserName"));
ATLASSERT(nResult==0);
And the result is:
<CustomProps>
<Prop name="AnExampleProperty" value="Property value" />
<Prop name="HDDSerialNumber" value="1234512345098765" />
<Prop name="MACAddress" value="11.11.11.11" />
<Prop name="UserName" value="TheUserName" />
<Prop name="VideoCard" value="nVidia GeForce 9800" />
</CustomProps>
Can you provide me with additional information of what should I do to
reproduce? Please send me the piese of code you used to add those properties.
Original comment by olegkriv...@gmail.com
on 8 Nov 2012 at 4:17
Well, here it is, but it is really simple code:
QString licenseNumber = licenseFeatures->license_number;
QString suiteVersion = QString("%1.%2").arg(QString::number(major)).arg(QString::number(minor));
QString isAltair = QString("%1").arg(QString::number(is_altair()));
graphicsDriverInfoString = RenderManager->getGraphicsDriverInfo();
crAddProperty(L"LicenceNumber", licenseNumber.utf16());
crAddProperty(L"IsAltair", isAltair.utf16());
crAddProperty(L"Suite", suiteVersion.utf16());
// everything is still fine
crAddProperty(L"GraphicsInfo", graphicsDriverInfoString.utf16());
// now the 4th property (Suite) is cleared
As I mentioned, if I revert to 1.3.0, it is working. I have had a look at the
CrashRpt code, and I cannot see anything obvious that changed in the whole
chain of functions called when calling crAddProperty. (That is not to say that
nothing changed ;) ) I must say though that I did not really look at _what_ the
code does, I just compared the files.
If anyone can guide me how to debug this, it would be appreciated.
Original comment by cron...@gmail.com
on 8 Nov 2012 at 5:26
Thanks for the code. The code is really simple, so my main guess is that your
QString introduces some unexpected effects. Can you please try to replase those
utf16 strings with hard-coded strings like below and tell me if it works for
you?
crAddProperty(L"LicenceNumber", "1234567");
crAddProperty(L"IsAltair", L"Yes");
crAddProperty(L"Suite", L"Some suite version here");
// everything is still fine
crAddProperty(L"GraphicsInfo", L"Some graphics info here");
// now the 4th property (Suite) is cleared
Original comment by zexspect...@gmail.com
on 8 Nov 2012 at 5:32
Unfortunately changing the code to
crAddProperty(L"LicenceNumber", L"1234");//licenseNumber.utf16());
crAddProperty(L"IsAltair", L"0");//isAltair.utf16());
crAddProperty(L"Suite", L"6.2");//suiteVersion.utf16());
crAddProperty(L"GraphicsInfo", L"nvidia GeForce 9800 GT");//graphicsDriverInfoString.utf16());
produces
<Prop name="GraphicsInfo" value="nvidia GeForce 9800 GT" />
<Prop name="IsAltair" value="0" />
<Prop name="LicenceNumber" value="1234" />
<Prop name="" value="" />
Original comment by cron...@gmail.com
on 8 Nov 2012 at 5:51
And removing the adding of 'GraphicsInfo' has this result:
<CustomProps>
<Prop name="IsAltair" value="0" />
<Prop name="LicenceNumber" value="1234" />
<Prop name="Suite" value="6.2" />
</CustomProps>
So it would seem that the 'Suite' property is working fine.
Original comment by cron...@gmail.com
on 8 Nov 2012 at 5:56
Hmmm... I put your code to WTLDemo.cpp like this:
crAddPropertyW(L"LicenceNumber", L"1234");//licenseNumber.utf16());
crAddPropertyW(L"IsAltair", L"0");//isAltair.utf16());
crAddPropertyW(L"Suite", L"6.2");//suiteVersion.utf16());
crAddPropertyW(L"GraphicsInfo", L"nvidia GeForce 9800 GT");
//graphicsDriverInfoString.utf16());
And it produces this:
<CustomProps>
<Prop name="GraphicsInfo" value="nvidia GeForce 9800 GT" />
<Prop name="IsAltair" value="0" />
<Prop name="LicenceNumber" value="1234" />
<Prop name="Suite" value="6.2" />
</CustomProps>
So, it works OK for me... I use CrashRpt v.1.4.0 Debug on VS2010/Win 7 Pro.
Please tell me, when do you call that piese of code? I call it right after
crInstall() (see WTLDemo.cpp for example).
Original comment by zexspect...@gmail.com
on 8 Nov 2012 at 6:12
It is called in a callback function (simplified version):
BOOL WINAPI crashCallBack(LPVOID pState)
{
crAddPropertyW(L"LicenceNumber", L"1234");//licenseNumber.utf16());
crAddPropertyW(L"IsAltair", L"0");//isAltair.utf16());
crAddPropertyW(L"Suite", L"6.2");//suiteVersion.utf16());
crAddPropertyW(L"GraphicsInfo", L"nvidia GeForce 9800 GT"); //graphicsDriverInfoString.utf16());
return TRUE;
}
which is installed like this:
info.pfnCrashCallback = crashCallBack;
The crash in this case is type 11, SEGFAULT (real crash due to a bug in the
app, not a simulated one).
The callback is called correctly, because I can see the custom dialog we
display in it.
Original comment by cron...@gmail.com
on 8 Nov 2012 at 6:32
Thank you for the information. I tried to reproduce your case like this (edited
WTLDemo.cpp's CrashCallbac function):
BOOL WINAPI CrashCallback(LPVOID lpvState)
{
UNREFERENCED_PARAMETER(lpvState);
// Crash happened!
crAddPropertyW(L"LicenceNumber", L"1234");//licenseNumber.utf16());
crAddPropertyW(L"IsAltair", L"0");//isAltair.utf16());
crAddPropertyW(L"Suite", L"6.2");//suiteVersion.utf16());
crAddPropertyW(L"GraphicsInfo", L"nvidia GeForce 9800 GT");//graphicsDriverInfoString.utf16());
return TRUE;
}
And the XML file contains these properties:
<CustomProps>
<Prop name="GraphicsInfo" value="nvidia GeForce 9800 GT" />
<Prop name="IsAltair" value="0" />
<Prop name="LicenceNumber" value="1234" />
<Prop name="Suite" value="6.2" />
</CustomProps>
So, it still works for me. Can you try to modify WTLDemo.cpp yourself and check
if it works OK for you? You can find the WTLDemo.cpp inside of demos/WTLDemo
folder of CrashRpt distribution.
Original comment by zexspect...@gmail.com
on 8 Nov 2012 at 6:52
:( adding that code to the WTLDemo works as expected.
So the next question: how do I go about debugging it? When stepping through
AddProperty, I cannot see the value of m_props.
Original comment by cron...@gmail.com
on 8 Nov 2012 at 8:13
OK, than it seems that the issue is related to your app environment.
I recommend you to start the debugging from debugging of CrashSender process.
Add the following line in the beginning of CErrorReportSender::Init() method
(see ErrorReportSender.cpp file inside of /reporting/crashsender folder):
ATLASSERT(0);
Then compile the CrashRpt solution (in Debug configuration) and then compile
your app (in Debug configuration, too). Ensure your app is linked to
CrashRpt1400d.lib (debug version of the CrashRpt library).
Please also ensure that you do not specify CR_INST_SEND_QUEUED_REPORTS flag for
your CrashRpt configuration. Please unset that flag while your are debugging.
Then run your app and trigger an exception. When crash occurs, CrashRpt runs
CrashSender1400d.exe process and passes the information about the crash to that
process. You will be able to see the "Debug Assertion Failed" window caused by
that ATLASSERT macro.
Next, in your Visual Studio window, open menu Tools->Attach to process...,
select CrashSender1400d.exe from the list of processes, and click Attach
button. Next, in "Debug Assertion Failed" window, click Retry button.
Next, a "CrashSender1400d.exe has triggered a breakpoint" window should appear.
Click Break button in that window. Now you are able to step-by-step debug the
code (press F10 several time to see how instruction pointer moves). In
particular, step to the m_CrashInfo.Init() method and watch the
m_CrashInfo.m_Reports(0).m_Props array to see what custom properties have been
passed to the CrashSender process. Then please tell me what properties you see.
Original comment by zexspect...@gmail.com
on 8 Nov 2012 at 9:11
Following these steps produces:
m_Props [4](
({m_pchData=0x0000000002e3ca1c "GraphicsInfo" }, {m_pchData=0x0000000002b33b4c "nvidia GeForce 9800 GT" }),
({m_pchData=0x0000000002b3176c "IsAltair" }, {m_pchData=0x0000000002e3ab4c "0" }),
({m_pchData=0x0000000002b30dbc "LicenceNumber" }, {m_pchData=0x0000000002b3134c "1234" }),
({m_pchData=0x0000000002b317cc "Suite" }, {m_pchData=0x0000000002e3a64c "6.2" })) std::map<WTL::CString,WTL::CString,std::less<WTL::CString>,std::allocator<std::pair<WTL::CString const ,WTL::CString> > >
Letting it continue however drops the Suite value, so it seems the problem is
somewhere in CrashSender. I'll do some more digging.
Original comment by cron...@gmail.com
on 8 Nov 2012 at 10:28
Stepping through the code some more revealed that the culprit is
CErrorReportSender::CreateCrashDescriptionXML(). It seems eri.GetPropByIndex(i,
sName, sVal) returns empty values. I'll do some more debugging.
Original comment by cron...@gmail.com
on 8 Nov 2012 at 10:40
I think I found it.
CrashInfoReader.cpp:259:
if(nItem<0 || nItem>=(int)m_FileItems.size())
Shouldn't that be m_props.size()?
Original comment by cron...@gmail.com
on 8 Nov 2012 at 11:04
Yes, it seems there should be m_props.size(). Thanks for debugging. I'll fix
this in the repository, so please check out the latest code from trunk and let
me know if it works for you.
Original comment by zexspect...@gmail.com
on 8 Nov 2012 at 11:21
This issue was closed by revision r1451.
Original comment by zexspect...@gmail.com
on 8 Nov 2012 at 11:23
Working fine now, thanks.
Original comment by cron...@gmail.com
on 8 Nov 2012 at 12:20
Original issue reported on code.google.com by
cron...@gmail.com
on 31 Oct 2012 at 8:45