openjdk team mailing list archive

[Harrison Neal <613263@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

We have a (pure) Java program that was admittedly written somewhat
sloppily (as a research project), except we started getting odd
exceptions that we didn't know what to make of them. For example:

Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 1
	at javax.swing.plaf.basic.BasicTabbedPaneUI.paintTabArea(BasicTabbedPaneUI.java:834)
	at javax.swing.plaf.basic.BasicTabbedPaneUI.paint(BasicTabbedPaneUI.java:797)
	at javax.swing.plaf.metal.MetalTabbedPaneUI.paint(MetalTabbedPaneUI.java:843)
	at javax.swing.plaf.metal.MetalTabbedPaneUI.update(MetalTabbedPaneUI.java:724)
	at javax.swing.JComponent.paintComponent(JComponent.java:765)
	at javax.swing.JComponent.paint(JComponent.java:1029)
	at javax.swing.JComponent.paintChildren(JComponent.java:866)
	at javax.swing.JComponent.paint(JComponent.java:1038)
	at javax.swing.JComponent.paintChildren(JComponent.java:866)
	at javax.swing.JComponent.paint(JComponent.java:1038)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5138)
	at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:302)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1145)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5086)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4896)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:740)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:696)
	at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:676)
	at javax.swing.RepaintManager.access$700(RepaintManager.java:57)
	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1550)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:226)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:602)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)

We don't do anything particularly special in Swing that we thought
should cause this (this is happening in the AWT thread, which we have no
control over; maybe two threads of ours modified the same object
simultaneously and caused an inconsistency that eventually resulted in
this? I'm not sure.). But, being a "pure" Java program (and, by that, I
mean we don't use JNI or anything to add native code to the JVM itself),
I didn't think it was possible to get an outright crash of the JVM:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f7b35a846b8, pid=14639, tid=140165863499536
... rest of file attached for the sake of readability.

These began happening on multiple machines, and the outright crash of
the entire JVM makes me wonder what exactly is going wrong. I'm
attaching all the files related to the project; it's an Eclipse project.

Things you should know:
-Java is made to invoke tshark (a network traffic capturer and analyzer) as a process (outside the JVM), so if you plan on running this you'll need tshark installed, and since it wants to read the network interfaces on the system directly, this stuff needs to be run as root. Also, tshark will try to dump the contents of the network traffic to a file, and, being cautious, it'll only work if the folder it's writing to is owned by the user it's running as (root). You can either disable that (remove "-w", "output/tsharkData.pcap", "-S" from PacketReader3.java, line 25) or ensure this entire directory structure is root-owned, as that seems the only way to appease tshark. We've found our lives were easiest working out of either /tmp or /root.

-There are some executables within the project that Java is made to
invoke in addition to tshark. I would provide the source code for the
few actual C executables included in this project, but for some
unearthly reason my higher-ups would rather have those executables (what
amounts to 10-20 lines of code each) remain a black box to my team and
I, rather than making both their and our lives simpler by just having
the 10 lines of code be in Java and save us the 10 lines of code to
execute the process. But enough about my problems.

-For both the above notes, I wouldn't blame you for running this in a
virtual machine or on a machine of inconsequential nature if you were to
touch it at all; that's what I'd do, anyway.

-This code uses the jcommon and jfreechart libraries, and Eclipse needs
to be told where those are to run this properly.

-In a nutshell, what this tries to do is analyze SSH connections. Java
invokes tshark, tshark spits out information about the connections going
across the wire, Java takes that packet information, passes it onto one
of the executables that takes the differences in times between the
packets, then finally passes it onto a second executable that compares
the timings against those in profile.txt. If you want the "full" version
of what our higher ups are wanting to accomplish, I have a PDF attached
with a description of their work.

-I don't know if this is or isn't a bug with IcedTea. If it's just
horrible Java code that can cause the two exceptions/errors mentioned
above, which there are some parts that are admittedly sketchy, don't be
afraid to let me know and mark this as invalid. I'm submitting this just
in case there is something going awry in the JVM, which I believe to be
the case.

-Let me know if you have any questions.

** Affects: openjdk-6 (Ubuntu)
     Importance: Undecided
         Status: New

-- 
SIGSEGV in IcedTea
https://bugs.launchpad.net/bugs/613263
You received this bug notification because you are a member of OpenJDK,
which is subscribed to openjdk-6 in ubuntu.

Status in “openjdk-6” package in Ubuntu: New

Bug description:
We have a (pure) Java program that was admittedly written somewhat sloppily (as a research project), except we started getting odd exceptions that we didn't know what to make of them. For example:

Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 1
	at javax.swing.plaf.basic.BasicTabbedPaneUI.paintTabArea(BasicTabbedPaneUI.java:834)
	at javax.swing.plaf.basic.BasicTabbedPaneUI.paint(BasicTabbedPaneUI.java:797)
	at javax.swing.plaf.metal.MetalTabbedPaneUI.paint(MetalTabbedPaneUI.java:843)
	at javax.swing.plaf.metal.MetalTabbedPaneUI.update(MetalTabbedPaneUI.java:724)
	at javax.swing.JComponent.paintComponent(JComponent.java:765)
	at javax.swing.JComponent.paint(JComponent.java:1029)
	at javax.swing.JComponent.paintChildren(JComponent.java:866)
	at javax.swing.JComponent.paint(JComponent.java:1038)
	at javax.swing.JComponent.paintChildren(JComponent.java:866)
	at javax.swing.JComponent.paint(JComponent.java:1038)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5138)
	at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:302)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1145)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5086)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4896)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:740)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:696)
	at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:676)
	at javax.swing.RepaintManager.access$700(RepaintManager.java:57)
	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1550)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:226)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:602)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)

