Crash [@ libGLESv2!gl::Blit::initGeometry+0x00000098] (HANG in roboform exception handler)




7 years ago
2 years ago


(Reporter: morac, Unassigned)


({crash, hang})

Windows XP
crash, hang

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [blocklist?][please blocklist <= 7.2.3], crash signature)


(5 attachments)



7 years ago
Created attachment 506062 [details]
stack trace, hang "crash" log.

Since upgrading to Firefox 2.0b9, I've been getting random periodic hangs on my home laptop.  I have no problems on my work PC. 

I generated crash dump and the dump reports that there is an access violation in:
libGLESv2!gl::Blit::initGeometry(void)+0x98 [e:\builds\moz2_slave\rel-cen-w32-bld\build\obj-firefox\gfx\angle\angle-build\src\libglesv2\blit.cpp @ 168]

See attached stack trace and crash analysis.  I'll mention that I do have Roboform 7.0 installed and it shows up in the stack dump after the exception occurs, but I also have it installed on my work PC and it works fine there.  Since the hang isn't reproducible on demand (happens a few times a day), I can't tell if Roboform is causing it or not since it will work fine for a while with or without Roboform installed.  If the trace indicates the problem is with Roboform then please ignore this or coordinate with Siber Systems to get things working.

My laptop has an NVIDIA GeForce Go 6800 graphics card running driver which is the latest available for my Dell Inspiron 9300.

Other info:

WebGL RendererTransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 10 2011 19:54:16)
GPU Accelerated Windows1/1 Direct3D 9
Any particular pages that this happens on?

Comment 2

7 years ago
I haven't seen a pattern. One time it happened simply by doing a search on which makes no sense.  Like I said it doesn't happen all that often.  I've only seen it a few times recently.

Since the hang appears to be a on a memcpy and I see that it ends up somehow executing Roboform code, I'm thinking it might be a way that Roboform is hooking into the Firefox browser, but I'm not 100% sure about that.  It would be nice if there was a standard API for hooking into the browser since without it, Roboform can cause instabilities in Firefox.

Comment 3

7 years ago
I'll mention the copy of Firefox 4.0b9 on my work PC doesn't support hardware acceleration do to lack of drivers (or something), so it's likely a compatibility issue between hardware acceleration and Roboform.


7 years ago
Attachment #506062 - Attachment mime type: application/force-download → application/zip

Comment 4

7 years ago
morac: can you run:


in your windbg? i noticed that you tried to use .childdbg 1 and it failed, and i'm wondering why.

libGLESv2!gl::Blit::initGeometry+98 [e:\builds\moz2_slave\rel-cen-w32-bld\build\obj-firefox\gfx\angle\angle-build\src\libglesv2\blit.cpp @ 168]
23931098 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

EXCEPTION_RECORD:  0013c680 -- (.exr 0x13c680)
.exr 0x13c680
ExceptionAddress: 23931098 (libGLESv2!gl::Blit::initGeometry+0x00000098)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 00000000
Attempt to write to address 00000000



PROCESS_NAME:  firefox.exe

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid




CONTEXT:  0013c69c -- (.cxr 0x13c69c)
.cxr 0x13c69c
eax=88760827 ebx=2f662d40 ecx=00000008 edx=4fdd3c68 esi=239b4ba4 edi=00000000
eip=23931098 esp=0013c968 ebp=22ae53ec iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
23931098 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
Resetting default scope

WRITE_ADDRESS:  00000000 

libGLESv2!gl::Blit::initGeometry+0 [e:\builds\moz2_slave\rel-cen-w32-bld\build\obj-firefox\gfx\angle\angle-build\src\libglesv2\blit.cpp @ 147]
23931000 51              push    ecx

ADDITIONAL_DEBUG_TEXT:  Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]

LAST_CONTROL_TRANSFER:  from 23932e24 to 23931098



