Bug ID: JDK-6557880 JVM Crash in the Ductus code near writeApha8

Type: Bug
Component: client-libs
Sub-Component: 2d
Affected Version: 5.0,6,6u5

Priority: P3
Status: Closed
Resolution: Duplicate
OS: linux,windows_xp
CPU: x86

Submitted: 2007-05-15
Updated: 2011-02-16
Resolved: 2007-07-05

FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode)

or

java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Linux io 2.6.11.4-21.11-smp #1 SMP Thu Feb 2 20:54:26 UTC 2006 i686 i686 i386 GNU/Linux

Linux dio 2.6.9-42.0.3.ELsmp #1 SMP Mon Sep 25 17:28:02 EDT 2006 i686
i686 i386 GNU/Linux

Linux gorm 2.6.19.1-mactel.mactel-061225 #1 SMP PREEMPT Mon Dec 25 19:17:52 CET
2006 i686 GNU/Linux

Linux novo 2.4.21-37.0.1.ELsmp #1 SMP Wed Jan 11 18:44:17 EST 2006 i686 i686 i386 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
JVM 1.6 is very unstable. In an application based on the netbeans rich client platform we observe a lot of JVM crashes (see attached hs_err_xxx file, if you need more please contact me - we have dozens of them). We checked on different computers with different OS versions (see above). Since we use 1.6 features we unfortunately cannot go back to 1.5.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
No simple testcase available yet. Crashes happen during program start, while the program is running and during program shutdown.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
JVM should not crash.
ACTUAL -
JVM crashes

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Attached seperatly

REPRODUCIBILITY :
This bug can be reproduced often.

