303656 - jint is not wide enough on FreeBSD/amd64, possibly others

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Java: Live Connect, defect)

Description

[Mikhail T.]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.4; FreeBSD; X11; amd64) KHTML/3.4.1 (like Gecko)
Build Identifier: 

Live Connect use get_java_wrapper and unwrap_java_wrapper to store pointers as 
integers in the JVM. The former takes and the latter return "jint" as the 
pointer. jint, usually, is merely an int. 
 
On FreeBSD/amd64 and, doubtless, on some other systems (Linux/amd64?) 
sizeof(void) is 8, while sizeof(int) is 4, which means that some objects (whose 
addresses happened to be above 4Gb mark) may get lost leading to random 
crashes. 
 
The fix will have to come from both side -- LiveConnect and Java. The 
get_java_wrapper() pointer (in jsjava.h) seems to be resolved to 
GetJavaWrapper() in the Java-plugin. The GetJavaWrapper() will need to be 
changed first. 
 
Either they both need to accept jlong (which will be wasteful on 32-bit 
systems, because jlong is, normally, "long long") or, best of all, they will 
both accept uintptr_t -- an integer type designed to be the same width as a 
pointer. 
 
Not sure, how best to go about this, but the problem exists... 

Reproducible: Always

Comment 1

[zug_treno]

Related to/duplicate of bug 239562?

Comment 2

[Mikhail T.]

Certainly related. But whatever the fixes that came out of bug 239562, the  
problem persists -- the get_java_wrapper pointer to function in jsjava.h still  
takes jint and the unwrap_java_wrapper still returns a jint instead of a  
pointer or a pointer-width integer (such as intptr_t).  
  
The types like intptr_t are mentioned in the old bug's comments and discounted  
as "C99 only". Well, that -- C99 -- is a 6 year-old standard now (5 year-old,  
when the old bug was discussed) and all modern OS-es define these types in  
their headers (checked on AIX, Solaris, Linux, BSD).  
  
The bigger problem is that GetJavaWrapper and friends in the Java distributions  
will need to change.  
  
Either JDKs will have to change (preferable) or a (hash-) table internal to  
LiveConnect will have to be used to map between the 32-bit integers and the  
64-bit pointers.  
 
On BSD the JDKs are built from source (using the ports) and port-maintainers  
can add patches for GetJavaWrapper et al. But the (l)users of other OSes will  
need some other methods -- such as the table I mention above. 
 
Just be sure not to pessimize the 32-bit platforms in the process :-) 

Comment 3

[Mikhail T.]

I would just like to remind all interested parties, that this problem remains a _show-stopper_ for plugging Java into 64-bit browsers...

Comment 4

[Alfred Peng]

The bug in the browser side seems to have been fixed in jsjava.h by replacing jint  with lcjsobject.

Comment 5

[Mikhail T.]

(In reply to comment #4)
> The bug in the browser side seems to have been fixed in jsjava.h by replacing
> jint  with lcjsobject.

That's good! Ss the Java-side getting fixed soon? If done right (so that the value remains 32-bit wide on 32-bit platforms), the existing ABI need not break, so it can be done even in the old 1.4.2_x branch...

Comment 6

[Alfred Peng]

Kenneth, any plan to support the 64bit on the java side of the plugins?

Comment 7

[Kenneth Russell]

I can't comment on Sun's plans for a 64-bit version of the Java Plug-In at this time. We are currently working on other restructuring and rearchitecting in the Plug-In which has higher priority.

Comment 8

[Benjamin Smedberg]

Firefox code moved from custom Liveconnect code to the NPAPI/NPRuntime bridge a while back. Mass-closing the bugs in the liveconnect component which are likely invalid. If you believe that this bug is still relevant to modern versions of Firefox, please reopen it and move it the "Core" product, component "Plug-Ins".