gmane.comp.java.openjdk.general

Re: Free Java Meeting at Fosdem - Brussels,Belgium on 7 and 8February 2009

Dalibor Topic — 2008-12-01T16:46:02

Barebone ad-hoc Wiki page for planning: http://wiki.debian.org/Java/DevJam/2009/Fosdem More updates on talk slots, etc. as we go, but please do sign up already if you know that you are coming - that'll make the Saturday/Sunday dinner event planning simpler. cheers, dalibor topic

Re: Free Java Meeting at Fosdem - Brussels, Belgium on 7 and 8February 2009

Mario Torre — 2008-12-01T15:21:19

Il giorno lun, 01/12/2008 alle 14.28 +0000, sales-k8ACu0K81pPy3iLdMGyKXPXRex20P6io< at >public.gmane.org ha scritto: Hi "sales" :) Yeah, me to! Cheers Mario

Re: Free Java Meeting at Fosdem - Brussels,Belgium on 7 and 8February 2009

Onno Kluyt — 2008-12-01T14:01:28

Excellent! Great work, Mark. Onno. On Dec 1, 2008, at 4:02 AM, Mark Wielaard wrote:

Re: Free Java Meeting at Fosdem - Brussels, Belgium on 7 and 8February 2009

Mark Wielaard — 2008-12-01T09:02:38

Hi all, On Mon, 2008-11-17 at 19:53 +0100, Mark Wielaard wrote: There were a lot of submissions this year, so it took the Fosdem organisation some time to go through them all. But I am happy to announce: The Free Java devroom request for FOSDEM 2009 (7+8 February) has been accepted. Details will follow (deadline for schedule, information we need for the schedule, room capacity, etc...). Welcome aboard, and thanks for your participation in FOSDEM 2009 :)

Re: Java binary, can't redirect stderr on VM crash

Mark Wielaard — 2008-11-28T12:11:38

Hi Igor, On Fri, 2008-11-28 at 14:35 +0300, Igor Nekrestyanov wrote: It is a fairly big file > 15MB. So if you could fetch it from the pointers below that would be preferable. If not I can upload my copy somewhere for you. It should be the "AR PL ShanHeiSun Uni" font from uming.tff that comes from the package cjkunifonts-uming-0.1.20060928-4.fc8.noarch ftp://download.fedora.redhat.com/pub/fedora/linux/releases/9/Everything/i386/os/Packages/cjkunifonts-uming-0.1.20060928-4.fc8.noarch.rpm They come from http://www.freedesktop.org/wiki/Software/CJKUnifonts (that is different from what I said in my previous email, I think I was confused by the output, but it could also be that it crashes more randomly than I thought.) Cheers, Mark

Re: Java binary, can't redirect stderr on VM crash

Igor Nekrestyanov — 2008-11-28T11:35:13

Mark, Could you send me copy of the font file? -igor Mark Wielaard wrote:

Re: Java binary, can't redirect stderr on VM crash

Patrick Wright — 2008-11-28T11:35:40

Hi Mark Thanks for testing that! I'll make sure to pass this info on to Igor in 2D-dev. Interesting to see that it's at least partly reproducible. Cheers! Patrick

Re: Java binary, can't redirect stderr on VM crash

Mark Wielaard — 2008-11-28T11:33:40

