1140616 - (CVE-2015-7196) crashes in GC with Java applet

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[vcoolas]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150305021524

Steps to reproduce:

We have internal Enterprise application that runs mix of GWT javascript and Java applets in browser (that is why providing link is not feasible). Lately we have noticed that whenever Java applet is involved, Firefox will crash. Not necessarily right away, but working with application in areas that involve Java applet will sooner or later always cause crash. There are no exact steps to reproduce issue as it looks to be different every time, but end result is always the same.

It looks to happen when either applet is about to be loaded or removed by Javascript. Which is done by adding and removing "embed" tag to document. When started, Java applet itself seems to be running always ok.

This problem happens with Firefox 35.0, 35.1, 36, 37 and 38. Not reproducible using Firefox 34, Firefox ESR 31.5. Neither it is reproducible with Chrome or Internet Explorer, any version.
OS is Windows 7 Enterprise (but reproduced on other various Windows OSes), problem reproduced with Java 7 update 72 and 75, Java 8 update 31 and 40.


Actual results:

https://crash-stats.mozilla.com/report/index/bp-457abcba-67c2-4d84-bd3a-68b652150306
https://crash-stats.mozilla.com/report/index/bp-19c7d138-3d35-4e15-957b-cb18b2150306
https://crash-stats.mozilla.com/report/index/bp-dacefcb6-59c9-430e-a38b-1ca002150306
https://crash-stats.mozilla.com/report/index/bp-0e43153f-1cf4-4a81-a233-44deb2150306
https://crash-stats.mozilla.com/report/index/bp-c03f84f6-e303-4332-bac7-907dd2150306
https://crash-stats.mozilla.com/report/index/bp-e4b683ce-2aa1-42f3-8791-4fef72150305
https://crash-stats.mozilla.com/report/index/bp-c9ae0a6a-5f90-42aa-a469-e031a2150305
https://crash-stats.mozilla.com/report/index/bp-9c023cba-8c77-4000-b751-3dcdf2150305
https://crash-stats.mozilla.com/report/index/bp-4a372eb0-43ca-4916-b0fe-3db012150305
https://crash-stats.mozilla.com/report/index/bp-00a4dbed-7a11-418e-b9b7-7720d2150213


Expected results:

no crashes

Comment 1

[Wayne Mery (:wsmwk)]

The first for crashes are all [@ js::Nursery::MinorGCCallback(JSTracer*, void**, JSGCTraceKind) ], which may make this related to bug 991746, but perhaps not a duplicate, given that 991746 exists in version 31 but you say version 34 and 31.5.0 work for you

Comment 2

[vcoolas]

All crash signatures were produced with same setup. Firefox 34 was installed on the same machine and there were no crashes. Firefox ESR 31.5 also has no problems, although it is run on different host, but same OS - Windows 7. Firefox 35 and 36 crash all the time with same application/web page containing applets, on different Windows OSes on different hosts.

Not sure if it is the same issue, could be, but other crashes of same thing have different signatures. Is there anything I could help trace issue? Unfortunately, there is no public access to the page that causes issue, but maybe something could be arranged privately, as I am developer from team that produces this Web application that causes crash in Firefox.

Comment 3

[Jan de Mooij [:jandem]]