0013c968 23931098 libglesv2!gl::Blit::initGeometry+0x98
0013c980 23932e24 libglesv2!gl::Context::makeCurrent+0x164
0013cb00 23938d51 libglesv2!glMakeCurrent+0x31
0013cb10 22ab6d33 libegl!eglMakeCurrent+0xf3
0013cb44 10513f7a xul!mozilla::gl::GLContextEGL::MakeCurrentImpl+0x43
0013cb60 105b3599 xul!mozilla::gl::GLContextEGL::Init+0x1b
0013cb6c 1060e408 xul!mozilla::gl::GLContextEGL::CreateEGLPBufferOffscreenContext+0x2ea
0013ccfc 10670128 xul!mozilla::gl::GLContextProviderEGL::CreateOffscreen+0x29
0013cd14 108e53f0 xul!mozilla::WebGLContext::SetDimensions+0x29d
0013cd98 105d97f3 xul!nsHTMLCanvasElement::UpdateContext+0x57
0013cdc0 109833d8 xul!nsHTMLCanvasElement::GetContext+0x2dc
0013ce30 109a86f4 xul!nsIDOMHTMLCanvasElement_GetContext+0x13f
0013cf64 0060b0e6 mozjs!CallCompiler::generateNativeStub+0x106
0013d404 0060ba6d mozjs!js::mjit::ic::NativeCall+0x2d
0013d430 004fe854 mozjs!JSCompartment::wrap+0xd4
0013d468 005df8af mozjs!js::mjit::EnterMethodJIT+0x1f
0013d488 005df9dd mozjs!CheckStackAndEnterMethodJIT+0xfd
0013d4a0 005dfa5c mozjs!js::mjit::JaegerShot+0x6c
0013d4b8 0052be20 mozjs!js::RunScript+0x80
0013d4cc 0052d08b mozjs!js::Execute+0x41b
0013d524 004ec468 mozjs!JS_EvaluateUCScriptForPrincipals+0x88
0013d550 004ec39c mozjs!JS_EvaluateUCScriptForPrincipalsVersion+0x3c
0013d594 10177942 xul!nsJSContext::EvaluateString+0x1c2
0013d5e4 1011a155 xul!nsGlobalWindow::QueryInterface+0x195
0013d68c 100cf17e xul!nsCOMPtr_base::~nsCOMPtr_base+0xe
0013d750 1075c5f9 xul!nsGenericHTMLElement::GetAttrHelper+0x16
0013d760 1075ce9e xul!nsHTMLScriptElement::GetCharset+0x17
0013d770 1040fe73 xul!nsScriptLoader::ProcessScriptElement+0x28ec93
0013d77c 1040feb2 xul!nsScriptLoader::ProcessScriptElement+0x28ecd2
0013db10 1001bf8e xul!nsScriptElement::MaybeProcessScript+0xcf
0013db34 101dea82 xul!nsHTMLScriptElement::MaybeProcessScript+0x1d
0013dbe0 101deae2 xul!nsHTMLScriptElement::DoneAddingChildren+0x12
0013dbec 10013453 xul!nsHtml5TreeOpExecutor::RunScript+0x95
0013dc10 100a7501 xul!nsHtml5TreeOpExecutor::RunFlushLoop+0x351
0013dc40 101a44bc xul!nsHtml5ExecutorFlusher::Run+0xc

this feels a bit odd, i'm not used to seeing access violation/status breakpoint together.