Hi Patrick, On Thu, 2008-11-27 at 23:26 +0100, Patrick Wright wrote: I can replicate the crash on a Fedora 9 i686 install, but not on a Fedora 10 x86_64 one, they have fairly different font setups though. gdb says: (gdb) bt #0 0x00110416 in ?? () #1 0x0082a660 in raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x0082c028 in abort () at abort.c:88 #3 0x0086764d in __libc_message (do_abort=, fmt=) at ../sysdeps/unix/sysv/linux/libc_fatal.c:170 #4 0x0086d874 in malloc_printerr (action=, str=, ptr=) at malloc.c:5949 #5 0x0086f8d6 in __libc_free (mem=) at malloc.c:3625 #6 0x05485943 in LEGlyphStorage::reset (this=0x93a822d0) at ../../../src/share/native/sun/font/layout/LEGlyphStorage.cpp:75 #7 0x0548b790 in LayoutEngine::reset (this=0x93140b98) at ../../../src/share/native/sun/font/layout/LayoutEngine.cpp:533 #8 0x0548dcfd in OpenTypeLayoutEngine::reset (this=0x93140b98) at ../../../src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp:127 #9 0x0548de00 in ~OpenTypeLayoutEngine (this=0x93140b98) at ../../../src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp:141 #10 0x0548b0bd in ~IndicOpenTypeLayoutEngine (this=0x93140b98) at ../../../src/share/native/sun/font/layout/IndicLayoutEngine.cpp:70 #11 0x0548d1d8 in Java_sun_font_SunLayoutEngine_nativeLayout (env=0x9c5ecf4, cls=0x164acc, font2d=0x164b1c, strike=0x164b18, matrix=0x164b14, gmask=0, baseIndex=0, text=0x164b08, start=0, limit=1, min=, max=1, script=33, lang=-1, typo_flags=0, pt=0x164ae8, gvdata=0x164ae4, upem=, layoutTables=) at ../../../src/share/native/sun/font/layout/SunLayoutEngine.cpp:217 This was with "AR PL UKai CN". Cheers, Mark

Re: Java binary, can't redirect stderr on VM crash

Patrick Wright — 2008-11-27T22:26:04

Hi Mark I hope I don't have to take it that far--right now I'm trying to find out if it affects all fonts, just some, what the exact pattern is. Too early to go rooting around. Oddly enough, only with Sun Java, meaning only with the Swing crash, and not consistently. I just tried two more times and it crashed twice, but only produced 1 hs log file. Odd! Thanks! Posted in the reply to Tim. It would be interesting to see if this is a distro (font?) specific issue or more general. I couldn't reproduce on OS X in a quick test and don't have other machines easily available. Cheers Patrick

Re: Java binary, can't redirect stderr on VM crash

Patrick Wright — 2008-11-27T22:21:15

Hi Chris hotspot.log was created, but did not include the library crash, which still went to the console. Thanks, though! Had never tried those flags before. Patrick

Re: Java binary, can't redirect stderr on VM crash

Patrick Wright — 2008-11-27T22:19:39

