Closed Bug 763864 Opened 12 years ago Closed 2 years ago

crash in js::RegExpShared::execute or js::ExecuteRegExp mainly on ARMv6 devices

Categories

(Core :: JavaScript Engine, defect)

ARM
Android
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox15 --- affected
firefox16 + wontfix
firefox17 + wontfix
firefox18 - affected
firefox19 --- affected
firefox20 --- affected
firefox21 --- affected
firefox23 --- affected
firefox24 --- affected

People

(Reporter: scoobidiver, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, Whiteboard: [js:waitingforinfo][native-crash][ARMv6])

Crash Data

It's #18 top crasher in 14.0b6, #9 in 15.0a2 and #18 in 16.0a1.

Signature 	js::RegExpShared::execute More Reports Search
UUID	a81b6ed3-eabb-4dc6-a993-ce9ee2120612
Date Processed	2012-06-12 09:27:22
Uptime	49
Last Crash	4.1 days before submission
Install Age	4.1 days since version was first installed.
Install Time	2012-06-08 07:31:47
Product	FennecAndroid
Version	14.0
Build ID	20120605235323
Release Channel	beta
OS	Linux
OS Version	0.0.0 Linux 2.6.35.7-I9100DXKI2-CL564948 #2 SMP PREEMPT Thu Sep 8 18:37:54 KST 2011 armv7l
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGBUS
Crash Address	0x0
App Notes 	
AdapterVendorID: smdkc210, AdapterDeviceID: GT-I9100.
AdapterDescription: 'Model: 'GT-I9100', Product: 'GT-I9100', Manufacturer: 'samsung', Hardware: 'smdkc210''.
samsung GT-I9100
samsung/GT-I9100/GT-I9100:2.3.3/GINGERBREAD/DXKI2:user/release-keys
EMCheckCompatibility	True

Frame 	Module 	Signature 	Source
0 		@0x4721ddc4 	
1 	libxul.so 	js::RegExpShared::execute 	js/src/vm/RegExpObject.cpp:307
2 	libxul.so 	js::ExecuteRegExp 	js/src/builtin/RegExp.cpp:140
3 	libxul.so 	DoMatch 	js/src/jsstr.cpp:1583
4 	libxul.so 	js::str_match 	js/src/jsstr.cpp:1663
5 	libxul.so 	js::Interpret 	js/src/jscntxtinlines.h:314
6 	libxul.so 	js::RunScript 	js/src/jsinterp.cpp:475
7 	libxul.so 	js::InvokeKernel 	js/src/jsinterp.cpp:535
8 	libxul.so 	js_fun_apply 	js/src/jsinterp.h:172
9 	libxul.so 	js::Interpret 	js/src/jscntxtinlines.h:314
10 	libxul.so 	js::RunScript 	js/src/jsinterp.cpp:475
11 	libxul.so 	js::InvokeKernel 	js/src/jsinterp.cpp:535
12 	libxul.so 	js_fun_apply 	js/src/jsinterp.h:172
13 	libxul.so 	js::Interpret 	js/src/jscntxtinlines.h:314
14 	libxul.so 	js::RunScript 	js/src/jsinterp.cpp:475
15 	libxul.so 	js::InvokeKernel 	js/src/jsinterp.cpp:535
16 	libxul.so 	js_fun_apply 	js/src/jsinterp.h:172
17 	libxul.so 	js::Interpret 	js/src/jscntxtinlines.h:314
18 	libxul.so 	js::RunScript 	js/src/jsinterp.cpp:475
19 	libxul.so 	js::InvokeKernel 	js/src/jsinterp.cpp:535
20 	libxul.so 	js_fun_apply 	js/src/jsinterp.h:172
21 	libxul.so 	js::Interpret 	js/src/jscntxtinlines.h:314
22 	libxul.so 	js::RunScript 	js/src/jsinterp.cpp:475
23 	libxul.so 	js::Execute 	js/src/jsinterp.cpp:674
24 	libxul.so 	JS_EvaluateUCScriptForPrincipalsVersionOrigin 	js/src/jsapi.cpp:5294
25 	libxul.so 	nsJSContext::EvaluateString 	dom/base/nsJSEnvironment.cpp:1458
26 	libxul.so 	nsScriptLoader::EvaluateScript 	content/base/src/nsScriptLoader.cpp:918
27 	libxul.so 	nsScriptLoader::ProcessRequest 	content/base/src/nsScriptLoader.cpp:811
28 	libxul.so 	nsScriptLoader::ProcessPendingRequests 	content/base/src/nsScriptLoader.cpp:967
29 	libxul.so 	nsScriptLoader::OnStreamComplete 	content/base/src/nsScriptLoader.cpp:1186
30 	libxul.so 	nsStreamLoader::OnStopRequest 	netwerk/base/src/nsStreamLoader.cpp:127
31 	libxul.so 	nsHTTPCompressConv::OnStopRequest 	netwerk/streamconv/converters/nsHTTPCompressConv.cpp:127
32 	libxul.so 	nsHttpChannel::OnStopRequest 	netwerk/protocol/http/nsHttpChannel.cpp:4495
33 	libxul.so 	nsInputStreamPump::OnStateStop 	netwerk/base/src/nsInputStreamPump.cpp:587
34 	libxul.so 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:405
35 	libxul.so 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:114
36 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:656
37 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
38 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:114
39 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:208
40 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:201
41 	libxul.so 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:189
42 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:295
43 	libxul.so 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3780
44 	libxul.so 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3857
45 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3933
46 	libxul.so 	GeckoStart 	toolkit/xre/nsAndroidStartup.cpp:109
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3ARegExpShared%3A%3Aexecute
Whiteboard: [native-crash] → [js:inv:p1][native-crash]
It's #11 top crasher in 14.0.1, #12 in 15.0b3, #39 in 16.0a2, and #17 in 17.0a1.
It's #7 non-fixed top crasher in 15.0b5.
Keywords: topcrash
It's #1 top crasher in 16.0b1 while only #15 in 15.0.