.  0  Id: 5a0.1104 Suspend: 1 Teb: 7ffdf000 Unfrozen
ChildEBP RetAddr  
0013bc3c 7c90d98a ntdll!KiFastSystemCallRet
0013bc40 7c80ba5d ntdll!NtQueryVirtualMemory+0xc
0013bc60 7c80ba86 kernel32!VirtualQueryEx+0x1d
0013bc78 0a8aae7d kernel32!VirtualQuery+0x15
WARNING: Stack unwind information not available. Following frames may be wrong.
0013c2d0 0a8aac05 roboform!DllUnregisterServer+0xa1a4d
0013c2e4 0a8aabbe roboform!DllUnregisterServer+0xa17d5
0013c2f4 7c864191 roboform!DllUnregisterServer+0xa178e
0013c564 7c8438fa kernel32!UnhandledExceptionFilter+0x1c7
0013c56c 7c839b39 kernel32!BaseProcessStart+0x39
0013c594 7c9032a8 kernel32!_except_handler3+0x61
0013c5b8 7c90327a ntdll!ExecuteHandler2+0x26
0013c668 7c90e48a ntdll!ExecuteHandler+0x24
0013c668 23931098 ntdll!KiUserExceptionDispatcher+0xe
0013c978 23932e24 libGLESv2!gl::Blit::initGeometry(void)+0x98 [e:\builds\moz2_slave\rel-cen-w32-bld\build\obj-firefox\gfx\angle\angle-build\src\libglesv2\blit.cpp @ 168]

So, i *think* that roboform is doing something magical.
Keywords: crash, hang

Comment 5

7 years ago
i think we have two problems:
a. we crashed in gles. this should have been fatal, and our crash reporter should have reported it.