Hi Tim Thanks for the reply. Yes, first, see http://mail.openjdk.java.net/pipermail/2d-dev/2008-November/000561.html for the first report, with a Swing demo app. Igor asked me to try a simpler test without getting Swing involved. The image-based test I'll paste at the end of the mail. That would be great. It's painstaking work given the nature of the problem. OK Didn't work, but script did (altho output went to the console as well), so I can capture the VM dump, at least. Thanks for the help! Patrick Here's the render-glyph-to-image test. This fails on OpenJDK but not Sun Java, for me. A font list (from getAllFonts()) is attached. The other simple test, listed in the 2d-dev mailing list, fails on both, but is higher level (Swing). import java.awt.*; import java.awt.image.BufferedImage; import java.io.IOException; public class RenderFontTest { public static void main(String[] args) throws IOException { if (args.length == 0) { System.err.println("Need a font name"); System.exit(1); } // in case "" get pulled in with argument, strip em String fontName = args[0]; if (args[0].startsWith("\"")) { fontName = fontName.substring(1, fontName.length() - 1); } new RenderFontTest().run(fontName); } private void run(String fontName) throws IOException { GraphicsEnvironment lge = GraphicsEnvironment.getLocalGraphicsEnvironment(); GraphicsConfiguration gconf = lge.getDefaultScreenDevice().getDefaultConfiguration(); Font f = loadFont(fontName); if (f == null) { System.err.println("Could not load font " + fontName + ", not in JRE font list"); return; } System.out.println("Testing font: " + fontName + " created as " + f.toString()); BufferedImage bimg = gconf.createCompatibleImage(100, 100); Graphics g = bimg.getGraphics(); g.setFont(f); g.drawString(Character.toString('\u0DDD'), 0, 0); g.dispose(); System.out.println("OK"); } // match exactly on font face name; constructor new Font(ffn...) was not working? private Font loadFont(String fontName) { Font[] fonts = GraphicsEnvironment.getLocalGraphicsEnvironment().getAllFonts(); for (int i = 0; i < fonts.length; i++) { Font font = fonts[i]; if (font.getFontName().equals(fontName)) { return font; } } return null; } } "AR PL UMing CN" "AR PL UMing HK" "AR PL UMing TW" "AR PL UMing TW MBE" "AlArabiya" "AlBattar" "AlHor" "AlManzomah" "AlMateen Bold" "AlMohanad" "AlMothnna Bold" "AlYarmook" "Ani" "Arab" "Bitstream Charter" "Bitstream Charter Bold" "Bitstream Charter Bold Italic" "Bitstream Charter Italic" "Bitstream Vera Sans" "Bitstream Vera Sans Bold" "Bitstream Vera Sans Bold Oblique" "Bitstream Vera Sans Mono" "Bitstream Vera Sans Mono Bold" "Bitstream Vera Sans Mono Bold Oblique" "Bitstream Vera Sans Mono Oblique" "Bitstream Vera Sans Oblique" "Bitstream Vera Serif" "Bitstream Vera Serif Bold" "Century Schoolbook L Bold" "Century Schoolbook L Bold Italic" "Century Schoolbook L Italic" "Century Schoolbook L Roman" "Cortoba" "Courier 10 Pitch" "Courier 10 Pitch Bold" "Courier 10 Pitch Bold Italic" "Courier 10 Pitch Italic" "DejaVu Sans" "DejaVu Sans Bold" "DejaVu Sans Mono" "DejaVu Sans Mono Bold" "DejaVu Serif" "DejaVu Serif Bold" "Dialog.bold" "Dialog.bolditalic" "Dialog.italic" "Dialog.plain" "DialogInput.bold" "DialogInput.bolditalic" "DialogInput.italic" "DialogInput.plain" "Dimnah" "Dingbats " "Electron" "Free Monospaced" "Free Monospaced Bold" "Free Monospaced Bold Oblique" "Free Monospaced Oblique" "Free Sans" "Free Sans Bold" "Free Sans Bold Oblique" "Free Sans Oblique" "Free Serif" "Free Serif Bold" "Free Serif Bold Italic" "Free Serif Italic" "Furat" "Garuda" "Garuda Bold" "Garuda Bold Oblique" "Garuda Oblique" "Granada" "Graph" "Hani" "Haramain" "Hor" "Jamrul" "Japan" "Jet" "Kayrawan" "Kedage Bold" "Kedage BoldItalic" "Kedage Normal" "Kedage NormalItalic" "Khalid" "Kinnari" "Kinnari Bold" "Kinnari Bold Italic" "Kinnari Bold Oblique" "Kinnari Italic" "Kinnari Oblique" "Kochi Gothic" "Kochi Mincho" "Likhan" "Lohit Bengali" "Lohit Gujarati" "Lohit Hindi" "Lohit Kannada" "Lohit Oriya" "Lohit Punjabi" "Lohit Tamil" "Lohit Telugu" "Loma" "Loma Bold" "Loma Bold Oblique" "Loma Oblique" "Mallige Bold" "Mallige BoldItalic" "Mallige Normal" "Mallige NormalItalic" "Mashq" "Mashq Bold" "Metal" "Mitra Mono" "Monospaced.bold" "Monospaced.bolditalic" "Monospaced.italic" "Monospaced.plain" "Mukti Narrow" "Mukti Narrow Bold" "Nada" "Nagham" "Nice" "Nimbus Mono L Bold" "Nimbus Mono L Bold Oblique" "Nimbus Mono L Regular" "Nimbus Mono L Regular Oblique" "Nimbus Roman No9 L Medium" "Nimbus Roman No9 L Medium Italic" "Nimbus Roman No9 L Regular" "Nimbus Roman No9 L Regular Italic" "Nimbus Sans L Bold" "Nimbus Sans L Bold Condensed" "Nimbus Sans L Bold Condensed Italic" "Nimbus Sans L Bold Italic" "Nimbus Sans L Regular" "Nimbus Sans L Regular Condensed" "Nimbus Sans L Regular Condensed Italic" "Nimbus Sans L Regular Italic" "Norasi" "Norasi Bold" "Norasi Bold Italic" "Norasi Bold Oblique" "Norasi Italic" "Norasi Oblique" "OpenSymbol" "Ostorah" "Ouhod Bold" "Petra" "Phetsarath OT" "Pothana2000" "Purisa" "Rachana" "Rasheeq Bold" "Rehan" "Salem" "Samyak Oriya" "SansSerif.bold" "SansSerif.bolditalic" "SansSerif.italic" "SansSerif.plain" "Sawasdee" "Sawasdee Bold" "Sawasdee Bold Oblique" "Sawasdee Oblique" "Serif.bold" "Serif.bolditalic" "Serif.italic" "Serif.plain" "Shado" "Sharjah" "Sindbad" "Standard Symbols L" "Tarablus" "Tholoth" "Tlwg Mono" "Tlwg Mono Bold" "Tlwg Mono Bold Oblique" "Tlwg Mono Oblique" "Tlwg Typewriter" "Tlwg Typewriter Bold" "Tlwg Typewriter Bold Oblique" "Tlwg Typewriter Mono Oblique" "Tlwg Typist" "Tlwg Typist Bold" "Tlwg Typist Bold Oblique" "Tlwg Typist Oblique" "Tlwg Typo" "Tlwg Typo Bold" "Tlwg Typo Bold Oblique" "Tlwg Typo Oblique" "URW Bookman L Demi Bold" "URW Bookman L Demi Bold Italic" "URW Bookman L Light" "URW Bookman L Light Italic" "URW Chancery L Medium Italic" "URW Gothic L Book" "URW Gothic L Book Oblique" "URW Gothic L Demi" "URW Gothic L Demi Oblique" "URW Palladio L Bold" "URW Palladio L Bold Italic" "URW Palladio L Italic" "URW Palladio L Roman" "Umpush" "Umpush Bold" "Umpush Bold Oblique" "Umpush Light" "Umpush Light Oblique" "Umpush Oblique" "Un Batang" "Un Batang Bold" "Un Dotum" "Un Dotum Bold" "Vemana2000" "Waree" "Waree Bold" "Waree Bold Oblique" "Waree Oblique" "WenQuanYi Zen Hei" "utkal medium"

