1096290 - Crash [@ js::ObjectImpl::getSlot(unsigned int) ] Browser crashes when executing an action in GWT application

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine: JIT, defect)

Description

[Jan Swaelens]

Hello,

We are using ESR 31.2.0 as a preferred browser for our GWT application.

For some time now we get browser crashes when a user performs a certain action in  our application, for example opening a customer detail view.

When the user does this the browser completely crashes - this does not happen for all of our users.

We have no idea how this can be caused by our application code, but are of course open for pointers in that direction as well.

Please help us identifying the cause. I am sending a crash report from within the dialog it shows after the crash in a few minutes.

How can we provide additional information you need to investigate this?

thanks

Comment 1

[:Gijs (he/him)]

Can you provide a link to the application in question?

Can you provide crash report IDs / links from the Firefox crash reporter? (there should be a list under about:crashes)

Can you provide more information about what OS those users are running, and if your webpage uses any plugins (flash, java, ...)?

Comment 2

[Jan Swaelens]

Hello,

Sadly no, it is an internally hosted application which I am not allowed to expose. If we get to a point that there is no alternative to proceed I might be able to get you access but it will require me to jump trough a lot of hoops.

These are the reports:
https://crash-stats.mozilla.com/report/index/e19325f6-b385-4c4d-957a-90e3e2141110
https://crash-stats.mozilla.com/report/index/dfc5ba48-d0df-46b6-a740-9e8992141110
https://crash-stats.mozilla.com/report/index/e36acd2b-5f31-4277-a7d5-d9ee32141110

The OS these where caught on are Windows 7 (64bit) with SP1, other users are on the same kind of setup.

I have the following:
Extensions: none
Appearance: default theme
Plugins:
- Adobe Acrobat
- Citrix Online Web Deployment Plugin
- Google Update
- Java Deployment Toolkit 7.0.510.13
- Java(TM) Platform SE 7 U51
- Microsoft Lync Web App Plug-in
- Microsoft Office 2010
- Shockwave Flash

All of the plugins are marked as 'ask to activate', also tried with setting them to 'Never Activate' but the error still happens.

I also tried with disabling hardware acceleration (as recommended by the guide as things to try) but no luck. Also tried with resetting firefox but the problem still happens.

It seems though that when running the browser in safe mode the issue does not happen - but I don't understand how this is different with disabling all plugins & hardware acceleration.

The crash reports seem to point to a JS issue, which might make sense since it is happening on a GWT application.

thanks
jan

Comment 3

[:Gijs (he/him)]

(In reply to Jan Swaelens from comment #2)
> Hello,
> 
> Sadly no, it is an internally hosted application which I am not allowed to
> expose. If we get to a point that there is no alternative to proceed I might
> be able to get you access but it will require me to jump trough a lot of
> hoops.

Thanks. I don't know if we'll need to; maybe Jan can tell what's going on from the dumps, maybe not...

Assuming this is pretty quickly reproducible, can you check if this happens on non-ESR versions of Firefox? And/or which versions are/aren't OK?

> These are the reports:
> https://crash-stats.mozilla.com/report/index/e19325f6-b385-4c4d-957a-
> 90e3e2141110
> https://crash-stats.mozilla.com/report/index/dfc5ba48-d0df-46b6-a740-
> 9e8992141110
> https://crash-stats.mozilla.com/report/index/e36acd2b-5f31-4277-a7d5-
> d9ee32141110

Thanks, these are helpful!

> It seems though that when running the browser in safe mode the issue does
> not happen - but I don't understand how this is different with disabling all
> plugins & hardware acceleration.
> 
> The crash reports seem to point to a JS issue, which might make sense since
> it is happening on a GWT application.

Your (educated) guess is right: safe mode disables some of the JIT functionality, making JS more stable... but also slower. That's why you can't reproduce in safe mode.


Jan, can you have a look at these crashes, please? :-)

Comment 4

[Jan Swaelens]

Works fine on:
33.1
32.0.3

Does not work on:
31

(all regular non esr releases)

Hope this helps.

Comment 5

[Jan de Mooij [:jandem]]

Jan, thank you for the report.

Based on the stack traces, we're crashing while doing an obj[int] operation where obj is a JS |arguments| object. It might be useful to look at the JS code and see where and how you use |arguments|...

Also, if I give you a special ESR 31 build, would you be able to test it and get some debugging output?

Comment 6

[Jan Swaelens]

Hello,

Thanks for looking into this, I can provide you JS code but since we use GWT it is all generated based on Java code - in addition to that we are using SmartGWT which is a library full of JS. In total it results in massive amounts of JS files. Can you point me to a specific area somehow based on the crash data?

I surely will be able to test with a debug build.

thanks

Comment 7

[Jan de Mooij [:jandem]]