Jelly Bean is unaffected.
Summary: crash in js::RegExpShared::execute → crash in js::RegExpShared::execute on GB, HC, and ICS
This looks like a null-pointer crash in jitcode generated for regular expressions. I would tend to think it's just a bug in our code, but it's very strange that Jelly Bean would be unaffected by a bug like that. Scoobi, could Jelly Bean not have reports just because there's not much data, or are there enough reports that we can confidently say the bug doesn't affect JB?

Without STR it's of course difficult to attack, but there are a few things we could try. Erin, could you please advise on which of these makes sense?

1. We could disable the regexp JIT on Android. That would either make this crash go away, or show that the problem is actually something else entirely. Disabling the regexp JIT would regress our benchmark performance. It would probably not have impact on user experience, but I don't know for sure.

 - If we do this for Beta, we wouldn't see the results until the next Beta release. And obviously it's riskier.
 - We could do it for trunk, which is safer but wouldn't help Beta.

2. We could pick up updates from Apple's copy of Yarr and see if that fixes the problem. The downsides are that it is a lot of work and also risky (we could patch it wrong and introduce new bugs). The risks are worse for Beta - we could just do this on trunk and then it wouldn't be so risky and wouldn't matter that it could take a while.
(In reply to David Mandelin [:dmandelin] from comment #4)
> Scoobi, could Jelly Bean not have reports just because there's not much data, or
> are there enough reports that we can confidently say the bug doesn't affect JB?
I sorted out crash reports by Linux version. I am not completely sure JB is unaffected because I haven't found something about Android versions in rkaiser and chofmann's correlation reports.
URLs:

8 	https://www.facebook.com/
6 	about:blank
2 	http://www.google.de/
2 	https://www.google.com/search?q=cult+of+dead+bow&ie=utf-8&oe=utf-8&aq=t&rls=org.
2 	http://www.facebook.com/
2 	http://www.bigfooty.com/forum/forums/port-adelaide-est-1870.28/
2 	http://www.7cont.ru/catalog/668/
1 	https://apps.facebook.com/inthemafia/?fb_source=bookmark_apps&ref=bookmarks&coun
1 	http://www.google.com/search?hl=ar&redir_esc=&client=ms-android-samsung&source=a
1 	http://www.expressen.se/?partner=m
1 	http://www.project-syndicate.org/commentary/sweden-s-other-rape-suspects-by-naom
1 	http://v8.googlecode.com/svn/data/benchmarks/v7/run.html
1 	http://www.postimage.org/index.php?mode=smf&lang=english&areaid=0&forumurl=http%
1 	http://a.tribalfusion.com/p.media/
1 	https://www.google.com/search?q=%D1%82%D0%BE%D1%80%D0%B3%D0%BE%D0%B2%D1%8B%D0%B5
1 	http://mobil.aftonbladet.se/
1 	http://demotywatory.pl/poczekalnia/page/6
1 	http://export.gov/safeharbor/
1 	http://www.phonescoop.com/oses/news.php?o=20
1 	http://sn130w.snt130.mail.live.com/default.aspx
1 	https://www.google.com/search?q=harian+fajar&ie=utf-8&oe=utf-8&aq=t&rls=org.mozi
1 	http://www.thedailyshow.com/full-episodes/thu-august-30-2012-michael-steele
1 	http://www.amazon.com/gp/cart/view-upsell.html?ie=UTF8&HUCT=1&newItems=C3VY2WQAZ
1 	http://www.play-today.ru/index.php?categoryID=2048&category_slug=scool-devochki-
1 	http://www.booking.com/city/be/oostende.en.html?aid=340631;label=city-oostende-d
1 	http://en.m.wikipedia.org/wiki/Delayed_ejaculation#section_3
1 	http://m.funnyordie.com/videos/b6046bfce4/the-donny-clay-show-with-courtney-stod
1 	http://www.dn.se/
1 	http://urlaub.swoodoo.com/booking/swoodoo/index.php?KID=626185&formular=4&adword
1 	http://m.db.no/2012/09/03/nyheter/koranbrenning/rettssikkerhet/utenriks/23233380
1 	http://www.lidl.be/cps/rde/xchg/lidl_be/hs.xsl/offerdate.htm?offerdate=53663
1 	http://www.tapuz.co.il/Communa/JoinTheCommuna.asp?communaid=39379&status=1
1 	http://www.liverpoolfc.com/video/interview/12379-lfc-0-2-arsenal-analysis
1 	http://www.google.com.au/imgres?imgurl=http://earthdivasblog.com/wp-content/uplo
1 	https://prodgame09.alliances.commandandconquer.com/41/index.aspx
1 	https://support.mozilla.org/fr/kb/comment-ajouter-appareil-firefox-sync
1 	http://es.m.youversion.com/home
1 	http://thinkcraftythoughts.blogspot.com/2012/01/baby-giraffe-hat.html#
1 	http://forum.nfluk.com/forumdisplay.php?f=13
1 	http://romanews.eu/it,a99814/Zeman-Andiamo-Milano-Giocarci-La-Partita-Lamela-Mig
1 	http://kotaku.com/5878869/the-12-best-games-on-psp
1 	http://thedailywhat.cheezburger.com/page/5
1 	http://perezhilton.com/2012-08-31-president-obama-twitter-response-this-seats-ta
1 	http://www.mobilmania.cz/clanky/o2-v-zari-po-roce-jde-do-prodeje-iphone-4s-cenik
1 	http://m.dantri.com.vn/error.aspx?aspxerrorpath=/Default.aspx
1 	http://www.amazon.com/Premium-Acoustic-SoundProofing-Deadening-Acoustical/dp/B00
1 	http://www.teamflyingcircus.com/forum/f23/dirty-da100-6570/index3.html
1 	http://frashntrack.com/
1 	http://bloggermalaz.blogspot.com/2012/08/foto-beginilah-tata-cara-bercerai-di.ht
1 	http://i.imgur.com/xCP4M.jpg
1 	http://m.tagged.com/meetme.html?hash=-kLsoFoEKZ
1 	http://www.nutricnihodnoty.cz/index/login/canteenId/46
1 	about:addons
1 	http://memebase.cheezburger.com/superheroes/page/5
1 	http://www.amazon.com/Cinema-Etoile-Chiffon-Babydoll-Medallion/dp/B005XLEJTY/ref
1 	http://www.facebook.com/photo.php?fbid=190281364438911&set=a.112384465561935.155
1 	http://www.tmonews.com/2012/08/t-mobile-com-receives-fresh-new-look-new-paint-jo
1 	http://www.meinpaket.de/de/home.html
1 	http://192.168.1.1/sam/admin/index2.php
1 	http://www.record.xl.pt/futebol/nacional/1a_liga/benfica/default.aspx
1 	http://webmaildomini.aruba.it/cgi-bin/ajaxmail?Act_Cnf=1&ID=IdBAJNGzFgyJEDBw-BAI
1 	http://www.washingtonpost.com/
Keywords: needURLs
Just checked, #6 in 15.0.1, #5 in 16b3, and #11 in 14.0.1.

(In reply to David Mandelin [:dmandelin] from comment #4)
> This looks like a null-pointer crash in jitcode generated for regular
> expressions. I would tend to think it's just a bug in our code, but it's
> very strange that Jelly Bean would be unaffected by a bug like that. Scoobi,
> could Jelly Bean not have reports just because there's not much data, or are
> there enough reports that we can confidently say the bug doesn't affect JB?
> 
> Without STR it's of course difficult to attack, but there are a few things
> we could try. Erin, could you please advise on which of these makes sense?
> 
> 1. We could disable the regexp JIT on Android. That would either make this
> crash go away, or show that the problem is actually something else entirely.
> Disabling the regexp JIT would regress our benchmark performance. It would
> probably not have impact on user experience, but I don't know for sure.
> 
>  - If we do this for Beta, we wouldn't see the results until the next Beta
> release. And obviously it's riskier.
>  - We could do it for trunk, which is safer but wouldn't help Beta.
> 
> 2. We could pick up updates from Apple's copy of Yarr and see if that fixes
> the problem. The downsides are that it is a lot of work and also risky (we
> could patch it wrong and introduce new bugs). The risks are worse for Beta -
> we could just do this on trunk and then it wouldn't be so risky and wouldn't
> matter that it could take a while.

Both of these options seem risky for where we are in the release. Let's wontfix for 16 given this is an issue since 14, and instead try speculative fixes in 17/18. I don't feel strongly about option trying #1 or #2, since we'd be making this change on Aurora.
(In reply to Marcia Knous [:marcia] from comment #6)
> URLs:

I've loaded most of the interesting urls and no crashes on load.
(In reply to Naoki Hirata :nhirata from comment #9)
> Looks like a gingerbread Samsung Galaxy S II crash with a custom kernel?

On all those crashes? Also, how should a mere different kernel make the JIT crash?
(In reply to David Mandelin [:dmandelin] from comment #4)
> are there enough reports that we can confidently say the bug doesn't affect JB?
There are enough reports and still no crashes on JB.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #10)
> (In reply to Naoki Hirata :nhirata from comment #9)
> > Looks like a gingerbread Samsung Galaxy S II crash with a custom kernel?
> 
> On all those crashes? Also, how should a mere different kernel make the JIT
> crash?

Not saying it's on all the crashes.  We just need to reproduce it on one at the very least to get it more actionable.  Cynogenmod 10 is crashy.
(In reply to Naoki Hirata :nhirata from comment #12)
> Not saying it's on all the crashes.  We just need to reproduce it on one at
> the very least to get it more actionable.  Cynogenmod 10 is crashy.

CM10 sure, but nothing here points to CM10 from what I saw, but to GB, HC and ICS, while CM10 is based on JB, AFAIK. The bug reports on CM10 are elsewhere. This is a JIT/Yarr crash on Android proper (and from what I see on different devices).
Whiteboard: [js:inv:p1][native-crash] → [js:p1:fx19][native-crash]
This is at #9 topcrasher in 17 and that's before we go to Beta channel in less than a week.  What are the speculative fix options here? Let's get to trying some in the next week's early 17 betas so we can nail down a fix before 17 release.
(In reply to Lukas Blakk [:lsblakk] from comment #14)
> This is at #9 topcrasher in 17 and that's before we go to Beta channel in
> less than a week.  What are the speculative fix options here? Let's get to
> trying some in the next week's early 17 betas so we can nail down a fix
> before 17 release.

Unfortunately this issue looks pretty difficult to investigate. We have two options right now:

 (1) Update our copy of YARR to the latest copy in the WebKit tree. Our copy is a year+ old, and I'm doing this update in bug 740015. That's not really something we should take for aurora though, but at least we can see if it fixes the issue on trunk.

 (2) Disable our regular expression JIT on ARM, on aurora. This would cost us something on benchmarks, but would be highly likely to fix this bug. There isn't much evidence that regular expression JITs matter on the web, FWIW, it is mainly a benchmarketing thing.
Depends on: 740015
From 19.0a1/20121009, every crash signatures on Linux have a Windows look.

For this bug, more reports at: https://crash-stats.mozilla.com/report/list?signature=js%3A%3ARegExpShared%3A%3Aexecute%28JSContext*%2C+unsigned+short+const*%2C+unsigned+int%2C+unsigned+int*%2C+js%3A%3AMatchPairs**%29
Crash Signature: [@ js::RegExpShared::execute] → [@ js::RegExpShared::execute] [@ js::RegExpShared::execute(JSContext*, unsigned short const*, unsigned int, unsigned int*, js::MatchPairs**)]
Crash Signature: [@ js::RegExpShared::execute] [@ js::RegExpShared::execute(JSContext*, unsigned short const*, unsigned int, unsigned int*, js::MatchPairs**)] → [@ js::RegExpShared::execute] [@ js::RegExpShared::execute(JSContext*, unsigned short const*, unsigned int, unsigned int*, js::MatchPairs**)] [@ js::RegExpShared::execute(JSContext*, JS::StableCharPtr, unsigned int, unsigned int*, js::MatchPairs**)]
Looks like we have a possible STR in comment 17. Assigning to David for further investigation - re-assign to another engineer as needed, but at this point in the beta cycle we have to make sure the tracked bugs are assigned to people and actively being worked on.
Assignee: general → dvander
Keywords: reproducible
Marty, could you take a look at the STR in comment #17? If we can't reproduce a crash off that, I recommend that we just turn off the regex JIT on ARM until we push the Yarr update through.
This is the #5 topcrash in 17.0b1 for Android. It's present on desktop as well, but only at #192 there.
Crash Signature: [@ js::RegExpShared::execute] [@ js::RegExpShared::execute(JSContext*, unsigned short const*, unsigned int, unsigned int*, js::MatchPairs**)] [@ js::RegExpShared::execute(JSContext*, JS::StableCharPtr, unsigned int, unsigned int*, js::MatchPairs**)] → [@ js::RegExpShared::execute] [@ js::RegExpShared::execute(JSContext*, unsigned short const*, unsigned int, unsigned int*, js::MatchPairs**)] [@ js::RegExpShared::execute(JSContext*, JS::StableCharPtr, unsigned int, unsigned int* js::MatchPairs**)] [@ …
This is the #1 topcrash for Firefox 16.0.1 for Android.
Keywords: qawanted
I just talked with Marty about this. Unfortunately we're in the middle of a JS work week so the earliest he'll be able to look into it is late this weekend. In the event we can't have a real fix in time, there is a fallback option I proposed in comment #15: we can disable the regex JIT on ARM. We'd lose on benchmarks, but past studies have suggested regex JITing does not really matter for web performance.
Assignee: dvander → mrosenberg
can't seem to repro using 19a1 10/15 build... removing reproducible.  Going to try to reproduce this crash again.
Keywords: reproducible
I can't seem to reproduce the crash any more. 10/28 Nightly w/ javascript.options.ion.content = false

I tried multiple of the listed websites on the Galaxy S II.
(In reply to Naoki Hirata :nhirata from comment #24)
> I can't seem to reproduce the crash any more. 10/28 Nightly w/
> javascript.options.ion.content = false
> 
> I tried multiple of the listed websites on the Galaxy S II.

Does that mean it crashes with ion.content = true?
I recently tried fuzzing the regexp jit on mobile and arm.  After a few hours of dying with OOMs, I didn't see anything that looked similar to these crashes.  I don't think there is much that I can do without a reproducible test case.
Looks like this had a spike in 17.0b3 - will wait to see what 17.0b4 data brings and then make the call on whether to untrack this for 17/18 or we'll need to disable the regex JIT on ARM.
(In reply to Lukas Blakk [:lsblakk] from comment #28)
> Looks like this had a spike in 17.0b3 - will wait to see what 17.0b4 data
> brings and then make the call on whether to untrack this for 17/18 or we'll
> need to disable the regex JIT on ARM.

js::RegExpShared::execute is #2 for 17.0b4, so it looks like a regression, not a transitional spike in b3. I guess we need to see if we still can do something for 17.
Hmm, as https://crash-stats.mozilla.com/report/list?signature=js%3A%3ARegExpShared%3A%3Aexecute shows, this is also happening in high volume on 16.0.2 and 16.0.1 - I'm actually at a loss as to why crash-stats doesn't show it as a topcrash for 16.0.2, as my explosiveness reports do show it as such.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #30)
> why crash-stats doesn't show it as a topcrash for 16.0.2
It's #1 top crasher in 16.0.2: https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/16.0.2
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #29)
> js::RegExpShared::execute is #2 for 17.0b4, so it looks like a regression,
> not a transitional spike in b3. I guess we need to see if we still can do
> something for 17.

As comment 27 mentions, without a reproducible test case there's unfortunately no forward movement on this one.  At this stage we have to wontfix for 17.
With bug 740015 landed we should look to see how this affects regex stability on mobile. It might be too early though.
(In reply to David Anderson [:dvander] from comment #33)
> With bug 740015 landed we should look to see how this affects regex
> stability on mobile. It might be too early though.

Even if it helps, this landing on 19 only will have a hard time fixing a 16 and 17 topcrash, for sure. :-/
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #35)
> (In reply to David Anderson [:dvander] from comment #33)
> > With bug 740015 landed we should look to see how this affects regex
> > stability on mobile. It might be too early though.
> 
> Even if it helps, this landing on 19 only will have a hard time fixing a 16
> and 17 topcrash, for sure. :-/

We can consider an uplift, depending on a risk evaluation by David.
Scoobidiver, does Firefox 19 have any new RegEx crash signatures that just replaced the old one? If not, I think this is actually low-risk.
(In reply to David Anderson [:dvander] from comment #37)
> Scoobidiver, does Firefox 19 have any new RegEx crash signatures that just
> replaced the old one? 
I think js::ExecuteRegExp is a possible replacement (about one crash per build like this bug) even if one crash happened before the fix of bug 740015: https://crash-stats.mozilla.com/report/list?product=FennecAndroid&version=FennecAndroid%3A19.0a1&range_value=4&range_unit=weeks&signature=js%3A%3AExecuteRegExp%28JSContext*%2C%20js%3A%3ARegExpStatics*%2C%20js%3A%3ARegExpShared%26%2C%20JS%3A%3AHandle%3CJSStableString*%3E%2C%20JS%3A%3AStableCharPtr%2C%20unsigned%20int%2C%20unsigned%20int*%2C%20js%3A%3ARegExpExecType%2C%20JS%3A%3AValue*%29
Crash Signature: js::MatchPairs**)] [@ js::RegExpShared::execute(JSContext*, wchar_t const*, unsigned int, unsigned int*, js::MatchPairs**)] → js::MatchPairs**)] [@ js::RegExpShared::execute(JSContext*, wchar_t const*, unsigned int, unsigned int*, js::MatchPairs**)] [@ js::ExecuteRegExp(JSContext*, js::RegExpStatics*, js::RegExpShared&, JS::Handle<JSStableString*>, JS::StableCharPtr unsigned i…
Hrm, if this only moved things to a different signature, it's of course probably not worth to uplift anywhere - and we need to continue investigating. :(

The good news is that so far, this is not a topcrash on 17.0b6, so maybe something makes us dodge it for 17?
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #40)
> The good news is that so far, this is not a topcrash on 17.0b6, so maybe
> something makes us dodge it for 17?
No, it's still in the top 5 in 17.0b6: https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/17.0b6
Hrm, yes, sorry.  Not sure what I did look at. :(
Crash Signature: unsigned int, unsigned int*, js::RegExpExecType, JS::Value*)] → unsigned int, unsigned int*, js::RegExpExecType, JS::Value*)] [@ NS_IsMainThread_P()]
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #40)
> Hrm, if this only moved things to a different signature, it's of course
> probably not worth to uplift anywhere - and we need to continue
> investigating. :(

It might be if there is an overall reduction in crashes.
This has affected Firefox since FF15 (Fennec Native rewrite) - tracking for releases won't move the needle in the future.
js::RegExpShared::execute stays at the top of the 17.0 for Android topcrash list, it's #1 with ~3% of all crashes.

On 19, we have way less data, but https://crash-stats.mozilla.com/report/list?signature=js%3A%3AExecuteRegExp%28JSContext%2A%2C%20js%3A%3ARegExpStatics%2A%2C%20js%3A%3ARegExpShared%26%2C%20JS%3A%3AHandle%3CJSStableString%2A%3E%2C%20JS%3A%3AStableCharPtr%2C%20unsigned%20int%2C%20unsigned%20int%2A%2C%20js%3A%3ARegExpExecType%2C%20JS%3A%3AValue%2A%29&version=FennecAndroid%3A19.0a2 might actually have taken over. Really hard to tell with the low ADU and crash numbers on Aurora, though.

dvander, Marty, any chance we can get some traction here?
There is nothing we can do for this bug without STR, unfortunately. We could still make a call to turn the regex JIT off on ARM, which would be a benchmark performance hit, but maybe worth it if we think there is too much instability.
Whiteboard: [js:p1:fx19][native-crash] → [js:waitingforinfo][native-crash]
Primary signature is gone from 19 and above.
There must have been some change in 19 that caused this.

QAWanted tag to try to get STRs per Comment 46.
Keywords: qawanted
(In reply to Naoki Hirata :nhirata from comment #47)
> Primary signature is gone from 19 and above.
> There must have been some change in 19 that caused this.

We updated Yarr for 19 (Bug 740015).
Crash Signature: js::MatchPairs**)] [@ js::RegExpShared::execute(JSContext*, wchar_t const*, unsigned int, unsigned int*, js::MatchPairs**)] [@ js::ExecuteRegExp(JSContext*, js::RegExpStatics*, js::RegExpShared&, JS::Handle<JSStableString*>, JS::StableCharPtr unsigned i… → js::MatchPairs**)] [@ js::RegExpShared::execute(JSContext*, wchar_t const*, unsigned int, unsigned int*, js::MatchPairs**)] [@ js::ExecuteRegExp] [@ js::ExecuteRegExp(JSContext*, js::RegExpStatics*, js::RegExpShared&, JS::Handle<JSStableString*> JS::St…
(In reply to Sean Stangl from comment #48)
> (In reply to Naoki Hirata :nhirata from comment #47)
> > Primary signature is gone from 19 and above.
> > There must have been some change in 19 that caused this.
> 
> We updated Yarr for 19 (Bug 740015).

I guess that's what fixed a lot of those cases, then. Yay!
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #49)
> I guess that's what fixed a lot of those cases, then. Yay!

Or just moved them from js::RegExpShared::execute to js::ExecuteRegExp, as that's rising on 19 now.
It's #15 top crasher in 19.0.2, not enough to qualify it for the topcrash keyword according to https://wiki.mozilla.org/CrashKill/Topcrash
Keywords: topcrash
Crash Signature: , js::MatchPairs**)] [@ js::RegExpShared::execute(JSContext*, wchar_t const*, unsigned int, unsigned int*, js::MatchPairs**)] [@ js::ExecuteRegExp] [@ js::ExecuteRegExp(JSContext*, js::RegExpStatics*, js::RegExpShared&, JS::Handle<JSStableString*>, JS:… → , js::MatchPairs**)] [@ js::RegExpShared::execute(JSContext*, wchar_t const*, unsigned int, unsigned int*, js::MatchPairs**)] [@ js::RegExpShared::execute(JSContext*, wchar_t const*, unsigned int, unsigned int*, js::MatchPairs&) ] [@ js::ExecuteRegExp]…
With combined signatures, it's #138 crasher in 20.0 so not even close to top crashers as it was before.
Crash Signature: , js::MatchPairs&) ] [@ js::ExecuteRegExp] [@ js::ExecuteRegExp(JSContext*, js::RegExpStatics*, js::RegExpShared&, JS::Handle<JSStableString*>, JS::StableCharPtr, unsigned int, unsigned int*, js::RegExpExecType, JS::Value*)] [@ js::ExecuteRegExp(JSCont… → , js::MatchPairs&) ] [@ js::RegExpShared::execute(JSContext*, unsigned short const*, unsigned int, unsigned int*, js::MatchPairs&) ] [@ js::ExecuteRegExp] [@ js::ExecuteRegExp(JSContext*, js::RegExpStatics*, js::RegExpShared&, JS::Handle<JSStableString…
99% of crashes happen on ARMv6 devices and in any Android versions.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3AExecuteRegExp
https://crash-stats.mozilla.com/report/list?signature=js%3A%3ARegExpShared%3A%3Aexecute%28JSContext*%2C+unsigned+short+const*%2C+unsigned+int%2C+unsigned+int*%2C+js%3A%3AMatchPairs%26%29
Crash Signature: , js::MatchPairs&) ] [@ js::RegExpShared::execute(JSContext*, unsigned short const*, unsigned int, unsigned int*, js::MatchPairs&) ] [@ js::ExecuteRegExp] [@ js::ExecuteRegExp(JSContext*, js::RegExpStatics*, js::RegExpShared&, JS::Handle<JSStableString… → , js::MatchPairs&) ] [@ js::RegExpShared::execute(JSContext*, unsigned short const*, unsigned int, unsigned int*, js::MatchPairs&) ] [@ js::ExecuteRegExp] [@ @0x0 | js::ExecuteRegExp ] [@ js::ExecuteRegExp(JSContext*, js::RegExpStatics*, js::RegExpSha…
Summary: crash in js::RegExpShared::execute on GB, HC, and ICS → crash in js::RegExpShared::execute or js::ExecuteRegExp mainly on ARMv6 devices
Whiteboard: [js:waitingforinfo][native-crash] → [js:waitingforinfo][native-crash][ARMv6]
Crash Signature: , unsigned int, unsigned int*, js::RegExpExecType, JS::Value*)] → , unsigned int, unsigned int*, js::RegExpExecType, JS::Value*)] [@ js::RegExpObject::createShared(JSContext*, js::RegExpGuard*)]
Crash Signature: , unsigned int, unsigned int*, js::RegExpExecType, JS::Value*)] [@ js::RegExpObject::createShared(JSContext*, js::RegExpGuard*)] → , unsigned int, unsigned int*, js::RegExpExecType, JS::Value*)] [@ js::ExecuteRegExp(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSString*>, js::MatchConduit&) ] [@ js::RegExpObject::createShared(JSContext*, js::RegExpGuard*)]
Crash Signature: , unsigned int, unsigned int*, js::RegExpExecType, JS::Value*)] [@ js::ExecuteRegExp(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSString*>, js::MatchConduit&) ] [@ js::RegExpObject::createShared(JSContext*, js::RegExpGuard*)] → , unsigned int, unsigned int*, js::RegExpExecType, JS::Value*)] [@ js::ExecuteRegExp(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSString*>, js::MatchConduit&) ] [@ js::RegExpObject::createShared(JSContext*, js::RegExpGuard*)] [@ js::RegExpObject::cr…
Restrict Comments: true

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.

Assignee: marty.rosenberg → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(sdetar)
Flags: needinfo?(sdetar)

We've replaced the regexp engine twice since this bug was opened, and this hasn't been a top crash in years. I think this is safe to close.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.