Re: Java binary, can't redirect stderr on VM crash

Mark Wielaard — 2008-11-27T22:04:16

Hi Patrick, On Thu, 2008-11-27 at 22:24 +0100, Patrick Wright wrote: If you have the debug info packages installed you can probably run this under gdb and get a good backtrace leading directly to the source code that calls the bad free(). You might also get more glibc malloc checking by export MALLOC_CHECK_=3 (see man malloc). That might catch an issue somewhat earlier. And probably also in a hs_err_pid[0-9].log file in your working directory. I am not sure why your redirecting doesn't work. The first variant should indeed do what you want. If you could post the RenderFontTest.java file then I could try to replicate locally if you want. Cheers, Mark

Re: Java binary, can't redirect stderr on VM crash

Christopher Hegarty - Sun Microsystems — 2008-11-27T22:11:06

Hi Patrick, I'm certainly not an expert in this area, but coincidentally I just looked into a similar issue related to redirecting vm output. The java launcher does exec to replace the current process image with a new process image in order to set various environment variables, etc. Therefore, there can be issues relating to env variables inherited and maybe in your case redirection. With Sun's JDK 6 and OpenJDK you should be able to redirect the vm output to a log file with the following options. -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=/tmp/hotspot.log -Chris. Patrick Wright wrote:

Re: Java binary, can't redirect stderr on VM crash

Tim Bell — 2008-11-27T21:59:29

Patrick: Is this test program ("RenderFontTest") something you could share with the list? Also, what font(s) are you testing when the crash happens? With this information we can try the testing on other platforms and throw additional troubleshooting resources such as libumem on Solaris at the problem. Looks as if this output is coming from down inside the free() implementation in the libc library on the native platform. : : Try this: java -cp out/production/Samples RenderFontTest "AR PL UMing CN" > /tmp/err.txt 2>&1 Or run your testing inside a /usr/bin/script session to catch the transcript. See 'man script' for more information. HTH - Tim

Java binary, can't redirect stderr on VM crash

Patrick Wright — 2008-11-27T21:24:27

