crash in [@ JSAutoCompartment::JSAutoCompartment(JSContext*, JSObject*) | AutoScriptEvaluate::StartEvaluating(JS::Handle<JSObject*>) ]

RESOLVED WORKSFORME

Status

()

defect
--
critical
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: ychung, Unassigned)

Tracking

({crash})

Trunk
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.2 affected, b2g-master affected)

Details

(Whiteboard: [b2g-crash], crash signature)

Attachments

(1 attachment)

Reporter

Description

4 years ago
This bug was filed from the Socorro interface and is 
report bp-fa2f370d-a128-403c-9aee-58a9d2150213.
=============================================================
When the user tries to enter password for FFOX account with screen reader on.

Repro Steps:
1) Update a Flame to 20150212064620.
2) Enable Screen Reader on Settings > Accessibility.
3) Go to Settings > Firefox Accounts > Create Account or Sign In.
4) Enter an email address, and select Next.
5) Tap on the password input field to enter password.

Actual:
Keyboard never shows up, and the crash happens.

Expected:
The keyboard pops up, so the user can enter the password.

Environmental Variables:
Device: Flame 3.0
Build ID: 20150212064620
Gaia: 2a2b008f9ae957fe19ad540d233d86b5c0b6829e
Gecko: 81f979b17fbd
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Repro frequency: 5/5
See attached: logcat
Reporter

Comment 1

4 years ago
This issue also reproduces on Flame 2.2.

Result: A crash occurs when the user taps the password input field. 

Environmental Variables:
Device: Flame 2.2
BuildID: 20150212133255
Gaia: ab9029f2b203e2a36e8f81edd17fa5ff81c874b5
Gecko: b1d3839680fb
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

-------------------------------------
Unable to reproduce on Flame 2.1. When the user tries to enter the email address on step #4, the user is returned to the previous screen when hitting any key on the keyboard. Unable to enter any email address before reaching the password page.

Environmental Variables:
Device: Flame 2.1
BuildID: 20150212084020
Gaia: 88084bc7ef5ba6627dd09c774ef2f7fa96cbed71
Gecko: eafa6c73ef0b
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Whiteboard: [3.0-Daily-Testing]
Nominating 2.2? since this is a reproducible crash.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
https://crash-stats.mozilla.com/report/index/6b8d44d7-a18a-45a5-a070-d23f32150218

Crashing Thread
Frame 	Module 	Signature 	Source
0 	libxul.so 	JSAutoCompartment::JSAutoCompartment(JSContext*, JSObject*) 	js/src/vm/Shape.h
1 	libxul.so 	AutoScriptEvaluate::StartEvaluating(JS::Handle<JSObject*>) 	/builds/slave/b2g_m-cen_flm-kk_ntly-00000000/build/objdir-gecko/dist/include/mozilla/Maybe.h:386
2 	libxul.so 	nsXPCWrappedJSClass::BuildPropertyEnumerator(XPCCallContext&, JSObject*, nsISimpleEnumerator**) 	js/xpconnect/src/XPCWrappedJSClass.cpp
3 	libxul.so 	nsXPCWrappedJS::GetEnumerator(nsISimpleEnumerator**) 	js/xpconnect/src/XPCWrappedJS.cpp
4 	libxul.so 	mozilla::a11y::xpcAccessible::GetState(unsigned int*, unsigned int*) 	accessible/xpcom/xpcAccessible.cpp
5 	libxul.so 	NS_InvokeByIndex 	xpcom/reflect/xptcall/md/unix/xptcinvoke_arm.cpp
6 	libxul.so 	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 	js/xpconnect/src/XPCWrappedNative.cpp
7 	libxul.so 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp
8 	libxul.so 	js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) 	js/src/jscntxtinlines.h
9 	libxul.so 	js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) 	js/src/vm/Interpreter.cpp
10 	libxul.so 	js::jit::DoCallFallback 	js/src/jit/BaselineIC.cpp
11 		@0xb342a70a 	

