515830 - crash on winmo while running reftests

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

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++

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

moving to core gfx color management since that is where the crash is.  It could actually be a bug in core layout though.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

We get the width/height here: http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLCanvasElement.cpp#500

Maybe on windows mobile we return invalid data?

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

I am open to any other tips for getting more useful data.  This is an easy repro.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I woudl apply the patch from the other bug and see if you can still repro it.

Comment 8

[Joel Maher ( :jmaher ) (UTC -8)]

could you link that bug, I would be happy to give it a try.  Thanks.

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

oh sorry, that was clint who was looking at the other one -- bug 514334.

Comment 10

[Joel Maher ( :jmaher ) (UTC -8)]

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
HTCNAV DLL_THREAD_ATTACH
Data Abort: Thread=8b90f8c4 Proc=80458840 'fennec.exe'
AKY=00400001 PC=7a30c3ec(xul.dll+0x002fc3ec) RA=7b16d360(xul.dll+0x0115d360) BVA=2e000004 FSR=00000007
HTCNAV DLL_THREAD_DETACH
HTCNAV DLL_PROCESS_DETACH


I assume we can move this bug back to fennec->windos mobile?

Comment 11

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 12

[Daniel Veditz [:dveditz]]

Can this be closed now? bug 506926 has landed on 1.9.2 and bug 514334 has landed on trunk.

Comment 13

[Joel Maher ( :jmaher ) (UTC -8)]

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.