Hi all I'm trying to track down a VM crash related to some part of the 2D stack. I've already written 2D-dev and they asked me to narrow it down. I have a question about how bin/java handles error output on a VM crash. Problem: I'm testing from the CLI, bash, on Ubuntu 8.10. I need to run my test program once for every font on the full font list for the JRE. However, when the program crashes (on working with the font), I get several dozen lines of VM crash output, and I'm not able to redirect this to a file. This is painful and I have many fonts to test to try and track the problem down. Example crash output starts like: *** glibc detected *** /usr/lib/jvm/java-6-openjdk/bin/java: free(): invalid next size (fast): 0xb4cc7288 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7f753f4] /lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7f77456] /usr/lib/jvm/java-6-openjdk/jre/lib/i386/libfontmanager.so[0xb4d37073] /usr/lib/jvm/java-6-openjdk/jre/lib/i386/libfontmanager.so[0xb4d3cec0] /usr/lib/jvm/java-6-openjdk/jre/lib/i386/libfontmanager.so[0xb4d3f42d] /usr/lib/jvm/java-6-openjdk/jre/lib/i386/libfontmanager.so[0xb4d3f530] I've tried redirect like java -cp out/production/Samples RenderFontTest "AR PL UMing CN" &>/tmp/err.txt java -cp out/production/Samples RenderFontTest "AR PL UMing CN" 2>/tmp/err.txt java -cp out/production/Samples RenderFontTest "AR PL UMing CN" 2>&1 In all cases, the crash report goes to the console. This happens with both Sun JDK 6 and OpenJDK 6. And the output is _long_. Versions involved: tuxdistro< at >ubuntu-desktop:~ $ /usr/lib/jvm/java-6-openjdk/bin/java -version java version "1.6.0_0" IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) tuxdistro< at >ubuntu-desktop:~ $ java -version java version "1.6.0_10" Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) tuxdistro< at >ubuntu-desktop:~ $ bash -version GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. Is the bin/java binary forking a process off? TIA, please redirect me if there's a better place to ask. Patrick PS: my bash-fu is very weak, sadly

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

Andrew John Hughes — 2008-11-26T06:06:06

2008/11/25 Andrew Haley public.gmane.org>: I didn't. I was just pointing out that this was a collection of patches from different people, some of which weren't under the SCA. all being contributed by you or Red Hat. I wasn't saying that the SCA was necessary for the contributions and I agree they are trivial/obvious; I'd have applied similar patches to Classpath without an assignment provided the same contributor didn't have a mass of other existing small patches. However, in my experience, Sun wants an SCA for *every* contribution and I had to have one in place for a similar one-liner.

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

Andrew Haley — 2008-11-25T09:52:47

You shouldn't just say "no assignment, so we can't apply these" without actually looking at the patches. icedtea-no-bcopy.patch simply removes a few lines of code. I am not a lawyer, but IMO that doesn't need copyright assignment. The citypeflow change is enum Cell { - Cell_0 + Cell_0, Cell_max = UINT_MAX }; which is the trivial/obvious way to fix it. Andrew.

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

Xiomara Jayasena — 2008-11-25T06:27:44

Thanks for the clarification, Martin. -Xiomara

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

Martin Buchholz — 2008-11-25T06:07:33

On Mon, Nov 24, 2008 at 21:19, Andrew John Hughes public.gmane.org> wrote: The citypeflow patch is already in openjdk. There were several variations on this very small patch, but the one in openjdk is the one authored by Google. Martin

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

Xiomara Jayasena — 2008-11-25T05:34:48

I believe an SCA sign by Matthias will be needed so the patches can be integrated. Let me investigate and get back to doko< at >... Thanks, -Xiomara

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

Andrew Haley — 2008-11-24T18:17:56

OK. * icedtea-f2i-overflow.patch fixes some overflows that are undefined behaviour in C++. * icedtea-hotspot-citypeflow.patch fixes an incorrect use of an enum. * icedtea-lib64.patch fixes directory search paths. * icedtea-gcc-4.3.patch fixes some compilation errors. * icedtea-no-bcopy.patch removes the definition of the BSD bcopy and bcmp functions. The first two are really important because without them g++ generates bad code. Andrew.