b. for some reason, roboform has a crash handler and it's:
1. greedy (catching things it shouldn't)
2. buggy (it hung -- you could use !analyze -v -hang to find out a bit more about it if you like).

i've cc'd some people from roboform who can hopefully look into at least 2-b. I also cc'd someone from our crash handling group, but i don't think there's anything he can do. this bug is filed by you for a, which is correct.
Summary: Hang caused by access violation libGLESv2!gl::Blit::initGeometry+0x00000098 → Crash [@ libGLESv2!gl::Blit::initGeometry+0x00000098] (HANG in roboform exception handler)
Sounds like roboform has an exception handler registered there somewhere, and they're doing something wrong. That's about all I guess from your WinDBG output.

Comment 7

7 years ago
yes, we do have exception handler, 
but it is supposed to work on RF itself.

i understand the pronlem here is not crash in RF
but that we catch somebody else's crashes, right?
If you are using SetUnhandledExceptionFilter, please stop immediately. That sets the process-wide exception handler, and removes our ability to report crashes from our users. If you must do exception handling internally, use inline SEH with __try / __except around specific call sites:

However, we would prefer you did not do any exception handling in the Firefox process, as anything you do is likely to make it more difficult for us to gather crash data.

Comment 9

7 years ago
(In reply to comment #4)
> morac: can you run:
> version
> vertarget
> in your windbg? i noticed that you tried to use .childdbg 1 and it failed, and
> i'm wondering why.

I just want to clarify a few things in case it caused a problem with the stack (and hence confusion):

1. The problem isn't a Firefox crash, but a hang or more specifically an apparent infinite exception loop.  Firefox 4.0b9 starts using 100% of the CPU (thread 0 according to Process Explorer -

2. I did not attach windbg to the Firefox process while it was running, I used Process Explorer to generate a mini dump file when Firefox hung. I also had to lower the Firefox process priority to be able to do anything on my system since it only has one single core CPU (not sure how that affects things).  I created a few dumps to make sure they were always more or less the same.  I then loaded said dumps into windbg for analysis.  That could explain why the ".childdbg 1" command failed since I wasn't debugging a running process.  I would like to do a proper windbg attach and hang analysis, but as the problem is not reproducible (it's only happened a handful of time and hasn't happened since I posted this bug report) that's tricky as I would need to run windbg all the time.  I supposed I could use windbg to attach to the Firefox process next time this happens.  I'll try and remember to do so.

Comment 10

7 years ago
yeah, .childdbg would fail on a minidump/non running process.

anyway, while it looked like a hang to you, technically firefox was supposed to be dead and was merely zombified by the extension doing something very wrong. but that's not something you (the end user) are expected to understand.

in the future, it's better to just attach w/ windbg directly. but i don't think we actually need anything else here. i should probably try to get a command into the steps so i can detect minidumps...

Comment 11

7 years ago
we veriufied that RoboForm does not catch Firefox crashes,
it only catches its own

Comment 12

7 years ago
Created attachment 513771 [details]
Another crash log. Attached to running process

I just got another hang while at
This time I attached windbg to Firefox 4.0b11 while it was still running.  After gathering data, I went back to the page, but it worked fine this time.  So it's a rare crash.

The crash was in:

libGLESv2!gl::Blit::initGeometry+0x6b [e:\builds\moz2_slave\rel-cen-w32-bld\build\obj-firefox\gfx\angle\angle-build\src\libglesv2\blit.cpp @ 168]

Again it appears as if Roboform (Everywhere 7.2.3) prevented the crash from being caught.  I've seen Firefox crash report handlers though.  My last reported crash in about:crashes is on 1/23/2011 ( if you're curious) so it doesn't block all crashes.  Only this one specific crash.  Maybe because it's in libGLESv2.dll?

   0  Id: bd0.d38 Suspend: 1 Teb: 7ffdf000 Unfrozen
ChildEBP RetAddr  
0013bdfc 7c90da0a ntdll!KiFastSystemCallRet
0013be00 7c8021eb ntdll!NtReadVirtualMemory+0xc
0013be1c 59a832fe kernel32!ReadProcessMemory+0x1b
0013be44 59a83b00 dbghelp!ReadMemoryRoutineLocal+0x3e
0013be74 59a841d7 dbghelp!ReadMemoryInternal+0x3e
0013bed4 59a843e3 dbghelp!IsFarCall+0x85
0013bf10 59a852b1 dbghelp!GetFunctionParameters+0x3a
0013bf58 59a85308 dbghelp!WalkX86Next+0x32b
0013bf80 59a8356d dbghelp!WalkX86+0x29
0013bfb8 0afae46b dbghelp!StackWalk64+0xdb
WARNING: Stack unwind information not available. Following frames may be wrong.
0013c620 0afae065 RoboForm!DllUnregisterServer+0x924bb
0013c634 0afae01e RoboForm!DllUnregisterServer+0x920b5
0013c644 7c864191 RoboForm!DllUnregisterServer+0x9206e
0013c8b4 7c8438fa kernel32!UnhandledExceptionFilter+0x1c7
0013c8bc 7c839b39 kernel32!BaseProcessStart+0x39
0013c8e4 7c9032a8 kernel32!_except_handler3+0x61
0013c908 7c90327a ntdll!ExecuteHandler2+0x26
0013c9b8 7c90e48a ntdll!ExecuteHandler+0x24
0013c9b8 43c3106b ntdll!KiUserExceptionDispatcher+0xe
0013ccc8 43c32cce libGLESv2!gl::Blit::initGeometry(void)+0x6b [e:\builds\moz2_slave\rel-cen-w32-bld\build\obj-firefox\gfx\angle\angle-build\src\libglesv2\blit.cpp @ 168]
0013ce40 43c38ed1 libGLESv2!gl::Context::makeCurrent(class egl::Display * display = 0x15ee20f0, class egl::Surface * surface = 0x15ee23a8)+0x11e [e:\builds\moz2_slave\rel-cen-w32-bld\build\obj-firefox\gfx\angle\angle-build\src\libglesv2\context.cpp @ 234]
0013ce50 38e5767b libGLESv2!glMakeCurrent(class gl::Context * context = 0x1050bba4, class egl::Display * display = 0x15ee20f0, class egl::Surface * surface = 0x15ee23a8)+0x31 [e:\builds\moz2_slave\rel-cen-w32-bld\build\obj-firefox\gfx\angle\angle-build\src\libglesv2\context.cpp @ 3576]
0013ce84 1050bba4 libEGL!eglMakeCurrent(void * dpy = 0x15ee20f0, void * draw = 0x15ee23a8, void * read = 0x15ee23a8, void * ctx = 0x14c42138)+0x11b [e:\builds\moz2_slave\rel-cen-w32-bld\build\obj-firefox\gfx\angle\angle-build\src\libegl\libegl.cpp @ 973]
0013cea0 105acffa xul!mozilla::gl::GLContextEGL::MakeCurrentImpl(int aForce = 0n275156127)+0x43 [e:\builds\moz2_slave\rel-cen-w32-bld\build\gfx\thebes\glcontextprovideregl.cpp @ 734]
0013ceac 10609479 xul!mozilla::gl::GLContextEGL::Init(void)+0x1b [e:\builds\moz2_slave\rel-cen-w32-bld\build\gfx\thebes\glcontextprovideregl.cpp @ 662]
0013cff4 10668c9f xul!mozilla::gl::GLContextEGL::CreateEGLPBufferOffscreenContext(struct gfxIntSize * aSize = 0x0013d058, struct mozilla::gl::ContextFormat * aFormat = 0x0013d060)+0x17f [e:\builds\moz2_slave\rel-cen-w32-bld\build\gfx\thebes\glcontextprovideregl.cpp @ 1887]
0013d00c 1085f7d7 xul!mozilla::gl::GLContextProviderEGL::CreateOffscreen(struct gfxIntSize * aSize = 0x0013d058, struct mozilla::gl::ContextFormat * aFormat = 0x0013d060)+0x29 [e:\builds\moz2_slave\rel-cen-w32-bld\build\gfx\thebes\glcontextprovideregl.cpp @ 2081]
0013d090 105d4666 xul!mozilla::WebGLContext::SetDimensions(int width = 0n300, int height = 0n150)+0x2ad [e:\builds\moz2_slave\rel-cen-w32-bld\build\content\canvas\src\webglcontext.cpp @ 453]
0013d0b8 1092a01c xul!nsHTMLCanvasElement::UpdateContext(class nsIPropertyBag * aNewContextOptions = 0x00000000)+0x57 [e:\builds\moz2_slave\rel-cen-w32-bld\build\content\html\content\src\nshtmlcanvaselement.cpp @ 611]
0013d128 10968a60 xul!nsHTMLCanvasElement::GetContext(class nsAString_internal * aContextId = 0x0013d16c, unsigned int64 * aContextOptions = 0x0013d158, class nsISupports ** aContext = 0x0013d14c)+0x2dc [e:\builds\moz2_slave\rel-cen-w32-bld\build\content\html\content\src\nshtmlcanvaselement.cpp @ 534]
0013d25c 00607166 xul!nsIDOMHTMLCanvasElement_GetContext(struct JSContext * cx = 0x1b12a640, unsigned int argc = 1, unsigned int64 * vp = 0x023001e0)+0x140 [e:\builds\moz2_slave\rel-cen-w32-bld\build\obj-firefox\js\src\xpconnect\src\dom_quickstubs.cpp @ 20395]
0013d6fc 00607aed mozjs!CallCompiler::generateNativeStub(void)+0x106 [e:\builds\moz2_slave\rel-cen-w32-bld\build\js\src\methodjit\monoic.cpp @ 667]

Comment 13

7 years ago
vadim: i think we're going to have to blocklist roboform. could you possibly show the code you use for catching exceptions?

Comment 14

7 years ago
Dumb question, but are crashes in libGLESv2.dll caught normally?

Comment 15

7 years ago
afaik they're just crashes. though we do tend to block crashy gl libraries if we can't find evidence it's our fault :)


7 years ago
Whiteboard: [blocklist?]

Comment 16

7 years ago
blocklist RoboForm for what?

catching crashes when it's installed?

RoboForm is apparently interested in its own crashes.

but our problem is to get a non-RoboForm crash,
to verify that RF does not catch it.

how can we do it?

how can we make another addon or Firefox to produce a test crash?

then i can tell you for sure what RF does in this case. is an extension that lets you crash Firefox at will.

Comment 18

7 years ago
I installed the crash me extension in a new profile and tested the following loads.  Note that Roboform will automatically attach (hook) itself to Firefox by default, even if the add-on is disabled.  There is an option to disable that which I did:

1. Minefield nightly.  With Roboform Mozilla add-on installed, Minefield hangs.  Without Roboform installed, the Mozilla Crash Reporter program displays.

2. Firefox 4.0b11.  With the Roboform Mozilla add-on installed, Firefox hangs, but without Roboform installed, the Mozilla Crash Reporter program displays.

3. Firefox 3.6.13.  With the Roboform Mozilla add-on installed, Firefox hangs, but without Roboform installed, the Mozilla Crash Reporter program displays.

In all cases when Roboform is installed, Firefox/Minefield simply hangs in some kind of infinite exception handler loop on a crash using 100% of the CPU.

So Roboform is doing something bad here.

There's basically two separate bugs here though:
1. Firefox is randomly crash in libGLESvs2.dll.
2. Roboform is causing Firefox to hang on a crash instead of opening the crash reporter.

I'm going to generate a simple crash dump using crash me in Firefox 3.6.13 and Minefield to show what Roboform is doing.

Comment 19

7 years ago
Created attachment 514118 [details]
Crash stacks with Roboform installed in Firefox 3.6.13 and Minefield

I'm running into problems trying to get data on this by running Firefox from withing the Windows debugger since if I attach the debugger to Firefox before Firefox crashes, the debugger intercepts it and it never goes into the Roboform exception handler.

So the only choice I had was to attach after Firefox/Minefield has hung.  I'm attaching to stack traces: one from Firefox 3.6.13 and one from the nightly Minefield load.

I also filed a bug with Roboform.  I don't remember having a problem with Roboform and Firefox prior to experiencing this.  I can only guess this is something new in Roboform v7.

I latest crash I found where Roboform was installed was back in June 29, 2010:

That was in Firefox 3.6.6 with Roboform v7 beta, but the add-on was version 6.9.98.

There are newer crashes with Roboform installed, but they are all plugin page crashes and apparently having Roboform installed doesn't affect those.  It only affects if Firefox itself crashes.

Comment 20

7 years ago
Created attachment 514121 [details]
Minefield hang with Roboform 7.2.3.

I realized I wasn't running the latest version of Roboform so I upgraded to 7.2.3 and repeated the hang.

It would be nice if symbols were available for Roboform.  Maybe they can provide a debug version?

Comment 21

7 years ago
1) i checked CrashMe -- it crashes as promised and RF did not come up to catch it

