882697 - Android crash in ExecuteRegExpImpl

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Robert Kaiser]

This bug was filed from the Socorro interface and is 
report bp-954cc715-34f4-4755-9ab2-3ef522130613 .
============================================================= 

This has been rising on 21 and 22 on mostly Samsung devices in yesterday's data.

0 		@0x58c82044 	
1 	libxul.so 	NS_IsMainThread_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:137
2 	libxul.so 	ExecuteRegExpImpl 	js/src/builtin/RegExp.cpp:128
3 	libxul.so 	js::ExecuteRegExp 	js/src/builtin/RegExp.cpp:598
4 	libxul.so 	XPC_WN_GetterSetter 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1465
5 	libxul.so 	ExecuteRegExp 	js/src/builtin/RegExp.cpp:626
6 	libxul.so 	js::regexp_test 	js/src/builtin/RegExp.cpp:672
7 	libxul.so 	regexp_test_impl 	js/src/builtin/RegExp.cpp:675
8 	libxul.so 	js::mjit::EnterMethodJIT 	js/src/methodjit/MethodJIT.cpp:1042
9 	libxul.so 	js::mjit::JaegerShotAtSafePoint 	js/src/methodjit/MethodJIT.cpp:1100
10 	libxul.so 	js::Interpret 	js/src/jsinterp.cpp:1375
11 	libxul.so 	libxul.so@0xd01743 	
12 	libxul.so 	js::ion::SnapshotIterator::SnapshotIterator 	js/src/ion/IonFrames.cpp:880


Devices for 21.0 in yesterday's data:
NS_IsMainThread_P() 	311
Samsung GT-I9100 	125
Samsung GT-P6200 	57
Samsung GT-P6800 	20
HTC One X 	20
Samsung GT-P6200L 	15
Samsung GT-I9100P 	11
Samsung GT-N7000 	11
Samsung SGH-I777 	9
Samsung SGH-S959G 	8
LGE LG-P880 	8
Samsung GT-P6210 	6
Samsung SCH-R760 	3
Samsung GT-I9100T 	2
Sony SGPT12 	1
YIFANG PMP5580C 	1
Samsung SHW-M250S 	1
Samsung SHW-M250L 	1
Samsung SC-02D 	1
Samsung SGH-T869 	1
Samsung GT-P6201 	1
Motorola MZ505 	1
LGE LG-P895 	1
HTC EVO 3D X515m 	1
Samsung GT-I9100M 	1
Samsung GT-N7000B 	1
Samsung ISW11SC 	1
Samsung GT-P6810 	1
ASUS Transformer Pad TF300T 	1
Samsung SC-02C 	1


More reports at https://crash-stats.mozilla.com/report/list?signature=NS_IsMainThread_P%28%29

Comment 1

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) [away until early June] from comment #0)
> This has been rising on 21 and 22 on mostly Samsung devices in yesterday's
> data.
Not 22.0 Beta. Likely by an external cause like an URL.

> 8 	libxul.so 	js::mjit::EnterMethodJIT
Another JIT crash?

Comment 2

[Robert Kaiser]

