Closed Bug 200016 Opened 21 years ago Closed 20 years ago
Crash accessing Java package from JS
In jsj_JSObject.c /* JNI returns a NULL handle for a Java 'null' */ if (!handle) return NULL; return handle->js_obj; get a invalid handle (handle != 0) from JPI side, just like #183092
Status: NEW → ASSIGNED
I'm sorry, no -- if an exception was thrown, the return value should be null. Anything else is a bug in the JNI, JPI, JVM interface glue, or whatever it's called these days. /be
I remember that another bug is also happen on the reason. (crash because of handle->js_obj;) Yes, I will push them (Sun 's JPI team member) to fix this on JPI side. It is not elegant to check exception anywhere and reduce the performance. I inserted checking exception code in this case to test, can't get exception, I will check inside JPI. Brendan, Are you on IRC mozilla channel? should we talk about this kind of bugs?
I can't get exception from JPI and the handle is also invalid, Xiaobin: Please check this. Thanks!
OS: Windows 2000 → All
filed a P1 bug in Sun's bugtraq #4850496
this is a dupe of bug 199694 ?
*** Bug 199694 has been marked as a duplicate of this bug. ***
that was backwards this is the dupe. bug 199694 is the original.
IMHO this bug should block 1.5 since people at bugtraq start in believing that we are not intressted in fixing criticial bugs.
Joshua, any hope of a fix for 1.5final? We need it this week, if possible. /be
This bug can't be fixed on mozilla side. It must be fixed on Java Plugin side. I will push JPI member to fix it.
The problem is due to invalid cast between jint and JSObjectHandle. jsj_JSObject.c Ln 313: handle = (JSObjectHandle*)JSJCallbacks->unwrap.... It calls to lcglue.cpp Ln 400. That function returned a jint. JPI side returns the right value "1". The fix should be either JPI side or browser side correctly malloc JSObjectHandle and assign the returned value from callback function to handle- >js_obj.
A typo in my last comment, The fix should be either OJI side or liveconnect side to correctly allocate JSObjectHandle and assign the right value to the struct.
Xiaobin, I am not an expert on this code, and I agree the cast is ugly, but that doesn't seem to be the cause of the crash. Is it not the case that every handle returned by unwrap_java_wrapper must have previously been passed into the OJI implementation via a get_java_wrapper call? The only call to get_java_wrapper that I can see is in jsj_WrapJSObject, and jsj_WrapJSObject does indeed allocate a JSObjectHandle for the OJI to associate with a Java object. Is the problem that some other Java object than one created as a wrapper for a JS object is being "unwrapped"? /be
Too late for 1.4.1
Flags: blocking1.4.1? → blocking1.4.1-
Probably too late for 1.5 but let us know if you get a fix into 1.6 soon and we'll consider it for 1.5.
Flags: blocking1.5? → blocking1.5-
I looked into the code and I don't think there is an easy fix for this bug. If we can fix it, we need to understand why there is a need to use JSObjectHandle and find an alternative way to do it. For most cases, JSObject is wrapped inside JSObjectHandle, however, for the testcase mentioned, it directly invokes the constructor of s.p.j.n.JSObject without first converting the second param to JSObjectHandle. That is why the crashes from.
Did this regress during 1.5? Did the testcase work in 1.4? /be
This bug is duplicate of #200016
*** Bug 221982 has been marked as a duplicate of this bug. ***
sorry, #221982 is mark as dup of this bug.
Assignee: joshua.xia → kyle.yuan
Status: ASSIGNED → NEW
Brendan, no, the test case does not work in 1.4 too. I'm looking into this right now, is there any chance to get it into 1.6?
Status: NEW → ASSIGNED
We'd have to see a patch and evaluate its risk before granting actual approval for 1.6, but this is definitely something that we'd like to have fixed. Some of the comments imply that the fix isn't going to be easy, though, so no guarantees. If it looks like something that needs quite a bit of real-world testing it may get bumped to 1.7a since it won't even have the 1.6beta shakedown period.
please nominate this bug as soon as a patch appears to help in getting it evaluated for the next release
Comment on attachment 136917 [details] [diff] [review] prevent JSObject and its derived classes from being created in js Xiaobin, I don't understand the 2nd change you said in comment 36. Is that necessary for this bug?
Attachment #136917 - Attachment description: prevent JSObject and its derived classes from creating in js → prevent JSObject and its derived classes from being created in js
Frankly to say, I don't like this patch which takes such a big effort to support an useless scenario. But in the interest of fixing this asap, I'd like to listen to anybody else's option on those two patches.
I was just wondering if the bug I submitted 9 months ago is fixed already, but unfortunately not, next time i will check is the 31st of March, wenn this bug is getting one year old .....
lets try to make some progress for 1.7beta
Please see the comments in my patch for detail. I discussed this issue with Xiaobin via emails. We all agree to use this workaround fix in mozilla side first, then do a better job in the next jre release.
Comment on attachment 141712 [details] [diff] [review] workaround fix - block accessing to all classes in sun.plugin package sorry for the indent problem. I should use space instead of tab.
Comment on attachment 141712 [details] [diff] [review] workaround fix - block accessing to all classes in sun.plugin package Kyle, please remove the comment about invoking java.lang.SecurityManager.... comment. That comment really needs to be investigated further.
Attachment #141712 - Flags: review?(Xiaobin.Lu) → review+
Comment on attachment 141712 [details] [diff] [review] workaround fix - block accessing to all classes in sun.plugin package Okay, I'll take those words back until Xiaobin and I find out the ultimate solution.
Attachment #141712 - Flags: superreview?(brendan)
Comment on attachment 141712 [details] [diff] [review] workaround fix - block accessing to all classes in sun.plugin package I see tabs in the + lines -- please use spaces, and indent to the right column. firstname.lastname@example.org with that nit picked. /be
Attachment #141712 - Flags: superreview?(brendan) → superreview+
checked in with comments/indent revised.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.