720444 - Add more available memory reporting to crash reports

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Gian-Carlo Pascutto [:gcp]]

For various memory & OOM related bugs (bug 702217, bug 718575), it would be useful to log more information about available Windows memory than we do now. 

We currently log dwMemoryLoad, ullTotalVirtual and ullAvailVirtual. Neither of these really says much about available memory. We want ullAvailPageFile (most important) and maybe ullAvailPhys too.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366770%28v=vs.85%29.aspx

Comment 1

[Justin Lebar (not reading bugmail)]

I guess the way to test this is to cause my build to crash and then check the resulting crashreport?

Comment 2

[Justin Lebar (not reading bugmail)]

Attachment: (Uncompiled) WIP v1

Comment 3

[Gian-Carlo Pascutto [:gcp]]

>I guess the way to test this is to cause my build to crash and then check the 
>resulting crashreport?

Yes. Might need to mark the build as official or similar to get the crash reporting stuff to activate.

Comment 4

[Benjamin Smedberg]

Just set MOZ_CRASHREPORTER=1 in your environment.

Comment 5

[(not currently active) Ted Mielczarek]

You don't even have to send the report. Just click the "Details" tab in the crashreporter.

Comment 6

[Justin Lebar (not reading bugmail)]

Hm.  I tried setting MOZ_CRASHREPORTER=1 in my environment, mk_add_options'ing it, and building with |export MOZILLA_OFFICIAL=1| in my .mozconfig.

In no case did I get the crash reporter to pop up when I dereferenced a null pointer.  I get the Windows crash report dialog instead.

Comment 7

[(not currently active) Ted Mielczarek]

Are you building with --disable-crashreporter? Because that would completely disable this code.

Comment 8

[(not currently active) Ted Mielczarek]

Also, crashme is the easiest way to test crashing:
http://code.google.com/p/crashme/

Comment 9

[Mozilla RelEng Bot]

Try run for 2627b6a8d253 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=2627b6a8d253
Results (out of 2 total builds):
    success: 2
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-2627b6a8d253

Comment 10

[Justin Lebar (not reading bugmail)]

