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

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: jan.swaelens, Unassigned)

Tracking

({crash})

31 Branch
All
Windows 7
crash
Points:
---

Firefox Tracking Flags

(firefox-esr3134+ affected)

Details

(crash signature)

Attachments

(2 attachments, 1 obsolete attachment)

10.47 KB, text/plain
Details
905.43 KB, application/javascript
Details
(Reporter)

Description

4 years ago
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

4 years ago
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, ...)?
Flags: needinfo?(jan.swaelens)
(Reporter)

Comment 2

4 years ago
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
Flags: needinfo?(jan.swaelens)

Comment 3

4 years ago
(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? :-)
Crash Signature: [@ js::ObjectImpl::getSlot(unsigned int) ]
Component: Untriaged → JavaScript Engine: JIT
Flags: needinfo?(jdemooij)
Product: Firefox → Core
Summary: Browser crashes when executing an action in GWT application → Crash [@ js::ObjectImpl::getSlot(unsigned int) ] Browser crashes when executing an action in GWT application
(Reporter)

Comment 4

4 years ago
Works fine on:
33.1
32.0.3

Does not work on:
31

(all regular non esr releases)

Hope this helps.
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?
Flags: needinfo?(jan.swaelens)
(Reporter)

Comment 6

4 years ago
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
Flags: needinfo?(jan.swaelens)
(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?
(Reporter)

Comment 8

4 years ago
Created attachment 8522928 [details]
console.log

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

thanks!
(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.
Flags: needinfo?(jdemooij)

Updated

4 years ago
Flags: needinfo?(jdemooij)
Here's the build with the extra logging:

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jandemooij@gmail.com-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 :)
Flags: needinfo?(jan.swaelens)
(Reporter)

Comment 11

4 years ago
Created attachment 8523697 [details]
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
Attachment #8522928 - Attachment is obsolete: true
Flags: needinfo?(jan.swaelens)
(Reporter)

Comment 12

4 years ago
Created attachment 8523698 [details]
ISC_Core.js
Thanks! Can you see what happens if you go to about:config and set the "javascript.options.ion" pref to "false" and restart?
Flags: needinfo?(jdemooij) → needinfo?(jan.swaelens)
(Reporter)

Comment 14

4 years ago
When I make that configuration change & restart the browser & execute my test scenario ... it works!
Flags: needinfo?(jan.swaelens)
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/jandemooij@gmail.com-ddf2c3e3b490

Will let you know when it's done.

Updated

4 years ago
Flags: needinfo?(jdemooij)
(Reporter)

Comment 17

4 years ago
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
Flags: needinfo?(jan.swaelens)
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...
Flags: needinfo?(jdemooij) → needinfo?(shu)
(Reporter)

Comment 19

4 years ago
My pleasure, I think we can wait for the next ESR update though - any idea on timing there?
(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).
[Tracking Requested - why for this release]:
status-firefox-esr31: --- → affected
tracking-firefox-esr31: --- → ?
(Reporter)

Comment 22

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

Comment 23

4 years ago
(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.
Flags: needinfo?(shu)
tracking-firefox-esr31: ? → 34+
(Reporter)

Comment 24

4 years ago
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

Updated

3 years ago
Crash Signature: [@ js::ObjectImpl::getSlot(unsigned int) ] → [@ js::ObjectImpl::getSlot(unsigned int) ] [@ js::ObjectImpl::getSlot ]

Comment 25

3 years ago
(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?
Severity: normal → critical
Flags: needinfo?(jan.swaelens)
Keywords: crash

Comment 26

3 years ago
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(jan.swaelens)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.