EVALUATION According to stack trace and evaluation this failure is the same as described in 6464341. Moreover, the problem is not reproducible after applying the fix of 6464341. So, I'm closing it as duplicate.
05-07-2007
EVALUATION I attached the valgrind output from the test case. This was produced from running the test case under valgrind like this: valgrind --suppressions=suppress.txt --error-limit=no --log-file=pv6 --undef-value-errors=no --gen-suppressions=all --smc-check=all --trace-children=yes --tool=memcheck ./pv6/bin/pv6 --jdkhome /java/re/jdk/1.6.0/latest/binaries/linux-i586 -J-DautoExit=true -J-Dorg.netbeans.do_not_warn_default_package=true -J-Dhome=$HOME The supression file, suppress.txt, should contain this: { dummy Memcheck:Addr4 obj:* } { thread1 Memcheck:Param write(buf) fun:write fun:_ZN2os13create_threadEP6ThreadNS_10ThreadTypeEj } { thread2 Memcheck:Param write(buf) fun:write fun:ContinueInNewThread fun:main } Also the test case required a little hacking on the sources since it wasn't happy with our DNS configuration. I had to hack the bytecodes slightly and I've attached the modified version as pv6.modded.tar.bz2.
08-06-2007
EVALUATION So I've tracked this further and here's the situation. In this piece of code: if (diam < oneU) { /* special case: very short cubic / if (x01 != 0 \|\| y01 != 0) { p->xyjBuffer[i++] = (i8)x01; p->xyjBuffer[i++] = (i8)y01; } if (x12 != 0 \|\| y12 != 0) { p->xyjBuffer[i++] = (i8)x12; p->xyjBuffer[i++] = (i8)y12; } if (x23 != 0 \|\| y23 != 0) { p->xyjBuffer[i++] = (i8)x23; p->xyjBuffer[i++] = (i8)y23; } we enter with "steps" == 1. The code earlier saw that with that number of steps we would not overrun the xyjBuffer if we used the while loop. The short cut case in this instance does overrun because it doesn't check to see where "i" is. Now it may be that only one of the if statements should have triggered and so there is a more complex problem here. I can't say since I don't know the code at all. However I did the experiment of modifying the code so that the initial guard looks like: if (diam < oneU && (i + 6) < xyjL ) { / special case: very short cubic */ so that in this instance it avoid the shortcut and uses the loop and the testcase no longer fails. I notice that if this is a legitimate fix then the code in appendArc2 has a similar situation. I also got this piece of mail from Tom R. after telling him about this problem: I got curious about valgrind so I gave it a try on the test case and after fiddling a bit with options to make it shut up about a bunch of things I got .../pv6.27124.1 which complains about both appendArc3 and processSubBufferInTile as reading and writing to space they shouldn't be. I guess you should have tried valgrind earlier... For some reason I'd had the impression that valgrind was kind of useless based on past experience but it actually looks pretty good, as long as you run on linux since it doesn't seem to work any where else. So it looks like this testcase may have more issues than the appendArc3 problem.
08-06-2007
EVALUATION I have discovered that is is caused by ductus code overwriting a piece of malloc'd storage. The native call chain at the point of failure is: #10 0x4b480976 in appendArc3 () from /eng/steveg/t1/jre/lib/i386/libdcpr.so #11 0x4b483f51 in FastOutputPC_appendCubic () from /eng/steveg/t1/jre/lib/i386/libdcpr.so #12 0x4b47bff8 in appendCubic_describeTo () from /eng/steveg/t1/jre/lib/i386/libdcpr.so #13 0x4b47c383 in sendTo () from /eng/steveg/t1/jre/lib/i386/libdcpr.so #14 0x4b485023 in writeAlpha8 () from /eng/steveg/t1/jre/lib/i386/libdcpr.so #15 0x4b47d74c in Java_sun_dc_pr_PathFiller_writeAlpha8 () from /eng/steveg/t1/jre/lib/i386/libdcpr.so At portion of the java call stack is: 1 - frame( sp=0x4b026c80, fp=0x4b026cc0, pc=0x402a253c) sun.dc.pr.PathFiller.writeAlpha8(Native Method) 2 - frame( sp=0x4b026cc8, fp=0x4b026d04, pc=0x40298cb1) sun.dc.pr.PathFiller.writeAlpha(PathFiller.java:402) 3 - frame( sp=0x4b026d0c, fp=0x4b026d40, pc=0x40298cb1) sun.dc.pr.Rasterizer.writeAlpha(Rasterizer.java:712) 4 - frame( sp=0x4b026d48, fp=0x4b026d84, pc=0x40298cb1) sun.java2d.pipe.DuctusRenderer.getAlpha(DuctusRenderer.java:105) 5 - frame( sp=0x4b026d8c, fp=0x4b026dc4, pc=0x40298cb1) sun.java2d.pipe.DuctusShapeRenderer.renderPath(DuctusShapeRenderer.java:114) 6 - frame( sp=0x4b026dcc, fp=0x4b026e3c, pc=0x40298cb1) sun.java2d.pipe.DuctusShapeRenderer.draw(DuctusShapeRenderer.java:63) 7 - frame( sp=0x4b026e44, fp=0x4b026e74, pc=0x4029918d) sun.java2d.pipe.ValidatePipe.draw(ValidatePipe.java:154) 8 - frame( sp=0x4b026e7c, fp=0x4b026ea8, pc=0x4029918d) sun.java2d.SunGraphics2D.draw(SunGraphics2D.java:2389) 9 - frame( sp=0x4b026eb0, fp=0x4b026ee4, pc=0x40298cb1) org.apache.batik.gvt.StrokeShapePainter.paint 10 - frame( sp=0x4b026eec, fp=0x4b026f14, pc=0x4029918d) org.apache.batik.gvt.CompositeShapePainter.paint 11 - frame( sp=0x4b026f1c, fp=0x4b026f48, pc=0x4029918d) org.apache.batik.gvt.ShapeNode.primitivePaint 12 - frame( sp=0x4b026f50, fp=0x4b026f78, pc=0x40298cb1) org.apache.batik.gvt.AbstractGraphicsNode.paint 13 - frame( sp=0x4b026f80, fp=0x4b026fd8, pc=0x40298cb1) org.apache.batik.gvt.ShapeNode.paint 14 - frame( sp=0x4b026fe0, fp=0x4b027008, pc=0x4029918d) org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint 15 - frame( sp=0x4b027010, fp=0x4b027040, pc=0x40298cb1) org.apache.batik.gvt.AbstractGraphicsNode.paint 16 - frame( sp=0x4b027048, fp=0x4b0270a0, pc=0x4029918d) org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint 17 - frame( sp=0x4b0270a8, fp=0x4b0270d8, pc=0x40298cb1) org.apache.batik.gvt.CanvasGraphicsNode.primitivePaint 18 - frame( sp=0x4b0270e0, fp=0x4b027108, pc=0x40298cb1) org.apache.batik.gvt.AbstractGraphicsNode.paint 19 - frame( sp=0x4b027110, fp=0x4b027168, pc=0x4029918d) org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint 20 - frame( sp=0x4b027170, fp=0x4b0271a0, pc=0x4029918d) org.apache.batik.gvt.filter.GraphicsNodeRed8Bit.genRect 21 - frame( sp=0x4b0271a8, fp=0x4b0271d8, pc=0x40298cb1) org.apache.batik.gvt.filter.GraphicsNodeRed8Bit.copyData 22 - frame( sp=0x4b0271e0, fp=0x4b027208, pc=0x402992f3) org.apache.batik.ext.awt.image.rendered.TileCacheRed.genRect 23 - frame( sp=0x4b027210, fp=0x4b02723c, pc=0x40298cb1) org.apache.batik.ext.awt.image.rendered.AbstractTiledRed.drawBlockInPlace 24 - frame( sp=0x4b027244, fp=0x4b027288, pc=0x40298cb1) org.apache.batik.ext.awt.image.rendered.AbstractTiledRed.drawBlock 25 - frame( sp=0x4b027290, fp=0x4b0272c0, pc=0x40298cb1) org.apache.batik.ext.awt.image.rendered.AbstractTiledRed.copyToRasterByBlocks 26 - frame( sp=0x4b0272c8, fp=0x4b02734c, pc=0x40298cb1) org.apache.batik.ext.awt.image.rendered.AbstractTiledRed.copyData 27 - frame( sp=0x4b027354, fp=0x4b02737c, pc=0x402992f3) org.apache.batik.ext.awt.image.rendered.TranslateRed.copyData 28 - frame( sp=0x4b027384, fp=0x4b0273b0, pc=0x402992f3) org.apache.batik.ext.awt.image.rendered.PadRed.copyData 29 - frame( sp=0x4b0273b8, fp=0x4b0273fc, pc=0x402992f3) org.apache.batik.gvt.renderer.StaticRenderer.repaint 30 - frame( sp=0x4b027404, fp=0x4b027448, pc=0x40298cb1) org.apache.batik.gvt.renderer.StaticRenderer.repaint 31 - frame( sp=0x4b027450, fp=0x4b02747c, pc=0x4029918d) org.apache.batik.transcoder.image.ImageTranscoder.transcode 32 - frame( sp=0x4b027484, fp=0x4b0274d8, pc=0x40298cb1) org.apache.batik.transcoder.XMLAbstractTranscoder.transcode 33 - frame( sp=0x4b0274e0, fp=0x4b027534, pc=0x40298cb1) org.apache.batik.transcoder.SVGAbstractTranscoder.transcode 34 - frame( sp=0x4b02753c, fp=0x4b027570, pc=0x40298cb1) de.bruker.mri.infra.api.icons.IconFactory.createIcon(IconFactory.java:356) 35 - frame( sp=0x4b027578, fp=0x4b0275b8, pc=0x40298e17) de.bruker.mri.infra.api.icons.IconFactory.getIcon(IconFactory.java:179) 36 - frame( sp=0x4b0275c0, fp=0x4b027618, pc=0x40298e17) de.bruker.mri.infra.api.program.ProgStarterFactory.getStartableJMacroMangerClient(ProgStarterFactory.java:948) 37 - frame( sp=0x4b027620, fp=0x4b027648, pc=0x40298e17) de.bruker.mri.infra.program.StartJMacroManagerClientAction.<init>(StartJMacroManagerClientAction.java:19) C frame (sp=0x4b027650, fp=0x4b027668, pc=0x402962a7) ... I modified code in dcLLFillerS.c to verify that it was not overwriting an xyjBuffer (after previous discovering this item type was the culprit). The catch_and_die() call was used to mark all of the points where an xyjBuffer was written. Here is the place where it dies: if (x23 != 0 \|\| y23 != 0) { catch_and_die(i + 1, "11"); p->xyjBuffer[i++] = (i8)x23; p->xyjBuffer[i++] = (i8)y23; }
08-06-2007

Duplicate :	JDK-6464341 - SwingSet2 demo crashes with ACCESS_VIOLATION in [ntdll.dll+0x1c97b] on windows-amd64
Relates :	JDK-6501898 - SIGSEGV near libc.so.6 after calling Java_sun_dc_pr_PathFiller_writeAlpha8