AdapterDeviceID: 0x0405
AdapterVendorID: 0x15ad
Add-ons: [e-mail]:1.2,[e-mail]:0.3,{972ce4c6-7e08-4474-a285-3208198ce6fd}:12.0a1
AvailablePageFile: 1446150144
AvailablePhysicalMemory: 417677312
AvailableVirtualMemory: 1924177920
BuildID: 20120124065917
CrashTime: 1327431776
EMCheckCompatibility: true
FramePoisonBase: 00000000f0de0000
FramePoisonSize: 65536
InstallTime: 1327431549
Notes: AdapterVendorID: 0x15ad, AdapterDeviceID: 0x0405, AdapterSubsysID: 040515ad, AdapterDriverVersion: 7.14.1.1134
D3D10 Layers? D3D10 Layers-
D3D9 Layers? D3D9 Layers-

ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
ProductName: Firefox
ReleaseChannel: default
SecondsSinceLastCrash: 23606404
StartupTime: 1327431761
SystemMemoryUsePercentage: 61
Theme: classic/1.0
Throttleable: 1
TotalVirtualMemory: 2147352576
URL: about:home
Vendor: Mozilla
Version: 12.0a1
Winsock_LSP: MSAFD Tcpip [TCP/IP] : 2 : 1 :  
 MSAFD Tcpip [UDP/IP] : 2 : 2 : %SystemRoot%\system32\mswsock.dll 
 MSAFD Tcpip [RAW/IP] : 2 : 3 :  
 MSAFD Tcpip [TCP/IPv6] : 2 : 1 : %SystemRoot%\system32\mswsock.dll 
 MSAFD Tcpip [UDP/IPv6] : 2 : 2 :  
 MSAFD Tcpip [RAW/IPv6] : 2 : 3 : %SystemRoot%\system32\mswsock.dll 
 RSVP TCPv6 Service Provider : 2 : 1 :  
 RSVP TCP Service Provider : 2 : 1 : %SystemRoot%\system32\mswsock.dll 
 RSVP UDPv6 Service Provider : 2 : 2 :  
 RSVP UDP Service Provider : 2 : 2 : %SystemRoot%\system32\mswsock.dll 
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{7043F7DF-0372-4BA6-B2E2-8E28A7723175}] SEQPACKET 1 : 2 : 5 :  
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{7043F7DF-0372-4BA6-B2E2-8E28A7723175}] DATAGRAM 1 : 2 : 2 : %SystemRoot%\system32\mswsock.dll 
 MSAFD NetBIOS [\Device\NetBT_Tcpip6_{A65083FF-B186-423B-A663-6A0050E91908}] SEQPACKET 4 : 2 : 5 :  
 MSAFD NetBIOS [\Device\NetBT_Tcpip6_{A65083FF-B186-423B-A663-6A0050E91908}] DATAGRAM 4 : 2 : 2 : %SystemRoot%\system32\mswsock.dll 
 MSAFD NetBIOS [\Device\NetBT_Tcpip6_{CB4B07EB-10E8-4179-9748-7ADF60C5051C}] SEQPACKET 3 : 2 : 5 :  
 MSAFD NetBIOS [\Device\NetBT_Tcpip6_{CB4B07EB-10E8-4179-9748-7ADF60C5051C}] DATAGRAM 3 : 2 : 2 : %SystemRoot%\system32\mswsock.dll 
 MSAFD NetBIOS [\Device\NetBT_Tcpip6_{89EB7912-4610-437A-BCB2-C80D2A593DA7}] SEQPACKET 0 : 2 : 5 :  
 MSAFD NetBIOS [\Device\NetBT_Tcpip6_{89EB7912-4610-437A-BCB2-C80D2A593DA7}] DATAGRAM 0 : 2 : 2 : %SystemRoot%\system32\mswsock.dll 
 MSAFD NetBIOS [\Device\NetBT_Tcpip6_{7043F7DF-0372-4BA6-B2E2-8E28A7723175}] SEQPACKET 2 : 2 : 5 :  
 MSAFD NetBIOS [\Device\NetBT_Tcpip6_{7043F7DF-0372-4BA6-B2E2-8E28A7723175}] DATAGRAM 2 : 2 : 2 : %SystemRoot%\system32\mswsock.dll 
 VMCI sockets DGRAM : 0 : 2 :  
 VMCI sockets STREAM : 0 : 1 : %SystemRoot%\system32\vsocklib.dll

This report also contains technical information about the state of the application when it crashed.

Comment 11

[Justin Lebar (not reading bugmail)]

Attachment: Patch v1

Comment 12

[(not currently active) Ted Mielczarek]

Comment on attachment 591186 [details] [diff] [review]
Patch v1

Review of attachment 591186 [details] [diff] [review]:
-----------------------------------------------------------------

While you're here, do you think you could do me a favor and add a test for these fields? I apparently skipped that when I first implemented this. There are two ways you could do it.
1) Just add it to an existing test like http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/test/unit/test_crashreporter_crash.js, and only check the fields when running on Windows. (Which is kind of a pain to test in xpcshell tests.)
2) Add a new test in that dir, and have the manifest skip it for non-Windows platforms: http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/test/unit/xpcshell.ini

The test itself should be simple, just assert that the fields exist and contain numeric values.

::: toolkit/crashreporter/nsExceptionHandler.cpp
@@ +445,5 @@
>        if (GlobalMemoryStatusEx(&statex)) {
>          char buffer[128];
>          int bufferLen;
> +
> +#define WRITE_STATEX_FIELD(field, paramName, conversionFunc)  \

Good call. This is getting really ugly.

Comment 13

[Justin Lebar (not reading bugmail)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/17e6e596ba28

Comment 14

[Mozilla RelEng Bot]

Try run for 530e2f252354 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=530e2f252354
Results (out of 71 total builds):
    success: 69
    warnings: 2
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-530e2f252354

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/17e6e596ba28

Comment 16

[u279076]

Is there something QA can do to verify this fix?

Comment 17

[Gian-Carlo Pascutto [:gcp]]

https://crash-stats.mozilla.com/ will contain "Available Page File" and "Available Physical Memory" fields in the details for a crash report.

Comment 18

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0

Verified on Windows XP in Firefox 12 beta 4. Crashed using Nightly tester tools, the  "Available Page File" and "Available Physical Memory" fields are displayed for windows reports in the Details pane.