SIGSEGV in IcedTea

[Harrison Neal]

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.