We don't do anything particularly special in Swing that we thought should cause this (this is happening in the AWT thread, which we have no control over; maybe two threads of ours modified the same object simultaneously and caused an inconsistency that eventually resulted in this? I'm not sure.). But, being a "pure" Java program (and, by that, I mean we don't use JNI or anything to add native code to the JVM itself), I didn't think it was possible to get an outright crash of the JVM:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f7b35a846b8, pid=14639, tid=140165863499536
... rest of file attached for the sake of readability.

These began happening on multiple machines, and the outright crash of the entire JVM makes me wonder what exactly is going wrong. I'm attaching all the files related to the project; it's an Eclipse project.

Things you should know:
-Java is made to invoke tshark (a network traffic capturer and analyzer) as a process (outside the JVM), so if you plan on running this you'll need tshark installed, and since it wants to read the network interfaces on the system directly, this stuff needs to be run as root. Also, tshark will try to dump the contents of the network traffic to a file, and, being cautious, it'll only work if the folder it's writing to is owned by the user it's running as (root). You can either disable that (remove "-w", "output/tsharkData.pcap", "-S" from PacketReader3.java, line 25) or ensure this entire directory structure is root-owned, as that seems the only way to appease tshark. We've found our lives were easiest working out of either /tmp or /root.

-There are some executables within the project that Java is made to invoke in addition to tshark. I would provide the source code for the few actual C executables included in this project, but for some unearthly reason my higher-ups would rather have those executables (what amounts to 10-20 lines of code each) remain a black box to my team and I, rather than making both their and our lives simpler by just having the 10 lines of code be in Java and save us the 10 lines of code to execute the process. But enough about my problems.

-For both the above notes, I wouldn't blame you for running this in a virtual machine or on a machine of inconsequential nature if you were to touch it at all; that's what I'd do, anyway.

-This code uses the jcommon and jfreechart libraries, and Eclipse needs to be told where those are to run this properly.

-In a nutshell, what this tries to do is analyze SSH connections. Java invokes tshark, tshark spits out information about the connections going across the wire, Java takes that packet information, passes it onto one of the executables that takes the differences in times between the packets, then finally passes it onto a second executable that compares the timings against those in profile.txt. If you want the "full" version of what our higher ups are wanting to accomplish, I have a PDF attached with a description of their work.

-I don't know if this is or isn't a bug with IcedTea. If it's just horrible Java code that can cause the two exceptions/errors mentioned above, which there are some parts that are admittedly sketchy, don't be afraid to let me know and mark this as invalid. I'm submitting this just in case there is something going awry in the JVM, which I believe to be the case.

-Let me know if you have any questions.