(In reply to Jan Swaelens from comment #6)
> I surely will be able to test with a debug build.

Oh, I was thinking I could get you a build with some logging so we can narrow it down to a specific JS function in the source code. But let's first try a normal debug build:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-esr31-win32-debug/1415904613/firefox-31.2.1esrpre.en-US.win32.zip

Can you check if it still crashes and if it prints something to the console if it does, like an assertion failure?

Comment 8

[Jan Swaelens]

Attachment: console.log

Yes, it still crashes - I attached the console log hope it is what you needed.

thanks!

Comment 9

[Jan de Mooij [:jandem]]

(In reply to Jan Swaelens from comment #8)
> Yes, it still crashes - I attached the console log hope it is what you
> needed.

Yes thank you. We have an assertion failure because we assume a value is an object but it isn't. I'll get you the same build but with some extra logging so that we can track it down more easily.

Comment 10

[Jan de Mooij [:jandem]]

Here's the build with the extra logging:

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-1b1167dcf5f7/try-win32-debug/firefox-31.2.1esrpre.en-US.win32.zip

Hopefully it will print the file + lineno of the function we're in before it crashes. Please also attach that function if possible :)

Comment 11

[Jan Swaelens]

Attachment: crashlog2.txt

Hello,

Please find the new attached output, it indeed points to at least a source line in one of our 3d party JS files (also attaching that one).

Loc: http://10.7.64.162:9081/milesria/milesria/sc/modules/ISC_Core.js?sv=51260c2
0f4a6373ead66f6d86372562a4d6711f9:796 (211562-212299)
getElement: 0 (undefined)

Thanks
jan

Comment 12

[Jan Swaelens]

Attachment: ISC_Core.js

Comment 13

[Jan de Mooij [:jandem]]

Thanks! Can you see what happens if you go to about:config and set the "javascript.options.ion" pref to "false" and restart?

Comment 14

[Jan Swaelens]

When I make that configuration change & restart the browser & execute my test scenario ... it works!

Comment 15

[Jan de Mooij [:jandem]]

OK, thanks again. I started another build with some more logging but the build will take at least an hour. Files will appear here:

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-ddf2c3e3b490

Will let you know when it's done.

Comment 16

[Jan de Mooij [:jandem]]

New build here:

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-ddf2c3e3b490/try-win32-debug/firefox-31.2.1esrpre.en-US.win32.zip

Comment 17

[Jan Swaelens]

Thanks! And here's the additional log:

Loc: http://10.7.64.162:9081/milesria/milesria/38CA11CA5CABFA5BA03FE6CBBB984EC8.
cache.html:6291 (26840-27463)
Done
Getting argument: 0
Loc: http://10.7.64.162:9081/milesria/milesria/sc/modules/ISC_Core.js?sv=51260c2
0f4a6373ead66f6d86372562a4d6711f9:796 (211562-212299)
getElement: 0 (undefined)
Magic: 16, (0-17)
Containing script: http://10.7.64.162:9081/milesria/milesria/sc/modules/ISC_Core
.js?sv=51260c20f4a6373ead66f6d86372562a4d6711f9:265
Assertion failure: isObject(), at c:\builds\moz2_slave\try-w32-d-000000000000000
00000\build\obj-firefox\dist\include\js/Value.h:1157



thanks
jan

Comment 18

[Jan de Mooij [:jandem]]

In ArgumentsObject::element() we have a MagicValue(JS_OPTIMIZED_OUT). Then we crash there because MAYBE_CALL_SLOT is UndefinedValue(). The arguments object seems to be coming from fun.arguments; the function itself doesn't use arguments. This looks like bug 1001378 and/or bug 1005458, although I can't find that code in Firefox 32 so it's probably not just those patches we should backport...

Shu, can we fix this for the next ESR31 release?

Jan, thanks for your help. This bug has been fixed in Firefox 32 but unfortunately wasn't backported to ESR31. You can probably workaround the crashes by disabling the call tracing code...

Comment 19

[Jan Swaelens]

My pleasure, I think we can wait for the next ESR update though - any idea on timing there?

Comment 20

[Jan de Mooij [:jandem]]

(In reply to Jan Swaelens from comment #19)
> My pleasure, I think we can wait for the next ESR update though - any idea
> on timing there?

The ESR 31.3 release will be Nov 25 as far as I can see; not sure if we can get this fixed in time for that. 31.4 will be ~6 weeks later. The next major release will be ESR 38 (May 2015).

Comment 21

[Jan de Mooij [:jandem]]

[Tracking Requested - why for this release]:

Comment 22

[Jan Swaelens]

Thanks, please let me know where it will be include once that it is known, so I can communicate to our users.

Comment 23

[Shu-yu Guo [:shu]]

(In reply to Jan de Mooij [:jandem] from comment #18)
> In ArgumentsObject::element() we have a MagicValue(JS_OPTIMIZED_OUT). Then
> we crash there because MAYBE_CALL_SLOT is UndefinedValue(). The arguments
> object seems to be coming from fun.arguments; the function itself doesn't
> use arguments. This looks like bug 1001378 and/or bug 1005458, although I
> can't find that code in Firefox 32 so it's probably not just those patches
> we should backport...
> 
> Shu, can we fix this for the next ESR31 release?
> 
> Jan, thanks for your help. This bug has been fixed in Firefox 32 but
> unfortunately wasn't backported to ESR31. You can probably workaround the
> crashes by disabling the call tracing code...

The patch for bug 1005458 subsumes the patch in 1001378. I'll post a backport patch in bug 1005458.

Comment 24

[Jan Swaelens]

Hello, I tested today on the 31.3.0 release but the problem still occurs - didn't the fix made it or is there still another issue? Just to make sure that there is still an issue or that it will be fixed in the next one?

thanks

Comment 25

[Wayne Mery (:wsmwk)]

(In reply to Jan Swaelens from comment #24)
> Hello, I tested today on the 31.3.0 release but the problem still occurs -
> didn't the fix made it or is there still another issue? Just to make sure
> that there is still an issue or that it will be fixed in the next one?
> 
> thanks

Is it still failing in version 38?

Comment 26

[Wayne Mery (:wsmwk)]

Let's make this simpler. https://crash-stats.mozilla.com/report/list?signature=js%3A%3AObjectImpl%3A%3AgetSlot#tab-reports has no crashes after version 32, so looks like it was fixed

Please reopen if you still see the crash.