More reports:
https://crash-stats.mozilla.com/report/list?product=B2G&signature=JSAutoCompartment%3A%3AJSAutoCompartment%28JSContext*%2C+JSObject*%29+|+AutoScriptEvaluate%3A%3AStartEvaluating%28JS%3A%3AHandle%3CJSObject*%3E%29#tab-reports
Crash Signature: [@ libxul.so@0x1078560 | libxul.so@0x107853f | libxul.so@0x39cf65 | libxul.so@0x602671 | libxul.so@0x182678e | libxul.so@0x601975 | libxul.so@0x601b6b | libxul.so@0x39cf65 | libxul.so@0x18266fe | libxul.so@0x15a7e09] → [@ libxul.so@0x1078560 | libxul.so@0x107853f | libxul.so@0x39cf65 | libxul.so@0x602671 | libxul.so@0x182678e | libxul.so@0x601975 | libxul.so@0x601b6b | libxul.so@0x39cf65 | libxul.so@0x18266fe | libxul.so@0x15a7e09] [@ JSAutoCompartment::JSAutoCompartme…
Summary: crash in libxul.so@0x1078560 | libxul.so@0x107853f | libxul.so@0x39cf65 | libxul.so@0x602671 | libxul.so@0x182678e | libxul.so@0x601975 | libxul.so@0x601b6b | libxul.so@0x39cf65 | libxul.so@0x18266fe | libxul.so@0x15a7e09 → crash in [@ JSAutoCompartment::JSAutoCompartment(JSContext*, JSObject*) | AutoScriptEvaluate::StartEvaluating(JS::Handle<JSObject*>) ]
Whiteboard: [3.0-Daily-Testing] → [b2g-crash]
Component: Disability Access APIs → JavaScript Engine
Version: unspecified → Trunk
Naveed, can you please help with an assignee on this one?
blocking-b2g: 2.2? → 2.2+
Flags: needinfo?(nihsanullah)
While the top of stack points at JS it happens to be a simple class header method call. The XPCOM code underneath it is more likely to ferret out the issue. Perhaps bholley might have some ideas?
Flags: needinfo?(nihsanullah)
Flags: needinfo?(bobbyholley)
Looks like we're entering the compartment of a null object. Maybe the WrappedJS has been Cycle collected or something?

http://hg.mozilla.org/mozilla-central/annotate/9696d1c4b3ba/js/xpconnect/src/XPCWrappedJS.cpp#l599

But looking at the stack, I don't see how we get from mozilla::a11y::xpcAccessible::GetState to nsXPCWrappedJS::GetEnumerator. This looks like accessibility funkiness, so I'm going to pass this one to alexander.
Flags: needinfo?(bobbyholley) → needinfo?(surkov.alexander)
I don't have better explanation other than cycle collection issue. CC'ing Yura to see if he can reproduce it.
Flags: needinfo?(surkov.alexander) → needinfo?(yzenevich)
(In reply to alexander :surkov from comment #7)
> I don't have better explanation other than cycle collection issue. CC'ing
> Yura to see if he can reproduce it.

Do you have an explanation of why we're ending up in nsXPCWrappedJS::GetEnumerator in the first place?
no. I would say there's something wrong with stack but I don't know much about xpconnect.
I can't seem to reproduce it with latest nightly gecko and gaia.
Flags: needinfo?(yzenevich) → needinfo?(ychung)
Reporter

Comment 11

4 years ago
I did not reproduce this issue on the latest nightly Flame Master either.

Result: No crash occurs.

Device: Flame Master (KK, 319mb, full flash)
Build ID: 20150224010314
Gaia: 31ac1cd7a029d5e46dd7c92537b5c973c5d9826e
Gecko: 368c62292249
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
===================================================
This issue still occurs on Flame 2.2.

Device: Flame 2.2 (KK, 319mb, full flash)
Build ID: 20150224002637
Gaia: 8e98fe665f3821d10d4d982cbb14cbe5b94d0be5
Gecko: 2b70d9d62799
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Flags: needinfo?(ychung)
Let's get a reverse regression window then.
Reporter

Updated

4 years ago
QA Contact: ychung
Reporter

Comment 13

4 years ago
Unable to get reverse regression window. I encountered the crash again on today's nightly Flame Master build.

Result: The device crashes when the cursor is placed on the input field for the password.

Device: Flame Master (KK, 319mb, full flash)
Build ID: 20150225010244
Gaia: f6bfd854fe4746f21bc006eac145365e85f98808
Gecko: 0a8b3b67715a
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
Flags: needinfo?(ktucker)
Flags: needinfo?(ktucker)
Keywords: regression
Reporter

Comment 14

4 years ago
The earliest build I could reproduce the crash is the following:

Environmental Variables:
Device: Flame 2.2
BuildID: 20141103133804
Gaia: 73eeaa23172c26e732972c318ea6aab20e0e1cae
Gecko: d11d6fdc785f
Version: 36.0a1 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Prior to this build, it is impossible to type anything in the email input field when the user tries to log in. When a key is pressed from the keyboard, the keyboard disappears and the page goes back to the previous screen. The user is unable to proceed afterwards.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
I'm not sure if it's the same crash, could you provide the crash id?
The reason why I mention this is because I don't see a crash report on socorro.
Reporter

Comment 17

4 years ago
(In reply to Yeojin Chung [:YeojinC] from comment #14)
> The earliest build I could reproduce the crash is the following:
> 
> Environmental Variables:
> Device: Flame 2.2
> BuildID: 20141103133804
> Gaia: 73eeaa23172c26e732972c318ea6aab20e0e1cae
> Gecko: d11d6fdc785f
> Version: 36.0a1 (2.2) 
> Firmware Version: v18D-1
> User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
> 
> Prior to this build, it is impossible to type anything in the email input
> field when the user tries to log in. When a key is pressed from the
> keyboard, the keyboard disappears and the page goes back to the previous
> screen. The user is unable to proceed afterwards.

You're correct, Naoki. I got a different crash report for this build:

https://crash-stats.mozilla.com/report/index/c02fc399-82c1-4ee2-b85f-6c5202150227
Flags: needinfo?(ychung)
Ok.  Thanks.  I don't see this crash this week.  I'm closing this off as a WFM; we should open a new bug for the new crash.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.