2) try this new version:

it has this bug fixed that may explain what was happening and why it is fixed now if RF is on the stack:

Crash: Fix cycling in RF crash catcher.
RF crash catcher could cycle in certain circumstances when unwinding stack.
Fixed now.
If RF does not find itself on the stack, it would send the crash to the next crash handler.

Comment 22

7 years ago
I downloaded 7.2.4 which is a definite improvement in that Firefox doesn't hang when it crashes, but it brings up the default windows crash window instead of bringing up Firefox's crash reporter tool.

If I uninstalled the Roboform add-on from Firefox, the Mozilla Crash Reporter pops up.

I'm not sure how the Mozilla Crash Reporter registers itself for handling exceptions, but apparently the "next crash handler" after Roboform is the default Windows crash handler.

Comment 23

7 years ago
this is how it works:

RF registers itself to handle crashes.

When crash happens, it checks the stack.

if RoboForm.dll is not on the stack, it returns from crash catcher,
which should give control to all other crash catchers.

Comment 24

7 years ago
you really shouldn't be registering an app exception handler. you should just be using local scoped SEH __try/__except.
Whiteboard: [blocklist?] → [blocklist?][please blocklist <= 7.2.3]

Comment 25

7 years ago
you may be right.

since Firefox is not Microsoft, you do not get 
to set the universal exception catcher, like MS does in Windows.

