Closed Bug 677579 Opened 14 years ago Closed 6 years ago

Crash in google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread at kernelbase.dll@0x3658f

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression)

Crash Data

It is #7 top browser crasher in 7.0a2 and #33 in 8.0a1. Signature kernelbase.dll@0x3658f UUID def2c5ab-dd8a-46cb-baa3-0630d2110806 Date Processed 2011-08-06 06:01:42.453873 Uptime 1765 Install Age 13.8 hours since version was first installed. Install Time 2011-08-05 23:10:05 Product Firefox Version 8.0a1 Build ID 20110731030821 Release Channel nightly Branch 2.2 OS Windows NT OS Version 6.1.7601 Service Pack 1 CPU x86 CPU Info GenuineIntel family 6 model 42 stepping 7 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0xffffffff83a00000 User Comments App Notes AdapterVendorID: 8086, AdapterDeviceID: 0126, AdapterDriverVersion: 8.15.10.2342 D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ WebGL? EGL? EGL+ GL Context? GL Context+ WebGL+ Frame Module Signature [Expand] Source 0 ntdll.dll ZwWaitForSingleObject 1 ntdll.dll ZwWaitForSingleObject 2 KERNELBASE.dll KERNELBASE.dll@0x3658f 3 kernel32.dll kernel32.dll@0x11193 4 kernel32.dll kernel32.dll@0x11147 5 xul.dll google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:764 6 xul.dll google_breakpad::ExceptionHandler::HandleException toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:521 7 kernel32.dll kernel32.dll@0x5003e 8 ntdll.dll RtlKnownExceptionFilter 9 ntdll.dll ?? ::FNODOBFM::`string' 10 ntdll.dll _RtlUserThreadStart More reports at: https://crash-stats.mozilla.com/report/list?signature=kernelbase.dll%400x3658f
Is this a new signature? When did it start appearing? Something is a bit broken here, because this is showing a crash on the minidump handler thread, but the crash is almost certainly happening elsewhere and the minidump handler thread is being blamed incorrectly. There are also a bunch of different crash reasons, which makes me think that there is a tooling issue.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #1) > Is this a new signature? No, but it's only #168 top browser crasher in 6.0. > When did it start appearing? No clear rise in 7.0a2 (90,000 ADU) (the two spikes are caused by consecutive startup crashes): https://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=kernelbase.dll%400x3658f&version=Firefox%3A7.0a2 Spike from July 30 in 8.0a1 (60,000 ADU): https://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=kernelbase.dll%400x3658f&version=Firefox%3A8.0a1
I did some analysis in bug 677579 (which is very similar, but Win64), and found that there's an exception context in the dump, but Breakpad is failing to read it, so it starts from the top of the crashing thread stack instead (which of course includes the minidump writing parts of Breakpad).
Component: Breakpad Integration → General
Product: Toolkit → Core
QA Contact: breakpad.integration → general
(In reply to Scoobidiver from comment #0) > It is #7 top browser crasher in 7.0a2 and #33 in 8.0a1. > > Signature kernelbase.dll@0x3658f > bp-def2c5ab-dd8a-46cb-baa3-0630d2110806 The best stack I can get out of this is: 0030c838 839f6a7c xul!FastConvertYUVToRGB32Row_SSE(unsigned char * y_buf = <Memory access error>, unsigned char * u_buf = <Memory access error>, unsigned char * v_buf = <Memory access error>, unsigned char * rgb_buf = <Memory access error>, int width = <Memory access error>)+0x1d [e:\builds\moz2_slave\m-cen-w32-ntly\build\gfx\ycbcr\yuv_row_win.cpp @ 32] WARNING: Frame IP not in any known module. Following frames may be wrong. 0030c83c 839fff50 0x839f6a7c 0030c840 0030c89c 0x839fff50 0030c844 0030c85c 0x30c89c 0030c89c 56f8dd41 0x30c85c 0030c8f0 56cb78cf xul!mozilla::layers::PlanarYCbCrImageD3D9::GetAsSurface(void)+0x6a [e:\builds\moz2_slave\m-cen-w32-ntly\build\gfx\layers\d3d9\imagelayerd3d9.cpp @ 562] 0030c908 56fba7ef xul!mozilla::layers::ImageContainerD3D10::GetCurrentAsSurface(struct nsIntSize * aSize = 0x0030c95c)+0x67 [e:\builds\moz2_slave\m-cen-w32-ntly\build\gfx\layers\d3d10\imagelayerd3d10.cpp @ 159] 0030c9ac 56fbb009 xul!nsLayoutUtils::SurfaceFromElement(class nsIDOMElement * aElement = 0x13e60004, unsigned int aSurfaceFlags = 0xd7f04c0)+0x2ae [e:\builds\moz2_slave\m-cen-w32-ntly\build\layout\base\nslayoututils.cpp @ 3927] 0030c9f4 56fbb69e xul!mozilla::WebGLContext::DOMElementToImageSurface(class nsIDOMElement * imageOrCanvas = 0x13e6ca08, class gfxImageSurface ** imageOut = 0x0030ca10, int * format = 0x0030ca34)+0x38 [e:\builds\moz2_slave\m-cen-w32-ntly\build\content\canvas\src\webglcontextgl.cpp @ 3562] 0030ca14 57104021 xul!mozilla::WebGLContext::TexImage2D_dom(unsigned int target = 0xde1, int level = 0, unsigned int internalformat = 0x1908, unsigned int format = 0x1908, unsigned int type = 0x1401, class nsIDOMElement * elt = 0x13e6ca08)+0x23 [e:\builds\moz2_slave\m-cen-w32-ntly\build\content\canvas\src\webglcontextgl.cpp @ 4461] 0030caa8 0b5a2435 xul!nsIDOMWebGLRenderingContext_TexImage2D(struct JSContext * cx = 0x0ca92400, unsigned int argc = 6, unsigned int64 * vp = 0x06870418)+0x175 [e:\builds\moz2_slave\m-cen-w32-ntly\build\obj-firefox\dist\include\customqs_webgl.h @ 330] 0030caf8 5ca93953 0xb5a2435 0030cb0c 06870038 mozjs!js::mjit::EnterMethodJIT(struct JSContext * cx = <Memory access error>, class js::StackFrame * fp = <Memory access error>, void * code = <Memory access error>, class js::Value * stackLimit = <Memory access error>)+0x33 [e:\builds\moz2_slave\m-cen-w32-ntly\build\js\src\methodjit\methodjit.cpp @ 687]
The root cause for the bogus signatures is the same as bug 677579. The crashes themselves are all over the place.
I mean bug 677580, of course.
When Socorro 2.2.2 is rolled out to production (probably tomorrow) this should go away. (These crashes will wind up with new signatures, and they're not all the same.) We can verify this by reprocessing some of the crashes and checking the signatures/stacks.
I filed bug 689579 to get crashes with this signature reprocessed, so when that's fixed they should all be reassigned to new signatures. I'm fairly certain that this isn't one consistent crash, it's a set of unrelated crashes being grouped under the same signature because of the processing failure.
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.