Closed Bug 515830 Opened 15 years ago Closed 14 years ago

crash on winmo while running reftests


(Core :: Graphics, defect)

Windows Mobile 6 Professional
Not set



Tracking Status
fennec 1.0-wm+ ---


(Reporter: jmaher, Unassigned)



(Keywords: crash, Whiteboard: [ccbr])

while running reftest on the latest 192 (private build) of fennec on winmo, I run into a crash with this call stack before we even launch the display

>	xul.dll!gfxContext::gfxContext(gfxASurface* surface = 0x00000000) Line: 62, Byte Offsets: 0x24	C++
 	xul.dll!nsCanvasRenderingContext2D::InitializeWithSurface(nsIDocShell* docShell = 0x00000000, gfxASurface* surface = 0x00000000, int width = 3840792, int height = 1000) Line: 905, Byte Offsets: 0xc8	C++
 	xul.dll!nsCanvasRenderingContext2D::SetDimensions(int width = 0, int height = 0) Line: 891, Byte Offsets: 0x114	C++
 	xul.dll!nsHTMLCanvasElement::UpdateContext(void) Line: 506, Byte Offsets: 0x60	C++
 	xul.dll!nsHTMLCanvasElement::GetContext(nsAString_internal& aContextId = {...}, nsISupports** aContext = 0x00000000) Line: 479, Byte Offsets: 0x1f0	C++
 	xul.dll!nsIDOMHTMLCanvasElement_GetContext(JSContext* cx = 0x003a9b10, unsigned int argc = 0, int* vp = 0x00000000) Line: 12304, Byte Offsets: 0x1fc	C++
 	js3250.dll!js_Interpret(JSContext* cx = 0x003a9b10) Line: 2179, Byte Offsets: 0x5f74	C++
 	js3250.dll!js_Invoke(JSContext* cx = 0x003a9b10, unsigned int argc = 0, int* vp = 0x00000000, unsigned int flags = 3840792) Line: 1379, Byte Offsets: 0x614	C++
 	js3250.dll!js_InternalInvoke(JSContext* cx = 0x003a9b10, JSObject* obj = 0x00000000, int fval = 0, unsigned int flags = 3840792, unsigned int argc = 2, int* argv = 0x01bd1600, int* rval = 0x29bbe71c) Line: 1434, Byte Offsets: 0x74	C++
 	js3250.dll!JS_CallFunctionValue(JSContext* cx = 0x003a9b10, JSObject* obj = 0x00000000, int fval = 0, unsigned int argc = 3840792, int* argv = 0x01bd1600, int* rval = 0x29bbe71c) Line: 5133, Byte Offsets: 0x2c	C++
 	xul.dll!nsJSContext::CallEventHandler(nsISupports* aTarget = 0x00000000, void* aScope = 0x00000000, void* aHandler = 0x003a9b18, nsIArray* aargv = 0x003aba94, nsIVariant** arv = 0x29bbe798) Line: 2097, Byte Offsets: 0x218	C++
 	xul.dll!nsGlobalWindow::RunTimeout(nsTimeout* aTimeout = 0x00000000) Line: 7937, Byte Offsets: 0x53c	C++
 	xul.dll!nsGlobalWindow::TimerCallback(nsITimer* aTimer = 0x003a9b10, void* aClosure = 0x00000000) Line: 8272, Byte Offsets: 0x1c	C++
 	xul.dll!nsTimerImpl::Fire(void) Line: 428, Byte Offsets: 0x154	C++
 	xul.dll!nsTimerEvent::Run(void) Line: 521, Byte Offsets: 0x40	C++
 	xul.dll!nsThread::ProcessNextEvent(int mayWait = 0, int* result = 0x00000000) Line: 527, Byte Offsets: 0x170	C++
 	xul.dll!NS_ProcessNextEvent_P(nsIThread* thread = 0x003a9b10, int mayWait = 0) Line: 230, Byte Offsets: 0x38	C++
 	xul.dll!nsBaseAppShell::Run(void) Line: 170, Byte Offsets: 0x48	C++
 	xul.dll!nsAppStartup::Run(void) Line: 183, Byte Offsets: 0x38	C++
 	xul.dll!XRE_main(int argc = 3840784, char** argv = 0x00000000, nsXREAppData* aAppData = 0x00000000) Line: 3481, Byte Offsets: 0x2084	C++
tracking-fennec: --- → ?
Component: Windows Mobile → GFX: Color Management
Product: Fennec → Core
QA Contact: mobile-windows → color-management
moving to core gfx color management since that is where the crash is.  It could actually be a bug in core layout though.
I don't see anything that would implicate color management. My guess is the crash is caused by a NULL surface being passed into InitializeWithSurface. This could be because we are passing in a 0, 0 width and height. Then again, I'm not sure I trust the stack values because, the docShell is NULL too.
Component: GFX: Color Management → Graphics
QA Contact: color-management → thebes
We get the width/height here:

Maybe on windows mobile we return invalid data?
That stack is bogus; my guess is that this is the same problem as in the other reftests crash bug, where we're simply running out of memory and not handling that gracefully.
I am open to any other tips for getting more useful data.  This is an easy repro.
(In reply to comment #5)
> I am open to any other tips for getting more useful data.  This is an easy
> repro.

I guess we basically want to check if malloc is failing. I'm not sure what the easiest way for you to do this on winmo is but if you need suggestions ask.
I woudl apply the patch from the other bug and see if you can still repro it.
could you link that bug, I would be happy to give it a try.  Thanks.
oh sorry, that was clint who was looking at the other one -- bug 514334.
Depends on: 514334, 508860
the patch from bug 514334 resolves the crash I was seeing.  The problem is that Fennec just terminates and never actually launches to run a test.

I also see an exception in gwes.exe in the debugger.  I always expect to see 3 handled exceptions, but they are usually from fennec.exe:
Data Abort: Thread=8b90f8c4 Proc=80458840 'fennec.exe'
AKY=00400001 PC=7b270a64(xul.dll+0x01260a64) RA=7b2707cc(xul.dll+0x012607cc) BVA=2ef7d000 FSR=00000807
RaiseException: Thread=8b90f8c4 Proc=80457850 'gwes.exe'
AKY=00400021 PC=03f683bc(coredll.dll+0x0001e3bc) RA=8001c06c(NK.EXE+0x0001c06c) BVA=00000001 FSR=00000001
Data Abort: Thread=8b90f8c4 Proc=80458840 'fennec.exe'
AKY=00400001 PC=7a30c3ec(xul.dll+0x002fc3ec) RA=7b16d360(xul.dll+0x0115d360) BVA=2e000004 FSR=00000007

I assume we can move this bug back to fennec->windos mobile?
so we can close this bug once that patch lands on m-c and 192.  The issue I am runing into is already filed in bug 506926.
Whiteboard: [ccbr]
tracking-fennec: ? → 1.0-wm+
Severity: normal → critical
Keywords: crash
Can this be closed now? bug 506926 has landed on 1.9.2 and bug 514334 has landed on trunk.
and we don't support windows mobile as a platform anymore.  I think enough stuff has changed in the last 6 months that this bug would be invalid anyway.
Closed: 14 years ago
Resolution: --- → FIXED
Resolution: FIXED → INVALID
You need to log in before you can comment on or make changes to this bug.