i thought it was possible to set some kinda universal catcher, 
but i am not sure.

if firefox organization so insists,
we can change our crash catching only to
local scoped SEH __try/__except,
in the scope of RoboForm.dll

plese confirm that this is a requirement.

Comment 26

7 years ago
Created attachment 514260 [details] [diff] [review]
check for null lock ptr

First off, I didn't read all of the above discussion so I could be completely off. What we have here is a write at address 0x0 in this line of code (gfx/angle/libGLESv2/Blit.cpp:168)

     memcpy(lockPtr, quad, sizeof(quad));

Which suggests that this lockPtr is null. It was obtained at the previous line (Blit.cpp:167)

     mQuadVertexBuffer->Lock(0, 0, &lockPtr, 0);

Where mQuadVertexBuffer is of type IDirect3DVertexBuffer9*.

So the problem here is that Direct3D's IDirect3DVertexBuffer9::Lock() method produces a null 'lock' pointer. Bas, do you know what this means and how we should react to it? My patch just bails out with a out_of_memory error.
Attachment #514260 - Flags: review?(bas.schouten)
Comment on attachment 514260 [details] [diff] [review]
check for null lock ptr

Looks good, looking at the surrounding code some whitespace around that if block would be appropriate though.
Attachment #514260 - Flags: review?(bas.schouten) → review+

