Closed Bug 700176 Opened 13 years ago Closed 12 years ago

Crash Report @ js_GetIndexFromBytecode

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
9 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: nhirata, Unassigned)

References

Details

(Keywords: crash, regression, topcrash, Whiteboard: startupcrash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-9cdfa8f5-7db1-4796-a207-d7baa2111030 .
============================================================= 

Frame 	Module 	Signature [Expand] 	Source
0 	libxul.so 	js_GetIndexFromBytecode 	js/src/jsopcode.cpp:164
1 	libxul.so 	js::PropertyCache::fullTest 	js/src/jspropertycache.cpp:316
2 	libxul.so 	js::mjit::stubs::GetProp 	js/src/jspropertycacheinlines.h:99
3 	libxul.so 	DisabledGetPropIC 	js/src/methodjit/PolyIC.cpp:1920
4 	libxul.so 	libxul.so@0xc1c83d 	
5 	libxul.so 	DisabledXNameIC 	js/src/methodjit/PolyIC.cpp:2198
Crash Signature: [@ js_GetIndexFromBytecode ]
set as P3, need steps, low volume.
Whiteboard: [native-crash] → [native-crash:P3], str-wanted
While I was trying to reproduce Bug 704129 with the steps mentioned in it, this crashed occurred:
https://crash-stats.mozilla.com/report/index/bp-66c75182-8af7-4467-9d8f-761ef2111122

--
Mozilla/5.0 (Android;Linux armv7l;rv:11.0a1)Gecko/20111122
Firefox/11.0a1 Fennec/11.0a1
Devices: Samsung Galaxy Nexus S
OS: Android 2.3.4
I cannot seem to reproduce the issue.  I did however run into bug 704511
Keywords: reproducible
Whiteboard: [native-crash:P3], str-wanted → [native-crash:P3]
It's #52 top crasher in 9.0b3, #80 in 10.0a2, and #155 in 11.0a1.

It first appeared in 9.0a1/20110903. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ce43a8644bc0&tochange=472716252ea3

The first frames on desktop are:
Frame 	Module 	Signature [Expand] 	Source
0 	mozjs.dll 	js_GetIndexFromBytecode 	js/src/jsopcode.cpp:160
1 	mozjs.dll 	GetAtomFromBytecode 	js/src/jspropertycache.cpp:316
2 	mozjs.dll 	js::PropertyCache::fullTest 	js/src/jspropertycache.cpp:409
3 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4126
4 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:614
5 	mozjs.dll 	js::ExecuteKernel 	js/src/jsinterp.cpp:814
6 	mozjs.dll 	js::Execute 	js/src/jsinterp.cpp:853
7 	mozjs.dll 	JS_ExecuteScriptVersion 	js/src/jsapi.cpp:4908

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js_GetIndexFromBytecode
Keywords: regression
OS: Android → All
Hardware: ARM → All
Version: Other Branch → 9 Branch
If I read correctly, this is the #3 top-crash (first real crash after the plugin-hangs and no-data crashes).  100% of the 40 or so stacks I clicked have RapportTanzan9.dll in the stack calling JS_CallFunctionValue directly.

The crash seems to be a NULL 'script' passed to http://hg.mozilla.org/releases/mozilla-release/annotate/c4405d7a95f6/js/src/jsopcode.cpp#l160.  The caller (http://hg.mozilla.org/releases/mozilla-release/annotate/c4405d7a95f6/js/src/jspropertycache.cpp#l313) derives 'script' from a ContextStack::currentScript which has several NULL return paths.  Since RapportTanzan is calling the JS engine directly from script (hence fp && !fp->isDummyFrame) and the rest of the NULL return paths are due to compartment mismatches, my money is on RapportTanazn not entering the right compartment (a recent (FF4) JSAPI change).  If this is the case, a spot fix here will only lead to a crash somewhere else.  Therefore, I think we should block RapportTanzan until they stop calling JSAPI directly and just call through xpconnect like everyone else.

CC'ing bhackett to see if he agrees.  I don't know who to CC for blocklisting, so I'll start with dmandelin and chofmann.
Makes sense to me.
nominating for fx10 if we can figure out a way to prevent the crash, otherwise I think we also have other outstanding issues for trusteer who appears to provide RapportTanzan.dll ( http://systemexplorer.net/db/rapporttanzan9.dll.html ).  cc'ing marcia and kev in case they have reached out to trusteer already.
tracking-firefox10: --- → ?
Well, the Android case is probably not from that DLL.

As chofmann mentioned, we should contact Trusteer and tell them what's up with this problem we have with users of their Rapport product (which is where RapportTanzan*.dll belong to) and what they should do instead.

We've had different crashes recently reported with Trusteer Rapport, some with a similar path (i.e. crashing in our code being called from RapportTanzan*.dll), see bug 681521, bug 699776, bug 696057.
tracking-firefox10: + → ---
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #8)
> We've had different crashes recently reported with Trusteer Rapport, some
> with a similar path

If they are calling JSAPI directly, this is not surprising.
Keywords: topcrash
Summary: Crash Report [@ js_GetIndexFromBytecode ] → Crash Report [@ js_GetIndexFromBytecode ] (mainly correlated to Trusteer Rapport)
Depends on: 683317
Depends on: 715693
Whiteboard: [native-crash:P3] → [native-crash]
A user reported repetitive crashes with Firefox + Trusteer Rapport when he was browsing Gmail account e.g., see https://crash-stats.mozilla.com/report/index/7bb0f859-ef0d-42ee-8ada-06f012120102

The CR displays RapportTanzan9.DLL|3.5.1108.62. He contacted Trusteer and they said him to install the latest version 3.5.1108.65, no more crashes since the update.

Maybe someone can test?
(In reply to Loic from comment #10)
> The CR displays RapportTanzan9.DLL|3.5.1108.62. He contacted Trusteer and
> they said him to install the latest version 3.5.1108.65, no more crashes
> since the update.
Not yet seen in correlations:
     91% (1520/1672) vs.   3% (2724/80386) RapportUtil.dll
         87% (1447/1672) vs.   3% (2544/80386) 3.5.1108.62
          3% (56/1672) vs.   0% (101/80386) 3.5.1108.63
          1% (15/1672) vs.   0% (62/80386) 3.5.1108.64
does this bug track mobile problems, or desktop problems, or both?

its still #5 on 9.0.1 and #31 on 9.0 so that would make it topcrash on desktop still.
Keywords: topcrash
(In reply to chris hofmann from comment #13)
> does this bug track mobile problems, or desktop problems, or both?
It was initially written for the mobile case, but as it also happens on Windows with similar first frames, I generalized it for both platforms.
For JavaScript bugs, it's hard to know if the cause is the same as some code is different.
If you think there should be two bugs, file one again for the mobile case.

For the Windows case correlated to Trusteer Rapport, it still crashes with the latest version:
     94% (1840/1956) vs.   3% (3305/97284) RapportUtil.dll
         89% (1736/1956) vs.   3% (3017/97284) 3.5.1108.62
          4% (87/1956) vs.   0% (160/97284) 3.5.1108.63
          1% (12/1956) vs.   0% (80/97284) 3.5.1108.64
          0% (5/1956) vs.   0% (14/97284) 3.5.1108.65
(In reply to chris hofmann from comment #13)
> does this bug track mobile problems, or desktop problems, or both?

It has originally been filed for the mobile crash but then has been "hijacked" by the desktop issue with Trusteer Rapport, which clearly can't apply to mobile as there's no Trusteer Rapport for Android. :(

Would have been better have two different bugs for this signature for the two different cases.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #15)
> It has originally been filed for the mobile crash but then has been
> "hijacked" by the desktop issue with Trusteer Rapport
As I am the hijacker, I filed bug 717909 for the mobile case.
OS: All → Windows 7
Hardware: All → x86
Whiteboard: [native-crash]
75% of crashes happen within one minute.

It's #15 top crasher in 10.0 and is now correlated to the Babylon Firefox Extension:
  js_GetIndexFromBytecode|EXCEPTION_ACCESS_VIOLATION_READ (76 crashes)
     64% (49/76) vs.   1% (155/13378) BabyFox.dll
          4% (3/76) vs.   0% (14/13378) 9.0.0.30
          1% (1/76) vs.   0% (1/13378) 9.0.0.31
          1% (1/76) vs.   0% (3/13378) 9.0.1.5
          1% (1/76) vs.   0% (4/13378) 9.0.2.10
          8% (6/76) vs.   0% (13/13378) 9.0.2.11
          4% (3/76) vs.   0% (4/13378) 9.0.2.5
          1% (1/76) vs.   0% (1/13378) 9.0.2.8
          1% (1/76) vs.   0% (4/13378) 9.0.3.14
         21% (16/76) vs.   0% (52/13378) 9.0.3.23
         21% (16/76) vs.   0% (45/13378) 9.0.4.10
Depends on: 721264
Summary: Crash Report [@ js_GetIndexFromBytecode ] (mainly correlated to Trusteer Rapport) → Crash Report @ js_GetIndexFromBytecode
Whiteboard: startupcrash
OS: Windows 7 → All
Hardware: x86 → All
Steps to reproduce:

http://mozos.net
openDialog("old/main.xul")

Crashing since 9.0b
Blocks: 730703
Correlations for Firefox 11.0 Windows NT

43% (60/140) vs.   1% (197/26228) BabyFox.dll
0% (0/140) vs.   0% (1/26228) 8.0.0.18
0% (0/140) vs.   0% (1/26228) 8.0.0.22
0% (0/140) vs.   0% (1/26228) 8.0.0.38
0% (0/140) vs.   0% (4/26228) 8.0.9.4
2% (3/140) vs.   0% (9/26228) 9.0.0.30
2% (3/140) vs.   0% (3/26228) 9.0.1.5
1% (1/140) vs.   0% (2/26228) 9.0.2.10
5% (7/140) vs.   0% (19/26228) 9.0.2.11
1% (1/140) vs.   0% (3/26228) 9.0.2.2
1% (1/140) vs.   0% (1/26228) 9.0.2.8
0% (0/140) vs.   0% (3/26228) 9.0.3.12
0% (0/140) vs.   0% (3/26228) 9.0.3.14
5% (7/140) vs.   0% (33/26228) 9.0.3.23
0% (0/140) vs.   0% (1/26228) 9.0.3.29
4% (5/140) vs.   0% (20/26228) 9.0.4.10
23% (32/140) vs.   0% (93/26228) 9.0.4.13
43% (60/140) vs.   1% (279/26228) captlib.dll
0% (0/140) vs.   0% (16/26228) 6.0.0.20
0% (0/140) vs.   0% (1/26228) 6.0.0.29
0% (0/140) vs.   0% (5/26228) 7.0.1.4
0% (0/140) vs.   0% (1/26228) 7.0.3.13
0% (0/140) vs.   0% (1/26228) 7.5.2.5
0% (0/140) vs.   0% (1/26228) 8.0.0.18
0% (0/140) vs.   0% (2/26228) 8.0.0.20
0% (0/140) vs.   0% (2/26228) 8.0.0.22
0% (0/140) vs.   0% (1/26228) 8.0.0.38
0% (0/140) vs.   0% (2/26228) 8.0.7.8
0% (0/140) vs.   0% (4/26228) 8.0.8.3
0% (0/140) vs.   0% (10/26228) 8.0.9.4
0% (0/140) vs.   0% (1/26228) 8.1.0.16
2% (3/140) vs.   0% (10/26228) 9.0.0.30
2% (3/140) vs.   0% (4/26228) 9.0.1.5
1% (1/140) vs.   0% (2/26228) 9.0.2.10
5% (7/140) vs.   0% (33/26228) 9.0.2.11
1% (1/140) vs.   0% (6/26228) 9.0.2.2
0% (0/140) vs.   0% (2/26228) 9.0.2.5
1% (1/140) vs.   0% (1/26228) 9.0.2.8
0% (0/140) vs.   0% (4/26228) 9.0.3.12
0% (0/140) vs.   0% (3/26228) 9.0.3.14
5% (7/140) vs.   0% (44/26228) 9.0.3.23
0% (0/140) vs.   0% (1/26228) 9.0.3.29
4% (5/140) vs.   0% (25/26228) 9.0.4.10
23% (32/140) vs.   0% (97/26228) 9.0.4.13


Both those libaries are Babylon stuff, AFAIK.
Babylon Toolbar is not the only one correlated according to correlations per add-on in 10.0.2:
38% (142/378) vs.   0% (175/52707) browseforchange@browseforchange.com
19% (73/378) vs.   2% (844/52707) plugin@yontoo.com
16% (60/378) vs.   1% (277/52707) crossriderapp2258@crossrider.com
15% (57/378) vs.   0% (112/52707) playbryte@playbryte.com
16% (60/378) vs.   3% (1710/52707) toolbar@ask.com
11% (40/378) vs.   2% (917/52707) bbrs_002@blabbers.com
14% (52/378) vs.   6% (2903/52707) {635abd67-4fe9-1b23-4f01-e679fa7484c1} (Yahoo! Toolbar, https://addons.mozilla.org/addon/2032)
8% (29/378) vs.   0% (53/52707) downloadmanager@wisedownloads.com
6% (24/378) vs.   0% (227/52707) appbar@alot.com
6% (24/378) vs.   0% (243/52707) {22119944-ED35-4ab1-910B-E619EA06A115} (Roboform Toolbar for Firefox, https://addons.mozilla.org/addon/750)
11% (42/378) vs.   5% (2852/52707) ffxtlbr@babylon.com

11.0 correlations show similar correlations per add-on.
Yes, the toolbar itself is not that high, the Babylon libraries are, though. Smells similar to those bugs for which we are going to block BExternal.dll now.
It's #9 top browser crasher in 11.0.

Correlations per extension are pretty stable. Here are the ones in 11.0:
  js_GetIndexFromBytecode|EXCEPTION_ACCESS_VIOLATION_READ (469 crashes)
     47% (220/469) vs.   0% (275/58517) browseforchange@browseforchange.com
     25% (119/469) vs.   2% (1293/58517) plugin@yontoo.com
     24% (111/469) vs.   1% (462/58517) crossriderapp2258@crossrider.com
     18% (85/469) vs.   0% (136/58517) playbryte@playbryte.com
     19% (87/469) vs.   4% (2247/58517) toolbar@ask.com
     20% (95/469) vs.   6% (3598/58517) {635abd67-4fe9-1b23-4f01-e679fa7484c1} (Yahoo! Toolbar, https://addons.mozilla.org/addon/2032)
     17% (78/469) vs.   6% (3579/58517) ffxtlbr@babylon.com
     12% (56/469) vs.   2% (916/58517) {99079a25-328f-4bd4-be04-00955acaa0a7}
     10% (49/469) vs.   0% (71/58517) downloadmanager@zoomdownloader.com
     10% (46/469) vs.   1% (406/58517) appbar@alot.com
     10% (45/469) vs.   1% (463/58517) {00f12770-e60e-4dc6-9105-425bface7c73}
      8% (37/469) vs.   0% (149/58517) wecarereminder@bryan (We-Care Reminder, https://addons.mozilla.org/addon/11517)
      8% (37/469) vs.   0% (186/58517) AppGraffiti@AppGraffiti.com
      8% (36/469) vs.   0% (73/58517) FantapperExtension@brandaffinity.net
     10% (45/469) vs.   2% (1285/58517) {EB9394A3-4AD6-4918-9537-31A1FD8E8EDF}
      7% (35/469) vs.   0% (135/58517) {EB132DB0-A4CA-11DF-9732-0E29E0D72085}
      6% (29/469) vs.   0% (44/58517) downloadmanager@wisedownloads.com
      7% (32/469) vs.   1% (498/58517) {5911488E-9D1E-40ec-8CBB-06B231CC153F}
      7% (35/469) vs.   2% (1221/58517) m3ffxtbr@mywebsearch.com
      5% (25/469) vs.   0% (61/58517) {5a95a9e0-59dd-4314-bd84-4d18ca83a0e2}
      6% (28/469) vs.   1% (462/58517) ffxtlbr@funmoods.com

The first ones should be analyzed by the add-on team.
(In reply to Scoobidiver from comment #23)
>      47% (220/469) vs.   0% (275/58517) browseforchange@browseforchange.com

It's available for download here: http://browseforchange.com/Download
Andrew tested it and didn't get it to crash. The add-on doesn't have any binaries but it does has a bunch of code quality problems, like heavy eval usage. It injects remote scripts into websites.

>      25% (119/469) vs.   2% (1293/58517) plugin@yontoo.com

http://www.yontoo.com/Download.aspx
Also no binaries, and also injects remote scripts into websites. 

>      24% (111/469) vs.   1% (462/58517) crossriderapp2258@crossrider.com

I couldn't find this one. It is built using this cross-browser add-on platform: http://crossrider.com/. Looking into SUMO and other sites, the add-on is called "I Want This" and it is potentially malware: 
http://www.greatis.com/appdata/d/i/i%20want%20this.dll.htm
http://www.threatexpert.com/report.aspx?md5=be935705b8902b5407e196b2248e568b
Note that js_GetIndexFromBytecode was removed in bug 720316, so this signature won't be around in a release or two or so.
(In reply to Jeff Walden (:Waldo) (remove +bmo to email) from comment #25)
> Note that js_GetIndexFromBytecode was removed in bug 720316, so this
> signature won't be around in a release or two or so.
bug 737780 is the new form of this bug in 13.0a2 because it has the same correlations per extension.
There are no crashes in 13.0.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.