(In reply to vcoolas from comment #2)
> Is there anything I could help trace issue?

Would you mind trying this debug build?

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-release-win32-debug/1426976301/firefox-36.0.4.en-US.win32.zip

Please let us know if it also crashes and attach the console output to this bug if it does (it should open a new console window when you start it, I think).

Comment 4

[Terrence Cole [:terrence]]

We appear to have introduced a bug in NPAPI in 35 that causes us to somehow embed a broken pointer into the store buffer. Unfortunately, there's not much in the existing stacks that helps much as the error happens long before the GC trips over it. Hopefully the debug build will show something up; otherwise someone with a debugger will need to backtrack the problem.

Comment 5

[vcoolas]

Attachment: firefox.zip

I am attaching console output logs from four runs. Except for one case, crashes with this debug version seem to happen much faster. Firefox crashed in every test run.

Comment 6

[Terrence Cole [:terrence]]

Assertion failure: CurrentThreadCanAccessRuntime(rt), at c:\builds\moz2_slave\m-rel-w32-d-000000000000000000\build\js\src\gc/Heap.h:1190

Nice! We need the backtrace from that line. Do you have link to the crash-stats upload?

Comment 7

[vcoolas]

Unfortunately, when debug version crashes, window to submit crash information does not even show up. Windows only show dialog that application needs to be closed. Maybe crash information gets saved somewhere locally on disk? If yes, where? Or maybe Firefox could be started with some additional options to produce this information?

I have just unzipped indicated archive with debug version and ran. Should I install/register something to get crash reporter application to pop up?

Comment 8

[MS]

Hello all,
Any progression on this bug ?
We also have a web application loading a Java Applet, and since Firefox 35 the browser crashes when the applet is unloaded. This issue is really critical...

I'm sorry but I can't share with you any public link of our web application because the product is not public.

Crash reports:
https://crash-stats.mozilla.com/report/index/9b310cd6-6ea4-4614-adfd-cc0992150402
https://crash-stats.mozilla.com/report/index/b8166c59-deda-4433-93ed-e52722150323
https://crash-stats.mozilla.com/report/index/753fa1e3-e2f8-4c9f-b982-71bfe2150323
https://crash-stats.mozilla.com/report/index/4fdc8917-343b-4050-b5dc-6b5c82150323

Comment 9

[iannakin]

I have a similar issue,

Firefox 37 crashes regularly (but not always) on a page where javascript code invokes methods from a java applet, but the crash only occurs when submitting the page.

Any work on this bug ?

(see : https://crash-stats.mozilla.com/report/index/45b27ef7-759f-42c9-a1e0-b4de62150415)

Comment 10

[pavrw]

Hi


Since a couple of weeks we are reproducing similar behaviour with our applet using FF 37.0.2 and different versions of Java (7u79, 8u45). Not happening with 31.6 (havent tried other versions).

This is more or less the scenario we are currently analyzing:
 -Browse foo.htm which loads an applet (OK)
 -Invoke function foo that loads and some libraries (NSS) for signature (OK)
 -Invoke function foo that loads and some libraries (NSS) for signature (OK)
 - ...you can do this as many times as you want...
 -Invoke function foo that loads and some libraries (NSS) for signature (OK)
 -Browse (as fast as you can after using the applet) to bar.htm
 -Result: Firefox crash

Java console is showing a java.lang.InterruptedException, and seems Java plugin is crashing on Applet unload, causing a Firefox Crash.

I could agree the applet is doing something wrong, but a plugin crash should never crash the browser!

Can you give us some feedback?

Comment 11

[pavrw]

Not happening on Ubuntu 14.04 amd64 neither with OpenJDK (7u79) or Oracle (8u45). Also happening on Windows 7 x86.


Current working test:
-Go to foo.htm (applet load)
-invoke/use applet (our applet is currently doing a lot of things, so we have still to analize if this is an issue that depends on applet code)
-CTRL+F5 = firefox crash

Comment 12

[Terrence Cole [:terrence]]

Maybe I'm missing something, but where is foo.htm?

Comment 13

[pavrw]

LOL...thats was just an example!. I'll try to have a simple testcase ASAP ;)
Are you going to be the one dealing with this problem?

Comment 14

[Terrence Cole [:terrence]]

It depends where the bug is. If we're crashing in GC it's generally because the heap got hosed at some point in the distant past -- I can't even tell you where the bug is without being able to reproduce it locally and walk backwards from the crash.

Comment 15

[Victor]

Hi all, 

there's any progression on this bug? Or any workaround?

Thanks.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

We would need to be able to reproduce the bug. Victor, are you seeing this crash? Can you give us more information?  A crash signature from about:crashes maybe? Thanks.

Comment 17

[Liz Henry (:lizzard) (relman/hg->git project)]

Right now, we have some crashes with this signature on 38.0.5 but none for 39+.

Comment 18

[Victor]

Hi Liz, 

I don't know if you are asking this, but this is the crash ID that I got yesterday: bp-ab3c08fb-f52e-4165-a117-d2fe92150622

I am using Firefox ESR 38.0.1

Tell me if you need something more.

Thanks.

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

[Tracking Requested - why for this release]:  Regression, crash, is appearing in ESR.

Comment 20

[Victor]

Hi Liz,

it seems that in Firefox 39, this error is not appearing. Do you know if the next release of Firefox ESR will have the fix apparently introduced in Firefox 39?
I mean, Firefox ESR 38.2 will have this fix?

Thanks.

Comment 21

[iannakin]

(In reply to Victor from comment #20)
> Hi Liz,
> 
> it seems that in Firefox 39, this error is not appearing. Do you know if the
> next release of Firefox ESR will have the fix apparently introduced in
> Firefox 39?
> I mean, Firefox ESR 38.2 will have this fix?
> 
> Thanks.

Hi Victor,
Actually, it does affect version 39, and even beta 40.0.
I don't know why someone told that it was not appearing, because after just 1 minute of testing I could crash FF.
Cheers

Comment 22

[Victor]

Yes, it does affect version 39. This is the signature: bp-0ea63e95-addd-48e2-ab4b-7471b2150720

Comment 23

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Let's try to see if we can get this fixed for ESR38 release. 

Naveed, can you please help find an owner for this issue? We are hoping to get a fix soon. Thanks!

Comment 24

[Jan de Mooij [:jandem]]

Victor, iannakin, anyone: it'd be incredibly useful if one of us at Mozilla could get access to a page that crashes reliably so we can debug this.

A remote desktop session might also work, but we'd probably have to install some developer stuff so it'd be more time consuming.

Comment 25

[Jan de Mooij [:jandem]]

Victor gave me access to a crashing website and I was able to reproduce this on Windows \o/

After spending some quality time with Visual Studio, it looks like the Java plugin is deallocating nsJSObjWrapper on a thread other than the main thread.

nsJSObjWrapper's Heap<JSObject*> member is not happy with this scheme: we don't remove the store buffer entry if the Heap<JSObject*> is destructed on another thread, so the next GC will crash because it has a bogus CellPtrEdge :(

While testing this, I also sometimes got it to fail the assert in isOkayToUseBuffer, when the main thread is doing a GC while we're destructing our Heap member.

The plugin code right now breaks the single-threaded-JSRuntime invariant and I'm not sure how to fix it. It seems we could either (1) MOZ_CRASH if we're on a different thread, and let Oracle et al deal with it (can we get away with this?) or (2) avoid deallocating the nsJSObjWrappers immediately but flag them and deallocate them later on the main thread (the plugin code is really complicated, no idea if this is feasible..).

Comment 26

[Boris Zbarsky [:bzbarsky]]

Hmm.  I don't really know that much about this code (ccing some people who might), but I assume that it's nsJSObjWrapper::NP_Deallocate that's being called on the wrong thread?  I see nothing in principle impossible about handing that delete call to the main thread; the question is whether anything relies on the NP_Invalidate in its destructor happening eagerly, I guess. I assume the OnWrapperDestroyed bit is ok to be called a bit later when the wrapper is really destroyed.

Comment 27

[Jan de Mooij [:jandem]]

(In reply to Boris Zbarsky [:bz] from comment #26)
> but I assume that it's nsJSObjWrapper::NP_Deallocate that's being
> called on the wrong thread?

Yes, the plugin calls _releaseObject and that calls NP_Deallocate. _releaseObject has a log message when it's called on the wrong thread, but that's easy to ignore:

https://hg.mozilla.org/mozilla-central/file/888e8026ed60/dom/plugins/base/nsNPAPIPlugin.cpp#l1394

If _releaseObject could set a flag indicating the nsJSObjWrapper can be destroyed, then presumably DelayedReleaseGCCallback could do the actual deallocation, it already has some similar code.. We'd have to be careful to ignore any flagged nsJSObjWrapper entries when we do hash table lookups though, there are at least two such tables.

It would be great if someone familiar with the plugin code could take a look.

Comment 28

[Andrew McCreight [:mccr8]]

Benjamin, do you have any ideas? You've looked at some "plugins doing stuff on the wrong thread" stuff recently. Thanks.

Comment 29

[Luis]

Hi All,

Are there any news on this bug? Will be solved in ESR 38.2 or 38.3? 

We have recommended to our community of hundreds of organizations and  many thousands of users to use Firefox ESR. It was good for us because the community avoid this error from version 35 to 40 because we have firefox ESR 31 working perfectly.  Now with the last version ESR31.8 

Now we have a complicated situation because I think that tomorrow the version Firefox ESR 38.2 will be released and the users with ESR 31.8 will be updated to ESR 38.2.

If this bug still exists in ESR38.2 we have to recommend to our community to disabled updates and stay in ESR 31.8 with the security risk associated (only a temporary solution) or migrate to Internet Explorer 11 as the final solution.

We have critical use cases of our business affected by this bug, so any information or workaround to avoid them will be  

Thanks in advance
Luis

Comment 30

[Jan de Mooij [:jandem]]

(In reply to Jan de Mooij [:jandem] from comment #25)
> It seems we could either (1) MOZ_CRASH if we're
> on a different thread

bsmedberg suggested we do this. I'll work on a patch.

Comment 31

[Benjamin Smedberg]

We should have a main-thread check in _releaseObject (NPN_ReleaseObject) and crash if it's called on the wrong thread. Also this is clearly a bug in the Java plugin and if you can reproduce it you should report it to Oracle support.

Comment 32

[Jan de Mooij [:jandem]]

Attachment: Patch

This patch adds a MOZ_CRASH to _releaseObject. I confirmed we hit this crash on the page where I can reproduce the problem.

I kept the NPN_PLUGIN_LOG call, because MOZ_CRASH doesn't print anything in opt builds and the logging might be useful to someone.

Comment 33

[Jan de Mooij [:jandem]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #31)
> Also this is clearly a bug in the
> Java plugin and if you can reproduce it you should report it to Oracle
> support.

I reported it to Oracle (http://bugreport.java.com) Let's hope they take it seriously and get back to us soon.

Comment 34

[Luis]

Hi!
Are you planning to give to the community any workarround before the answer of Oracle? or are you waiting for Oracle?
Do you have any ideas of the planning of the solution?
Thanks in advance,
Luis

Comment 35

[Benjamin Smedberg]

Comment on attachment 8646867 [details] [diff] [review]
Patch

This is going to cause user regressions :-(

I wonder if we should move Java back out of process at the same time.

Comment 36

[Jan de Mooij [:jandem]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #35)
> I wonder if we should move Java back out of process at the same time.

I've no idea how that works so someone else would have to do that. Let me know if we should wait for that, else I'll land this on Monday.

Comment 37

[Benjamin Smedberg]

Attached a patch to move Java OOPP in bug 874176. I propose that they land together.

Comment 38

[Jan de Mooij [:jandem]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #37)
> Attached a patch to move Java OOPP in bug 874176. I propose that they land
> together.

Bug 874167 seems to have stuck so I pushed this:

https://hg.mozilla.org/integration/mozilla-inbound/rev/51f188b7abd8

Comment 39

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

https://hg.mozilla.org/mozilla-central/rev/51f188b7abd8

Comment 40

[Liz Henry (:lizzard) (relman/hg->git project)]

OK, so as I understand this, now Firefox 43 users (and ESR versions built from 43, if we take this patch and the one in bug 874167 for the next ESR) will still crash sometimes when using Java applets, but the crash will be safer or potentially less exploitable.   

Benjamin do you want to request uplift for this to 42 or further? If we do that, would it need both patches?

It's hard to tell here what the tradeoff would be for ESR, though I'd lean toward crashing more often but more safely.

Comment 41

[Benjamin Smedberg]

On the non-ESR branches, we should take both patches at least to 42.

I don't know what to do about ESR: both patches will have some compatibility issues with Java hangs or crashes. Moving Java out-of-process will keep Firefox alive but Java's going to keep crashing regardless of what we do here. That fix has to come from Oracle.

Comment 42

[Benjamin Smedberg]

Donald, I think you should be aware of this as well as bug 874167.

Comment 43

[Liz Henry (:lizzard) (relman/hg->git project)]

Jan can you nominate for uplift?

Comment 44

[Jan de Mooij [:jandem]]

Comment on attachment 8646867 [details] [diff] [review]
Patch

Nominating for Aurora to match bug 874167.

Approval Request Comment
[Feature/regressing bug #]: Java plugin issue.
[User impact if declined]: Plugin crashes, maybe security related. This patch makes us crash immediately before things go off the rails.
[Describe test coverage new/current, TreeHerder]: On m-c for a few days.
[Risks and why]: More Java plugin crashes.
[String/UUID change made/needed]: None.

Comment 45

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8646867 [details] [diff] [review]
Patch

Make sense to take it in 42. Thanks

Comment 46

[Sylvestre Ledru [:Sylvestre]]

Wontfix for 41 (cf comment #41)

Comment 47

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6a513309283d

Comment 48

[Liz Henry (:lizzard) (relman/hg->git project)]

Let's look at uplifting this again for ESR 38.4.0, since it's not in beta 41.

Comment 49

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Jan, do you think we should consider fixing this in ESR38.4.0? Based on comment 41, it seems moving the java plug-in out of proc (even though it keeps crashing) is better than Firefox crashing. Thoughts?

Comment 50

[Jan de Mooij [:jandem]]

(In reply to Ritu Kothari (:ritu) from comment #49)
> Jan, do you think we should consider fixing this in ESR38.4.0? Based on
> comment 41, it seems moving the java plug-in out of proc (even though it
> keeps crashing) is better than Firefox crashing. Thoughts?

The patch here is trivial to backport, but we'd also have to backport bug 874167, so I'll forward this to bsmedberg.

Comment 51

[Benjamin Smedberg]

Moving Java OOP will cause compatibility issues for enterprise users. We should probably not mess with ESR unless there is no other way to fix the security issue.

Comment 52

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

I looked at the crash reports for this one and the product breakdown indicates this is showing up on Thurderbird 38.3.0 with a total of 19 crashes. 

Benjamin, given the complexity of fixing this in esr38 (no straight forward fix), do you suggested we wontfix this or leave it open and wait for more data from ESR38.4.0?

Comment 53

[Benjamin Smedberg]

What more data? The question from comment 51 was about security evaluation, not about data.

Comment 54

[Al Billings [:abillings - ex-MoCo]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #48)
> Let's look at uplifting this again for ESR 38.4.0, since it's not in beta 41.

Here we are and it didn't make it...

Comment 55

[Liz Henry (:lizzard) (relman/hg->git project)]

This never got a security rating (partly my fault as I didn't notice this lacked a rating or sec-approval). 

Breaking compatibility in some unknown way sounds worse to me than this crash. How bad is it that we fixed this without fixing it in ESR? (thus potentially revealing the vulnerability)?  
Is there another way we could address the security issue without moving Java OOP? 
I don't want to land this on ESR and cause possibly worse regressions for the people already crashing and potentially everyone else using ESR.  
Is this worth doing more investigation or trying to figure out what this and the patch from bug 874167 would break?

With all these questions still up in the air, I am leaning towards the thought we need to bother Oracle more to fix this on their side, and keep wontfixing this for ESR, though that is depressing.

Comment 56

[Victor]

Hi, does it mean that this issue won't be fixed in ESR 38.4.0?

Comment 57

[Al Billings [:abillings - ex-MoCo]]

Victor, it seems unlikely as we're making final ESR builds real soon now.

Comment 58

[Liz Henry (:lizzard) (relman/hg->git project)]

Jan, should we still be backporting this to ESR if we don't also take bug 874167 (Which Benjamin says we should not take in ESR)? Will it at least fix the security issue (even if we still crash)?

Comment 59

[Jan de Mooij [:jandem]]

Comment on attachment 8646867 [details] [diff] [review]
Patch

Nominating for ESR38 as discussed.

[Approval Request Comment]
User impact if declined: Security issues.
Fix Landed on Version: Backported to 42+
Risk to taking this patch (and alternatives if risky): More (intentional) browser crashes when plugins misbehave.
String or UUID changes made by this patch: None.

Comment 60

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8646867 [details] [diff] [review]
Patch

May be crashier but more secure crashes anyway.
Approved for uplift to esr38.

Comment 61

[Luis]

Hi All,

As I explained we recommended to our community of hundreds of organizations and many thousands of users to use Firefox ESR. It was good for us because the community avoid this error from version 35 to 40, because we have firefox ESR 31 working perfectly until ESR31.8 

Now we have a complicated situation after Firefox ESR 38.2 was published and Firefox is asking for updates and there are no security updates for ESR31. Administrators are working to achieve users continue with ESR31.8 but this situation is bad because of security.

Our solutions are: 
-- recommend to our community to disabled updates and stay in ESR 31.8 with the security risk associated (only a temporary solution). We are in this situation Now 
-- or migrate to Internet Explorer 11 or Edge as the final solution for clients that doesn’t accept the risk 

We have critical use cases of our business affected by this bug, so any information or workaround to avoid them will be grateful. We were wating for a possible solution in 38.4  but if you won’t fix in 38.4 our problem is bigger.

For us:
-- there is an important regression between 31 ESR and 38 ESR
-- Is it possible to collaborate in anyway?
---- Maybe you can build a beta version with this changes and our team tester can verify if with this fix our regression disappears. Maybe we are wating for nothing.
-- Maybe you can create a parameter to control this issue. You can introduce this patch but disabled by default and we can enabled with a parameter in [about:config] 

I think is better for security and disponibility of firefox to execute JAVA OOP.

Thanks in advance,
Luis

Comment 62

[Liz Henry (:lizzard) (relman/hg->git project)]

Luis,  the fix will be in ESR 38.4.0. I haven't built it yet. It should release next Tuesday.

Comment 63

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-esr38/rev/256edca6ccf5

Comment 64

[Luis]

Thanks it's good news for us 
We are going to test the 38.4 next Tuesday

Comment 65

[Camelia Badau [:cbadau], Desktop QA]

Can you please verify that the issue is fixed on Firefox 42 and on ESR 38.4.0? I cannot reproduce the initial issue and thus I can't verify it.

Comment 66

[Liz Henry (:lizzard) (relman/hg->git project)]

Luis, if you want to give it a try now, here is the current release candidate for ESR 38.4.0, hope that helps.  

https://ftp.mozilla.org/pub/firefox/candidates/38.4.0esr-candidates/build2/

Comment 67

[Victor]

I have tested the release candidate and still crashes, but with a different signature (mozilla::plugins::parent::_releaseobject)

This is the ID:   ba750b9c-8688-4e95-b3f3-994292151029

Comment 68

[Luis]

Sadly, It's the same as Victor, Firefox still crash. Can we help you in anyway?

Comment 69

[Victor]

Jan had access to our application where he was able to reproduce the issue. Do you still have access Jan? Were you able to reproduce the problem with this new version?

Liz, if you need access too I can send you the instructions to connect and reproduce the problem.

If there's something more that we can do for you, please tell us.

Thanks.

Comment 70

[Jan de Mooij [:jandem]]

(In reply to Victor from comment #67)
> I have tested the release candidate and still crashes, but with a different
> signature (mozilla::plugins::parent::_releaseobject)

The patch in this bug just makes the browser crash when the Java plugin misbehaves, before it can corrupt memory and cause crashes or security issues later on. So unfortunately that crash is expected. It's up to Oracle to fix the Java plugin.

Bug 874167 moved the Java plugin out-of-process, so that only the plugin crashes and not the whole browser. That patch wasn't backported to ESR 38 though.

Comment 71

[Victor]

Thanks Jan.

Do you know if Bug 874167 can be included in ESR 38.4.0?

Comment 72

[Benjamin Smedberg]

No, we will not include bug 874167 into the ESR because it has more serious compatibility concerns.

Comment 73

[David DeHaven]

What was the bug ID for the bug submitted to java.com? Also, can someone provide a link to an example that causes the crash? If one is provided in the bug report then that should be fine, but I need the JI number.

Comment 74

[David DeHaven]

I found the JBS issue:
https://bugs.openjdk.java.net/browse/JDK-8133523

A sample would be very helpful in evaluating this.

Comment 75

[Luis]

David, 

Would help you to connect remotely to our systems to evaluate directly this issue?

Comment 76

[Jan de Mooij [:jandem]]

(In reply to Luis from comment #75)
> Would help you to connect remotely to our systems to evaluate directly this
> issue?

Victor, Luis: it'd be great if you could help David reproduce this crash so they can confirm their Java fix works :)

Comment 77

[Victor]

I have just sent an email to David with the instructions to reproduce the issue.

David, did you receive the email? If you need something more, please tell me.

Thanks.

Comment 78

[David DeHaven]

(In reply to Victor from comment #77)
> David, did you receive the email? If you need something more, please tell me.

I did, thank you.

Comment 79

[David DeHaven]

(In reply to Luis from comment #75)
> Would help you to connect remotely to our systems to evaluate directly this
> issue?

Remote access through our WAN is usually met with frustration and anger. I'll try Victor's link first and let you know.

Comment 80

[Adit Shetty]

An easy way to reproduce the crash is as below with FF ESR 38.0.4 on Windows 

Below is a link of the Applet JSObject example from oracle docs
Run the below url in FF ESR version, once the applet is launched , refresh the page and notice the browser crashing
http://docs.oracle.com/javase/tutorial/deployment/applet/examples/dist/applet_InvokingJavaScriptFromApplet/AppletPage.html

Comment 81

[Donald Smith]

As per my comment on Bug 1221448 Oracle is aware of the issue specific to 38.4, and deciding the best way to make that available.  The timeframe is likely 'days', not 'week(s)'.

Comment 82

[Donald Smith]

/s/that/a fix to the JRE/

Comment 83

[Donald Smith]

FWIW, the JRE fix for this should now be available, once we have more feedback that the build we're making available does indeed fully address the issue, we'll push more broadly. Details below:

You can now get version 1.8.0_66-b18, of the JRE or JDK, here:
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Note that you want b18, and you want 8u66, *not* 8u55.  Also this is Windows only.  Build 1.8.0_66-b18 contains the fix for this issue.  Be sure to check double check after install with "java -version", or after accepting the license you'll notice the url path for the download includes -b18 instead of -b17.  It is possible you may hit a cache with -b17 still out there.

We'd greatly appreciate your help testing this out.  Once we've had more public validation of this fix, we'll push more aggressively, likely very early next week.  If you experience any issues, please report at java.com/report

FWIW, release notes are here:
http://www.oracle.com/technetwork/java/javase/8u66-relnotes-2692847.html

Comment 84

[Donald Smith]

Hey, how could I write something like that and not have at least one mistake.  When I say you "want 8u66, *not* 8u55", I really meant you do not want "8u65"...

To be more precise, this fix is in 8u66-b18 Windows only on OTN for now...

Comment 85

[per-olof.holmgren]

I have tested our web application with java 8u66-b18 and now it's working fine.
Thank You!

Comment 86

[Luis]

Our first test has been positive too with 8u66-b18, 
thanks !!

Comment 87

[Victor]

Hi Donald, do you know when will be available the fix for all users?

Thanks.

Comment 88

[Donald Smith]

Oracle development has a fix that is under code review and test currently.  Assuming the fix passes regression testing and security reviews we will slot this into the earliest release possible.  We're concerned with compounding issues here, so want to do more extensive testing.  In the meantime we would recommend the FF ESR or other versions where this is known to work.

Comment 89

[Paul Silaghi, QA [:pauly]]

(In reply to Adit Shetty from comment #80)
> An easy way to reproduce the crash is as below with FF ESR 38.0.4 on Windows 
> 
> Below is a link of the Applet JSObject example from oracle docs
> Run the below url in FF ESR version, once the applet is launched , refresh
> the page and notice the browser crashing
> http://docs.oracle.com/javase/tutorial/deployment/applet/examples/dist/
> applet_InvokingJavaScriptFromApplet/AppletPage.html
I couldn't reproduce the initial issue on FF 35.0.1, 41. 38.0.1 ESR, 38.4.0 ESR.
Moreover, no crashes occur on FF 2015-12-05-00-15-01-mozilla-esr38, 43b9 Win 7.
Marking this bug as verified based on my testing and comments 85, 86.