Comment 30

7 years ago
Since I'm not sure where else to mention the Roboform issues (there should be a separate bug) I'll post here.  I upgraded to 7.2.5 which has "the fix" in it according to the release notes and I'm finding it's not 100% fixed.  Certain crashes will bring up the Mozilla dialog, but others will either bring up the Windows Crash dialog or hang.

The following are the results that occur with different "Crash Me" crashes in Firefox 3.6.13 and Minefield:

1. "Null pointer defer!" - Windows crash dialog (bad)
2. "Null function call!" - Firefox hangs using 100% of CPU in Minefield (very bad!).  
3. "Divide By Zero!" - Windows crash dialog (bad)
4. "Stack Overflow!" - Firefox hangs using 100% of CPU (very bad!)
5. "Pure Virtual Call!" - Mozilla Crash Reporter (good)
6. "Invalid Parameter to CRT Method!" - Mozilla Crash Reporter (good)
7. "ObjC Exception!" - Nothing (no crash)

So #5 and #6 work, but #1 through #4 do not.  Occasionally #1 also hangs and sometimes #2 runs the dumprep.exe (Windows crash dump generator) program.

Without Roboform install, all crashes (except #7 which doesn't crash) bring up the Mozilla crash reporter.

Comment 31

7 years ago
yes, we will fix it in the next release.

7.2.5 was to close to do such big changes.

Comment 32

7 years ago
Any possibility of getting the (In reply to comment #28)
> Comment on attachment 514260 [details] [diff] [review]
> check for null lock ptr
> Looks good, looking at the surrounding code some whitespace around that if
> block would be appropriate though.

Any possibility of getting this into the 4.0 release (block maybe)?

Comment 33

7 years ago
We will have a new release in 1 week or less, 
as we now do release on a weekly basis.
It will let all Firefox crashes to go Firefox.

So i hope you are not going to block RoboForm, 
plus RoboForm is more of an innocent bystander here in this crash.
(In reply to comment #32)
> Any possibility of getting the (In reply to comment #28)
> > Comment on attachment 514260 [details] [diff] [review]
> > check for null lock ptr
> > 
> > Looks good, looking at the surrounding code some whitespace around that if
> > block would be appropriate though.
> Any possibility of getting this into the 4.0 release (block maybe)?

I would also be in favor of just pushing my patch now, as it's not risky. We already apply a few custom patches to ANGLE.

Comment 35

7 years ago
Fixed in RF ver 7.2.6 that was released.

Now RF lets Firefox handle all crashes where RF is not on the stack.

Comment 36

7 years ago
(In reply to comment #35)
> Fixed in RF ver 7.2.6 that was released.
> Now RF lets Firefox handle all crashes where RF is not on the stack.

I can verify this is working correctly, at least with all the Crash me add-on tests.

Now if I get the libGLESv2 crash again Firefox should catch it.
Blocks: 639322


7 years ago
Crash Signature: [@ libGLESv2!gl::Blit::initGeometry+0x00000098]
Closing as this doesn't show up anymore in crash-stats for the last year.
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.