Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#67714 - java8-openjdk source package is incorrect

Attached to Project: Arch Linux
Opened by Riccardo Paolo Bestetti (vmsh0) - Tuesday, 25 August 2020, 10:07 GMT
Last edited by Levente Polyak (anthraxx) - Wednesday, 26 August 2020, 08:38 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To freswa (frederik)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

The source package for java8-openjdk (openjdk8-src) appears to contain the incorrect source code for the respective jre (jre8-openjdk). I noticed this while examining a stack trace.

For example, I have the following stack trace:

java.lang.NullPointerException
at javax.swing.plaf.basic.BasicListUI.convertLocationToRow(BasicListUI.java:1111)
at javax.swing.plaf.basic.BasicListUI.convertLocationToModel(BasicListUI.java:1174)
at javax.swing.plaf.basic.BasicListUI.locationToIndex(BasicListUI.java:930)
at javax.swing.JList.locationToIndex(JList.java:1596)
at javax.swing.JList.dropLocationForPoint(JList.java:1270)
at javax.swing.JList.dropLocationForPoint(JList.java:282)
at javax.swing.TransferHandler$TransferSupport.setDNDVariables(TransferHandler.java:301)
at javax.swing.TransferHandler$TransferSupport.access$500(TransferHandler.java:213)
at javax.swing.TransferHandler$DropHandler.handleDrag(TransferHandler.java:1466)
[...]

And as an example, you can open the javax/swing/TransferHandle file and note that none of the three methods in the stack trace (TransferHandler$DropHandler.handleDrag, TransferHandler$TransferSupport.access$500, TransferHandler$TransferSupport.setDNDVariables) are where they are supposed to be.

This is not simply a line number mismatch: for example, the TransferHandler$TransferSupport.access$500 method doesn't even appear in the source code.


Additional info:
* package version(s): latest (8.u262-1)

Steps to reproduce:
You can use the attached Java class to reproduce my stack trace. Compile and run it, and the try to drag one of the colored rectangles on the GUI around.
   scratch_2.java (7.7 KiB)
This task depends upon

Closed by  Levente Polyak (anthraxx)
Wednesday, 26 August 2020, 08:38 GMT
Reason for closing:  Not a bug
Comment by freswa (frederik) - Tuesday, 25 August 2020, 10:20 GMT
What ist the output of "archlinux-java status"?
Comment by Levente Polyak (anthraxx) - Tuesday, 25 August 2020, 10:20 GMT
you seem to be using a different JRE, look at the PKGBUILD it cannot magically be something totally different.
Comment by Riccardo Paolo Bestetti (vmsh0) - Tuesday, 25 August 2020, 10:59 GMT
I understand your skepticism, however look at the exact steps I did just now once again to verify:

# archlinux-java set java-8-openjdk

$ javac -version
javac 1.8.0_262

$ java -version
openjdk version "1.8.0_262"
OpenJDK Runtime Environment (build 1.8.0_262-b10)
OpenJDK 64-Bit Server VM (build 25.262-b10, mixed mode)

(I removed the "package" line from the scratch_2.java file for convenience)

$ javac scratch_2.java
$ java scratch_2

(interacted with the software as described, stack trace was printed)

Excerpt from stack trace:
at javax.swing.TransferHandler$TransferSupport.setDNDVariables(TransferHandler.java:301)
at javax.swing.TransferHandler$TransferSupport.access$500(TransferHandler.java:213)
at javax.swing.TransferHandler$DropHandler.handleDrag(TransferHandler.java:1466)
at javax.swing.TransferHandler$DropHandler.dragOver(TransferHandler.java:1496)

$ cp /lib/jvm/java-8-openjdk/src.zip .
$ unzip src.zip
$ vim javax/swing/TransferHandler.java

301gg => line 301 does _not_ contain TransferHandler$TransferSupport.setDNDVariables
213gg => line 213 this one looks ok, TransferSupport.access$500 should indeed point to the inner class
1466gg => line 1466 does _not_ contain TransferHandler$DropHandler.handleDrag
1496gg => line 1496 does _not_ contain TransferHandler$DropHandler.dragOver

You can see the line numbers are not very far away from what they should be (e.g. 1496 looks like it should be 1495, 1466 should probably be 1456). Java 8 was patched but the source code was taken from a different version?

@Levente Polyak: I took a quick look at the PKGBUILD. Yes, what is happening seems impossible. Could you try to reproduce on your system?
Comment by kkl2401 (kkl2401) - Wednesday, 26 August 2020, 05:40 GMT
Are you sure you're reading the stack trace correctly? The line "at javax.swing.TransferHandler$TransferSupport.setDNDVariables(TransferHandler.java:301)" does NOT mean that the method setDNDVariables starts there (or is invoked there). It means that the exception occurred while inside the method, specifically on line 301. This line IS inside the method setDNDVariables. To me it seems everything is as it's supposed to be.
Comment by Riccardo Paolo Bestetti (vmsh0) - Wednesday, 26 August 2020, 06:46 GMT
@kkl2401: This is very interesting: I've been reading Java stack traces for _many_ years now, and made good use of them to debug software for countless hours. I had never noticed that. But of course that's entirely correct, as well as the only way which really makes sense.

This is a bit embarassing. I guess the report can be closed :)

Loading...