The JVM crashed when trying to use https resource that uses not valid SSL certificate

NEW
Unassigned

Status

Core Graveyard
Java to XPCOM Bridge
--
major
10 years ago
3 years ago

People

(Reporter: Victor Gubin, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: xulrunner 1.9.0.2

This happens because the thread which verifies the certificate is not attached to JVM

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
–°rash
(Reporter)

Comment 1

10 years ago
Created attachment 329852 [details] [diff] [review]
Attache current thread patch

This patch fix this problem. Only the one problem, no name of thread which I attache to JVM . 
But now in this code, I caught only in the case of SSL
(Reporter)

Updated

10 years ago
Severity: normal → blocker
Severity: blocker → major
Attachment #329852 - Flags: review?(jhpedemonte)
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Updated

10 years ago
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Attachment #329852 - Flags: review?(jhpedemonte) → review?(jst)
(Reporter)

Updated

9 years ago
Component: Java to XPCOM Bridge → XULRunner
Product: Core → Toolkit
Component: XULRunner → Java to XPCOM Bridge
Product: Toolkit → Core
Comment on attachment 329852 [details] [diff] [review]
Attache current thread patch

Javier, I'm going to let you decide whether this is the right fix here or not.
Attachment #329852 - Flags: review?(jst) → review?(jhpedemonte)
(Reporter)

Comment 3

8 years ago
Sorry for very badly description of .

I'll try to make more detailed description: 

There is Mozilla which is embedded into Java using JavaXPCOM bridge. 
There is a nsIWebBrowser instance, which navigates into some https:// resource with invalid or self-signed SSL certificate. With current implementation it's brings to JVM crash. 

As you can know, JNI is not thread safe. JNI context is valid only for one thread, and each thread which is uses JNI must be attached into JVM first. Otherwise JVM will crashes. It is described at: http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/invocation.html#wp1060

So the attached patch makes modification in JavaXpcom  JNI part. This modification connect to JVM each thread that makes attempt to use JavaXPCOM. If connection is impossible for some reason, the Java exception is throws to JVM and there aren't any crashes occurs.

Updated

4 years ago
Assignee: jhpedemonte → nobody
Attachment #329852 - Flags: review?(jhpedemonte)
(Assignee)

Updated

3 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.