(In reply to Scoobidiver from comment #1)
> (In reply to Robert Kaiser (:[e-mail]) [away until early June] from
> comment #0)
> > This has been rising on 21 and 22 on mostly Samsung devices in yesterday's
> > data.
> Not 22.0 Beta.

It did there as well. But I didn't spot before that the signature is different: https://crash-stats.mozilla.com/report/list?signature=NS_IsMainThread%28%29

> Likely by an external cause like an URL.

There are no URLs on this unfortunately.

> > 8 	libxul.so 	js::mjit::EnterMethodJIT
> Another JIT crash?

Gah, didn't see that. Probably WONTFIX or INVALID in this case.

Comment 3

[Scoobidiver (away)]

It's #11 top crasher in 21.0 and #10 in 22.0b5.

Comment 4

[Scoobidiver (away)]

This signature drops off in 22.0 and is now only #32 crasher.

Comment 5

[Robert Kaiser]

(In reply to Scoobidiver from comment #4)
> This signature drops off in 22.0 and is now only #32 crasher.

This sounds good but IMHO we should wait for at least 3-4 days of data before we make moves of the topcrash keyword or really firm statements about what what data for a release looks like. The very early adopters, esp. now where we do not turn on updates to 100% of our users in the first days, often give us a different picture than the normal population.

Comment 6

[Scoobidiver (away)]

The stack trace in 23.0 Beta looks like:
Frame 	Module 	Signature 	Source
0 		@0x47498550 	
1 	libxul.so 	ExecuteRegExpImpl 	js/src/builtin/RegExp.cpp
2 	libxul.so 	js::ExecuteRegExp 	js/src/builtin/RegExp.cpp
3 	libxul.so 	ExecuteRegExp 	js/src/builtin/RegExp.cpp
4 	libxul.so 	js::regexp_test(JSContext*, unsigned int, JS::Value*) 	js/src/builtin/RegExp.cpp
5 		@0x474912da

It might be a new form of bug 763864.

More reports at:
https://crash-stats.mozilla.com/report/list?product=FennecAndroid&signature=ExecuteRegExpImpl

Comment 7

[Scoobidiver (away)]

It's #15 crasher in 22.0 and #9 in 23.0b2.

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

Naveed can you look into this topcrasher?

Comment 9

[Jan de Mooij [:jandem]]

This is a crash in Yarr code (WebKit regexp engine we use).

It also looks like this is fixed in 24 (Scoobidiver/Kairo can you guys confirm I'm using Socorro correctly?). Unfortunately, I don't see any interesting Yarr changes in Firefox 24.

Sean can you take a look? Could bug 871444 or bug 877021 be related maybe? We may be able to disassemble some instructions around the instruction pointer but I need ARM help from mjrosenb for that.

Comment 10

[Jan de Mooij [:jandem]]

I looked at about 50 crashes or so with Fennec 23, 99% of them have js::regexp_test on the stack (see also comment 6).

Comment 11

[Scoobidiver (away)]

(In reply to Jan de Mooij [:jandem] from comment #9)
> It also looks like this is fixed in 24 (Scoobidiver/Kairo can you guys
> confirm I'm using Socorro correctly?).
Aurora and Nightly channels with about 1.5 kADU are not affected but 24.0 and 25.0 may be affected when in Beta (80 kADU) or Release (2 MADU).

Comment 12

[Sean Stangl [:sstangl]]

(In reply to Jan de Mooij [:jandem] from comment #9)
> Sean can you take a look? Could bug 871444 or bug 877021 be related maybe?

Those patches landed for 24, but the crashes are in 22. Could we get a user-submitted website that causes such a crash, or track regexp + input as part of the crash reporter?

Comment 13

[Sean Stangl [:sstangl]]

This bug is most likely a continuation of Bug 763864.

Comment 14

[Scoobidiver (away)]

(In reply to Sean Stangl [:sstangl] from comment #13)
> This bug is most likely a continuation of Bug 763864.
This bug happens only on ARMv7 devices while bug 763864 was on ARMv6 devices.

Comment 15

[Sean Stangl [:sstangl]]

(In reply to Scoobidiver from comment #14)
> This bug happens only on ARMv7 devices while bug 763864 was on ARMv6 devices.

Do we have some user-submitted URLs that can reproduce the crash?

Comment 16

[Jan de Mooij [:jandem]]

(In reply to Sean Stangl [:sstangl] from comment #12)
> Those patches landed for 24, but the crashes are in 22.

The crashes seem to be gone in 24 so I wondered if one of the patches fixed / worked around it; seems unlikely though..

Comment 17

[Sean Stangl [:sstangl]]

(In reply to Jan de Mooij [:jandem] from comment #16)
> The crashes seem to be gone in 24 so I wondered if one of the patches fixed
> / worked around it; seems unlikely though..

Yeah, very unlikely.

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

ExecuteRegExpImpl signature is at #11 in FF23.0b4 so untracking and removing the keyword.

Comment 19

[Scoobidiver (away)]

(In reply to [e-mail] [:lsblakk] from comment #18)
> ExecuteRegExpImpl signature is at #11 in FF23.0b4 so untracking and removing
> the keyword.
And it will be #10 in 23.0 Beta once the patch of bug 839854 uplifted.

Comment 20

[Lukas Blakk [:lsblakk] use ?needinfo]

Actually it has dropped to #15, we can keep an eye out for increased volume but on 23 the volume is quite low currently so untracking.

Comment 21

[Tracy Walker [:tracy]]

just one URL associated with this crash; a facebook user page.

Comment 22

[Kevin Brosnan [Ex-Mozilla]]

23+ ship has sailed. Need to re-triage this.

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:sdetar, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 24

[Iain Ireland [:iain]]

We've replaced the regexp engine twice since this bug was relevant. Closing.