From mr at sun.com  Mon Nov  3 16:18:38 2008
From: mr at sun.com (Mark Reinhold)
Date: Mon, 03 Nov 2008 08:18:38 -0800
Subject: Request for permission letter 
In-Reply-To: vmikheev@excelsior-usa.com; Wed, 29 Oct 2008 17:08:33 +0600;
	<C499FB28FD6BEE458071184CE929A111F62BC6@mail.excelsior> 
Message-ID: <20081103161838.BB864E09D3@eggemoggin.niobe.net>

> Date: Wed, 29 Oct 2008 17:08:33 +0600
> From: Vitaly Mikheev <vmikheev at excelsior-usa.com>

> I'm with Excelsior Java Team. Excelsior LLC has been a Java SE Licensee
> since 2005.
> 
> We would like to contribute some fixes in AWT native methods we have
> made in our implementation during these years. Basically, they were
> inspired by either support cases or our internal QA.
> 
> In addition, we've also discovered a few issues in HotSpot we found
> when using the Reference Implementation for reference (pun
> intended;). Despite our JVM is not a HS derivative, we want the issues
> to be fixed and contribute the necessary modifications.
> 
> However, SCSL does permit us to contribute to OpenJDK under SCA.
> 
> As mentioned in FAQ at
> 
>   http://www.sun.com/software/opensource/java/faq.jsp
> 
> we have to post a request here to resolve it.
> 
> Please send me the letter granting the necessary permission. The signed
> SCA has been already faxed.

Vitaly -- thanks for your interest.  We'll need to check a couple
of details with our legal team, but we should be able to send you
the permission letter in the next week or so.

- Mark


From vmikheev at excelsior-usa.com  Wed Nov  5 12:16:49 2008
From: vmikheev at excelsior-usa.com (Vitaly Mikheev)
Date: Wed, 5 Nov 2008 18:16:49 +0600
Subject: Request for permission letter 
Message-ID: <C499FB28FD6BEE458071184CE929A111F62C31@mail.excelsior>

>Vitaly -- thanks for your interest.  We'll need to check a couple
>of details with our legal team, but we should be able to send you
>the permission letter in the next week or so.

Mark -- thank you. Making an optimistic assumption about the letter,
we have started preparing the materials for the first contribution.

--Vitaly

> -----Original Message-----
> From:	mr at sun.com [SMTP:mr at sun.com]
> Sent:	Monday, November 03, 2008 10:19 PM
> To:	Vitaly Mikheev
> Cc:	discuss at openjdk.java.net
> Subject:	Re: Request for permission letter 
> 
> > Date: Wed, 29 Oct 2008 17:08:33 +0600
> > From: Vitaly Mikheev <vmikheev at excelsior-usa.com>
> 
> > I'm with Excelsior Java Team. Excelsior LLC has been a Java SE Licensee
> > since 2005.
> > 
> > We would like to contribute some fixes in AWT native methods we have
> > made in our implementation during these years. Basically, they were
> > inspired by either support cases or our internal QA.
> > 
> > In addition, we've also discovered a few issues in HotSpot we found
> > when using the Reference Implementation for reference (pun
> > intended;). Despite our JVM is not a HS derivative, we want the issues
> > to be fixed and contribute the necessary modifications.
> > 
> > However, SCSL does permit us to contribute to OpenJDK under SCA.
> > 
> > As mentioned in FAQ at
> > 
> >   http://www.sun.com/software/opensource/java/faq.jsp
> > 
> > we have to post a request here to resolve it.
> > 
> > Please send me the letter granting the necessary permission. The signed
> > SCA has been already faxed.
> 
> Vitaly -- thanks for your interest.  We'll need to check a couple
> of details with our legal team, but we should be able to send you
> the permission letter in the next week or so.
> 
> - Mark


From Xiomara.Jayasena at Sun.COM  Fri Nov  7 04:56:05 2008
From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena)
Date: Thu, 06 Nov 2008 20:56:05 -0800
Subject: JDK 7 build 39  is available at the openjdk.java.net website
Message-ID: <4913CA65.1080207@sun.com>



The OpenJDK source is available at:
http://hg.openjdk.java.net/jdk7/jdk7
http://hg.openjdk.java.net/jdk7/jdk7/rev/ab523b49de1f

The OpenJDK source binary plugs for the promoted JDK 7 build 39 are 
available under the openjdk http://openjdk.java.net website under Source 
Code (direct link to bundles: http://download.java.net/openjdk/jdk7)

Summary of changes:
http://download.java.net/jdk7/changes/jdk7-b39.html


-Xiomara


From mark at klomp.org  Mon Nov 17 18:53:53 2008
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 17 Nov 2008 19:53:53 +0100
Subject: Free Java Meeting at Fosdem - Brussels, Belgium on 7 and 8
	February 2009
Message-ID: <1226948033.3264.68.camel@dijkstra.wildebeest.org>

Hi all,

Since we always have so much fun meeting each other at Fosdem we have
again applied for a Developer Room at Fosdem early next year. This year
Fosdem will be taking place in Brussels, Belgium on Saturday 7 and
Sunday 8 February 2009. FOSDEM '09 is a free and non-commercial event
organized by the community, for the community. Its goal is to provide
Free and Open Source developers a place to meet. http://fosdem.org/2009/

We should know early next week if a developer room is available. If so
we will start collecting ideas for activities. If there isn't a
developer room available we will figure out something else.

Hope to see you there, you friendly ad hoc Fosdem meeting committee,

Dalibor Topic,
Andrew John Hughes,
Andrew Haley,
David Herron
and Mark Wielaard



From Xiomara.Jayasena at Sun.COM  Fri Nov 21 03:34:07 2008
From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena)
Date: Thu, 20 Nov 2008 19:34:07 -0800
Subject: JDK 7 build 40  is available at the openjdk.java.net website
Message-ID: <49262C2F.1050106@sun.com>



The OpenJDK source is available at:
http://hg.openjdk.java.net/jdk7/jdk7
http://hg.openjdk.java.net/jdk7/jdk7/rev/44be42de6693

The OpenJDK source binary plugs for the promoted JDK 7 build 40 are 
available under the openjdk http://openjdk.java.net website under Source 
Code (direct link to bundles: http://download.java.net/openjdk/jdk7)

Summary of changes:
http://download.java.net/jdk7/changes/jdk7-b40.html


-Xiomara



From linuxhippy at gmail.com  Sat Nov 22 15:59:21 2008
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sat, 22 Nov 2008 16:59:21 +0100
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <490938A9.9050201@sun.com>
References: <490938A9.9050201@sun.com>
Message-ID: <194f62550811220759t669a2fd5mf99cd53df1634a6e@mail.gmail.com>

So JDK7 (the SUN builds) will be built with GCC-4.2.1 instead of the 3.2.1?
Would be a really welcome change ;)

Thx, Clemens

2008/10/30 Xiomara Jayasena <Xiomara.Jayasena at sun.com>:
>
> Hi,
>
> The official Release Engineering builds for JDK 7 will be moving from the
> following OSs:
>
> *32 bit builds*
> ==========
> *From: *RH AS 2.1 to Fedora 9
>
> *64 bit builds*
> ==========
> *From: *SUSE 8 to: Fedora 9
>
> All required Makefile changes are in place, there are still  other items
> that are still being investigated for this OS upgrade to happen but wanted
> to inform of the changes that are on the way.
> *When:*  It is expected that this change will happen by build 42.
>
> Please let me know if there are any questions.
>
> Thanks,
> -Xiomara
>
>


From Kelly.Ohair at Sun.COM  Sat Nov 22 18:11:04 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Sat, 22 Nov 2008 10:11:04 -0800
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <194f62550811220759t669a2fd5mf99cd53df1634a6e@mail.gmail.com>
References: <490938A9.9050201@sun.com>
	<194f62550811220759t669a2fd5mf99cd53df1634a6e@mail.gmail.com>
Message-ID: <49284B38.70707@sun.com>

To clarify a little, yes this means gcc4, or whatever the default
gcc/g++ on the Fedora 9 system is, if Fedora 9 changes it, we change too.

I would not read too much into the pick of Fedora 9, we needed to pick one
that we could focus on, the important message is that we want to advance
a newer Linux system. If a new Fedora releases we might even change to it,
we want to be as flexible as possible.

Our hope is that the OpenJDK developers will use lots of different
Linux systems and gcc compiler versions in their day-to-day development
work, reporting any issues they run into.

I know there are lots of things we can do to improve the build situation,
this one was considered a major first step.

-kto

Clemens Eisserer wrote:
> So JDK7 (the SUN builds) will be built with GCC-4.2.1 instead of the 3.2.1?
> Would be a really welcome change ;)
> 
> Thx, Clemens
> 
> 2008/10/30 Xiomara Jayasena <Xiomara.Jayasena at sun.com>:
>> Hi,
>>
>> The official Release Engineering builds for JDK 7 will be moving from the
>> following OSs:
>>
>> *32 bit builds*
>> ==========
>> *From: *RH AS 2.1 to Fedora 9
>>
>> *64 bit builds*
>> ==========
>> *From: *SUSE 8 to: Fedora 9
>>
>> All required Makefile changes are in place, there are still  other items
>> that are still being investigated for this OS upgrade to happen but wanted
>> to inform of the changes that are on the way.
>> *When:*  It is expected that this change will happen by build 42.
>>
>> Please let me know if there are any questions.
>>
>> Thanks,
>> -Xiomara
>>
>>


From gnu_andrew at member.fsf.org  Sun Nov 23 01:31:21 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 23 Nov 2008 01:31:21 +0000
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <49284B38.70707@sun.com>
References: <490938A9.9050201@sun.com>
	<194f62550811220759t669a2fd5mf99cd53df1634a6e@mail.gmail.com>
	<49284B38.70707@sun.com>
Message-ID: <17c6771e0811221731h5a4d75baocd5d7eb62ab48544@mail.gmail.com>

On 22/11/2008, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
> To clarify a little, yes this means gcc4, or whatever the default
>  gcc/g++ on the Fedora 9 system is, if Fedora 9 changes it, we change too.
>
>  I would not read too much into the pick of Fedora 9, we needed to pick one
>  that we could focus on, the important message is that we want to advance
>  a newer Linux system. If a new Fedora releases we might even change to it,
>  we want to be as flexible as possible.
>
>  Our hope is that the OpenJDK developers will use lots of different
>  Linux systems and gcc compiler versions in their day-to-day development
>  work, reporting any issues they run into.
>
>  I know there are lots of things we can do to improve the build situation,
>  this one was considered a major first step.
>
>  -kto
>
>
>  Clemens Eisserer wrote:
>
> > So JDK7 (the SUN builds) will be built with GCC-4.2.1 instead of the
> 3.2.1?
> > Would be a really welcome change ;)
> >
> > Thx, Clemens
> >
> > 2008/10/30 Xiomara Jayasena <Xiomara.Jayasena at sun.com>:
> >
> > > Hi,
> > >
> > > The official Release Engineering builds for JDK 7 will be moving from
> the
> > > following OSs:
> > >
> > > *32 bit builds*
> > > ==========
> > > *From: *RH AS 2.1 to Fedora 9
> > >
> > > *64 bit builds*
> > > ==========
> > > *From: *SUSE 8 to: Fedora 9
> > >
> > > All required Makefile changes are in place, there are still  other items
> > > that are still being investigated for this OS upgrade to happen but
> wanted
> > > to inform of the changes that are on the way.
> > > *When:*  It is expected that this change will happen by build 42.
> > >
> > > Please let me know if there are any questions.
> > >
> > > Thanks,
> > > -Xiomara
> > >
> > >
> > >
> >
>


Well F10 is out on Tuesday so choosing F9 seems strange...

But I don't get the point of this mail anyway.  OpenJDK already builds
fine on F9 and F10 for me.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From martinrb at google.com  Sun Nov 23 03:18:36 2008
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 22 Nov 2008 19:18:36 -0800
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <17c6771e0811221731h5a4d75baocd5d7eb62ab48544@mail.gmail.com>
References: <490938A9.9050201@sun.com>
	<194f62550811220759t669a2fd5mf99cd53df1634a6e@mail.gmail.com>
	<49284B38.70707@sun.com>
	<17c6771e0811221731h5a4d75baocd5d7eb62ab48544@mail.gmail.com>
Message-ID: <1ccfd1c10811221918o71fd40d8l8e6c995e98555448@mail.gmail.com>

On Sat, Nov 22, 2008 at 17:31, Andrew John Hughes
<gnu_andrew at member.fsf.org> wrote:

> Well F10 is out on Tuesday so choosing F9 seems strange...

Andrew, you appear to live in a different world from the rest of us.
Operating systems generally try to be backward compatible,
so from my point of view using Fedora 9 seems offhand very aggressive.
My rule of thumb was to build production binaries on the oldest
systems you are willing to support.  What developers should use is
a different story.

> But I don't get the point of this mail anyway.  OpenJDK already builds
> fine on F9 and F10 for me.

It is of great interest to me.  In future, if my build is broken,
I will first ask, "How is my system different from Fedora 9?".

Martin


From gnu_andrew at member.fsf.org  Sun Nov 23 08:41:02 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 23 Nov 2008 08:41:02 +0000
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <1ccfd1c10811221918o71fd40d8l8e6c995e98555448@mail.gmail.com>
References: <490938A9.9050201@sun.com>
	<194f62550811220759t669a2fd5mf99cd53df1634a6e@mail.gmail.com>
	<49284B38.70707@sun.com>
	<17c6771e0811221731h5a4d75baocd5d7eb62ab48544@mail.gmail.com>
	<1ccfd1c10811221918o71fd40d8l8e6c995e98555448@mail.gmail.com>
Message-ID: <17c6771e0811230041h421c08e4xb2ae07e6e287bcfd@mail.gmail.com>

On 23/11/2008, Martin Buchholz <martinrb at google.com> wrote:
> On Sat, Nov 22, 2008 at 17:31, Andrew John Hughes
>  <gnu_andrew at member.fsf.org> wrote:
>
>  > Well F10 is out on Tuesday so choosing F9 seems strange...
>
>
> Andrew, you appear to live in a different world from the rest of us.
>  Operating systems generally try to be backward compatible,
>  so from my point of view using Fedora 9 seems offhand very aggressive.
>  My rule of thumb was to build production binaries on the oldest
>  systems you are willing to support.  What developers should use is
>  a different story.
>

Not really.  If you're saying you want the oldest system while still
maintaining reasonably close to the majority of systems in general
use, then yes I agree F9 is aggressive, as I'd like to know the build
isn't going to be unknowingly broken in really bad ways on current
Debian stable or RHEL 4/5, both of which are much older (though Debian
stable will soon become a more recent release).

 I was reading it as where do we want to do test builds to ensure we
catch the new issues that are going to arise.  Apparently there are
already issues building with the new Ubuntu release due to a
backported gcc 4.4 patch, but I haven't been able to verify this as I
don't have software installed that is so bleeding edge ;)

I don't see why anyone other than developers or prospective developers
would be building OpenJDK.  Actual users would find it much easier
just using the package for their distro and you'll find one in Fedora,
Ubuntu, Debian and (with some work) RHEL and Gentoo.

>
>  > But I don't get the point of this mail anyway.  OpenJDK already builds
>  > fine on F9 and F10 for me.
>
>
> It is of great interest to me.  In future, if my build is broken,
>  I will first ask, "How is my system different from Fedora 9?".
>
>

Then should we be posting successful build testimonials here? Would
that help? My own builds and blogs I've seen by others suggest builds
on a variety of GNU/Linux platforms over and above just F9.

>  Martin
>

-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From martinrb at google.com  Sun Nov 23 17:41:18 2008
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 23 Nov 2008 09:41:18 -0800
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <17c6771e0811230041h421c08e4xb2ae07e6e287bcfd@mail.gmail.com>
References: <490938A9.9050201@sun.com>
	<194f62550811220759t669a2fd5mf99cd53df1634a6e@mail.gmail.com>
	<49284B38.70707@sun.com>
	<17c6771e0811221731h5a4d75baocd5d7eb62ab48544@mail.gmail.com>
	<1ccfd1c10811221918o71fd40d8l8e6c995e98555448@mail.gmail.com>
	<17c6771e0811230041h421c08e4xb2ae07e6e287bcfd@mail.gmail.com>
Message-ID: <1ccfd1c10811230941x2e777cb0x37b91344ad90ae63@mail.gmail.com>

Andrew,

I think we still have a mismatch of expectations.
Sun has historically provided binaries as their primary deliverable,
and continues to operate the "business" side of JDK development
in that way.  The problem of building a binary distribution that
will run well on as many systems in actual use as possible is a
different (and probably, harder) problem than what distro
maintainers do, which is to always take source, never binaries,
from upstream, and build binaries designed only to ever run
on the same system they were built on.  A packager at a
company might want to use Sun's approach, and build
one set of supported binaries that will work on a relatively
disparate set of target machines within the company.

Another way of looking at it - it's a (Sun) bug
if Sun-built Fedora 9 binaries fail to run well on Ubuntu dapper,
whereas I doubt that the Fedora community itself is aiming
for that kind of compatibility.

Your suggestion of advertising test build successes is a good one.
For the record, I have been and will continue to build all releases
of openjdk6 and openjdk7 on Ubuntu dapper, and will attempt
to fix (or report) any failures doing so.

Martin

On Sun, Nov 23, 2008 at 00:41, Andrew John Hughes
<gnu_andrew at member.fsf.org> wrote:

> Then should we be posting successful build testimonials here? Would
> that help? My own builds and blogs I've seen by others suggest builds
> on a variety of GNU/Linux platforms over and above just F9.


From Jonathan.Gibbons at Sun.COM  Sun Nov 23 17:57:13 2008
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Sun, 23 Nov 2008 09:57:13 -0800
Subject: Allowing partial jtreg samejvm safe runs
In-Reply-To: <1227460674.29485.26.camel@hermans.wildebeest.org>
References: <1227460674.29485.26.camel@hermans.wildebeest.org>
Message-ID: <EB6434B6-6268-4806-97DC-0DC094BCF487@sun.com>

Mark,

I like this approach in that we don't mess up the tests with /othervm  
keywords
unnecessarily.  I think it is worth distinguishing tests which are  
inherently
"othervm" from those which are "currently othervm but potentially  
samevm with
a bit of effort".

-- Jon

On Nov 23, 2008, at 9:17 AM, Mark Wielaard wrote:

> Hi,
>
> Jonathan Gibbons has been extending jtreg so that tests can be run in
> the same vm. He also made it so that most langtools tests are run that
> way. That brings an enormous speed up. Since running all jdk tests  
> takes
> ages it would be great if we could use this same speedup there.
>
> Problem is that -samevm only works if all tests have been adapted to
> behave well (or marked as needing /othervm). So my idea was to add a
> "whitelist mechanism" so you can indicate which (sub)dirs are ready to
> be run with samevm.
>
> Luckily jtreg has mostly been setup for this already. All Actions ask
> their Script whether or not they should be running in an othervm. So  
> we
> hook into that to check the scripts location against a whitelist.
>
> I choose the TEST.ROOT file as the location of the whitelist. Since  
> that
> is also the root of the test suite. I made the code so that the
> whitelist is only used when running the full test suite from the root.
> That way you can still experiment with -samevm or -othervm when  
> running
> subtrees of tests.
>
> Also CCed jdk-regtest at sun.com since that address is mentioned in the
> TEST.ROOT file with an request to contact them if you change  
> anything in
> that file.
>
> Below is the implementation as I checked into icedtea6 (patch also
> attached).
>
> 2008-11-23  Mark Wielaard  <mark at klomp.org>
>
>    * test/jtreg/com/sun/javatest/regtest/Main.java
>    (createParameters): Set same jvm safe dirs when non-null.
>    (getSameJVMSafeDirs): New method that reads samejvmsafe property
>    from TEST.ROOT.
>    (sameJVMSafeDirs): New private field.
>    * test/jtreg/com/sun/javatest/regtest/RegressionParameters.java
>    (SAME_JVM_SAFE_DIRS): New static final field.
>    (load): Read same jvm safe dirs.
>    (save0): Write same jvm safe dirs.
>    (getSameJVMSafeDirs): New method.
>    (setSameJVMSafeDirs): New method.
>    * test/jtreg/com/sun/javatest/regtest/RegressionScript.java
>    (run): Set testDirPath.
>    (isOtherJVM): Take same jvm safe into account.
>    (isSameJVMSafe): New method.
>    (testDirPath): New private field.
>
> For icedtea6 I did a quick scan of the openjdk/jdk/test subdirs and
> listed an initial set that work with -samejvm and added a patch to
> augment the TEST.ROOT file (attached).
>
> 2008-11-23  Mark Wielaard  <mark at klomp.org>
>
>    * patches/icedtea-samejvm-safe.patch: New patch.
>    * Makefile.am (ICEDTEA_PATCHES): Add new patch.
>    (check-jdk): Run jtreg with -samevm.
>    * HACKING: Document new patch.
>
> Comments on the idea and the implementation very appreciated.
>
> With this 'make check-jdk' takes a little bit less than 3 hours on my
> machine now. It was almost 3.5 hours, so it already saves a lot of  
> time.
> But we need to make much more tests work with samevm to bring the  
> total
> test running time down to something an ordinary developer would be
> comfortable with running every day.
>
> We have to see whether or not that is really possible. It seems jdi,  
> rmi
> and awt take up a lot of the time needed to run all tests, and I am  
> not
> sure those tests can be speed up much.
>
> Cheers,
>
> Mark
> diff -r 9aae858397f9 test/jtreg/com/sun/javatest/regtest/Main.java
> --- a/test/jtreg/com/sun/javatest/regtest/Main.java	Fri Nov 21  
> 18:35:27 2008 -0500
> +++ b/test/jtreg/com/sun/javatest/regtest/Main.java	Sun Nov 23  
> 16:56:34 2008 +0100
> @@ -29,6 +29,7 @@
> import java.io.BufferedReader;
> import java.io.BufferedWriter;
> import java.io.File;
> +import java.io.FileInputStream;
> import java.io.FileNotFoundException;
> import java.io.FileReader;
> import java.io.FileWriter;
> @@ -52,6 +53,7 @@
> import java.util.Iterator;
> import java.util.List;
> import java.util.Map;
> +import java.util.Properties;
> import java.util.TreeMap;
>
> import com.sun.javatest.CompositeFilter;
> @@ -1354,6 +1356,10 @@
>             if (ignoreKind != null)
>                 rp.setIgnoreKind(ignoreKind);
>
> +            sameJVMSafeDirs = getSameJVMSafeDirs(ts);
> +            if (sameJVMSafeDirs != null)
> +                rp.setSameJVMSafeDirs(sameJVMSafeDirs);
> +
>             return rp;
>         } catch (TestSuite.Fault f) {
>             f.printStackTrace();
> @@ -1372,6 +1378,35 @@
>         } catch (IOException e) {
>             return file.getAbsoluteFile();
>         }
> +    }
> +
> +    // Returns directory (prefix) for tests that are same jvm safe
> +    // read from amejvmsafe property in TEST.ROOT file. Returning  
> null
> +    // means all tests are considered same jvm safe. null is returned
> +    // when there is no samejvmsafe property, or there was a problem
> +    // reading it, and when anything else than the test root was  
> given
> +    // as test file argument. Meaning that this only returns  
> something
> +    // non-null if anything was actually specified as same jvm safe  
> and
> +    // the whole test suite is being tested.
> +    private List<String> getSameJVMSafeDirs(File testRoot) {
> +	// Only use the same jvm safe dirs when running from the root.
> +	if (testFileArgs.size() != 1
> +	    || ! 
> canon(testFileArgs.iterator().next()).equals(canon(testRoot)))
> +	    return null;
> +
> +	try {
> +	    File file = new File(testRoot, "TEST.ROOT");
> +            if (file.exists()) {
> +		Properties testRootProps = new Properties();
> +		testRootProps.load(new FileInputStream(file));
> +		String safedirs = testRootProps.getProperty("samejvmsafe");
> +		if ((safedirs != null) && (safedirs.trim().length() > 0))
> +		    return Arrays.asList(StringArray.splitWS(safedirs));
> +	    }
> +	} catch (IOException ioe) {
> +	    // Bah, then just assume everything is safe.
> +	}
> +	return null;
>     }
>
>     private String getRelativePath(File base, File f) {
> @@ -1762,6 +1797,7 @@
>     // these args are jtreg extras
>     private File baseDirArg;
>     private boolean sameJVMFlag;
> +    private List<String> sameJVMSafeDirs;
>     private JDK jdk;
>     private boolean guiFlag;
>     private boolean reportOnlyFlag;
> diff -r 9aae858397f9 test/jtreg/com/sun/javatest/regtest/ 
> RegressionParameters.java
> --- a/test/jtreg/com/sun/javatest/regtest/RegressionParameters.java	 
> Fri Nov 21 18:35:27 2008 -0500
> +++ b/test/jtreg/com/sun/javatest/regtest/RegressionParameters.java	 
> Sun Nov 23 16:56:34 2008 +0100
> @@ -139,6 +139,7 @@
>     private static final String TEST_JAVA_OPTIONS = ".testJavaOpts";
>     private static final String IGNORE = ".ignore";
>     private static final String RETAIN_ARGS = ".retain";
> +    private static final String SAME_JVM_SAFE_DIRS =  
> ".samejvmsafedirs";
>
>     @Override
>     public void load(Map data, boolean checkChecksum) throws  
> Interview.Fault {
> @@ -182,6 +183,10 @@
>         v = (String) data.get(prefix + RETAIN_ARGS);
>         if (v != null)
>              
> setRetainArgs(Arrays.asList(StringArray.splitSeparator("\n", v)));
> +
> +        v = (String) data.get(prefix + SAME_JVM_SAFE_DIRS);
> +        if (v != null)
> +             
> setSameJVMSafeDirs(Arrays.asList(StringArray.splitSeparator("\n",  
> v)));
>     }
>
>     @SuppressWarnings("unchecked")
> @@ -203,6 +208,9 @@
>
>         if (jdk != null)
>             data.put(prefix + JDK, jdk.getPath());
> +
> +        if (sameJVMSafeDirs != null)
> +            data.put(prefix + SAME_JVM_SAFE_DIRS,  
> StringUtils.join(sameJVMSafeDirs, "\n"));
>
>         if (retainArgs != null)
>             data.put(prefix + RETAIN_ARGS,  
> StringUtils.join(retainArgs, "\n"));
> @@ -592,6 +600,18 @@
>     private Pattern retainFilesPattern;
>
>     //---------------------------------------------------------------------
> +
> +    List<String> getSameJVMSafeDirs() {
> +        return sameJVMSafeDirs;
> +    }
> +
> +    void setSameJVMSafeDirs(List<String> sameJVMSafeDirs) {
> +        this.sameJVMSafeDirs= sameJVMSafeDirs;
> +    }
> +
> +    private List<String> sameJVMSafeDirs;
> +
> + 
>     //---------------------------------------------------------------------
>
>     private static final String PATHSEP  =  
> System.getProperty("path.separator");
>     private static final String LINESEP  =  
> System.getProperty("line.separator");
> diff -r 9aae858397f9 test/jtreg/com/sun/javatest/regtest/ 
> RegressionScript.java
> --- a/test/jtreg/com/sun/javatest/regtest/RegressionScript.java	Fri  
> Nov 21 18:35:27 2008 -0500
> +++ b/test/jtreg/com/sun/javatest/regtest/RegressionScript.java	Sun  
> Nov 23 16:56:34 2008 +0100
> @@ -69,6 +69,10 @@
>     public Status run(String[] argv, TestDescription td,  
> TestEnvironment env) {
>         if (!(env instanceof RegressionEnvironment))
>             throw new AssertionError();
> +
> +	String testFilePath = td.getRootRelativePath();
> +	int lastSlash = testFilePath.lastIndexOf('/');
> +	testDirPath = testFilePath.substring(0, lastSlash);
>
>         regEnv = (RegressionEnvironment) env;
>         params = regEnv.params;
> @@ -833,7 +837,26 @@
>     }
>
>     boolean isOtherJVM() {
> -        return params.isOtherJVM();
> +	boolean samevm = !params.isOtherJVM();
> +	if (samevm)
> +	    return !isSameJVMSafe();
> +	else
> +	    return true;
> +    }
> +
> +    // Whether the actions of this script can safely run in the  
> same jvm.
> +    // No same jvm safe dirs given means they are all assumed safe.
> +    // If our actions come from a file in a subdir of a safe dir  
> that is ok.
> +    boolean isSameJVMSafe() {
> +        List<String> dirs = params.getSameJVMSafeDirs();
> +	if (dirs == null)
> +	    return true;
> +
> +	for (String dir : dirs)
> +	    if (testDirPath.startsWith(dir))
> +		return true;
> +
> +	return false;
>     }
>
>     String getJavaProg() {
> @@ -921,5 +944,6 @@
>
>     private RegressionEnvironment regEnv;
>     private RegressionParameters params;
> +    private String testDirPath;
> }
>
> <icedtea-samejvm-safe.patch>



From Kelly.Ohair at Sun.COM  Sun Nov 23 18:25:03 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Sun, 23 Nov 2008 10:25:03 -0800
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <17c6771e0811230041h421c08e4xb2ae07e6e287bcfd@mail.gmail.com>
References: <490938A9.9050201@sun.com>
	<194f62550811220759t669a2fd5mf99cd53df1634a6e@mail.gmail.com>
	<49284B38.70707@sun.com>
	<17c6771e0811221731h5a4d75baocd5d7eb62ab48544@mail.gmail.com>
	<1ccfd1c10811221918o71fd40d8l8e6c995e98555448@mail.gmail.com>
	<17c6771e0811230041h421c08e4xb2ae07e6e287bcfd@mail.gmail.com>
Message-ID: <49299FFF.4040404@sun.com>



Andrew John Hughes wrote:
> On 23/11/2008, Martin Buchholz <martinrb at google.com> wrote:
>> On Sat, Nov 22, 2008 at 17:31, Andrew John Hughes
>>  <gnu_andrew at member.fsf.org> wrote:
>>
>>  > Well F10 is out on Tuesday so choosing F9 seems strange...
>>
>>
>> Andrew, you appear to live in a different world from the rest of us.
>>  Operating systems generally try to be backward compatible,
>>  so from my point of view using Fedora 9 seems offhand very aggressive.
>>  My rule of thumb was to build production binaries on the oldest
>>  systems you are willing to support.  What developers should use is
>>  a different story.
>>
> 
> Not really.  If you're saying you want the oldest system while still
> maintaining reasonably close to the majority of systems in general
> use, then yes I agree F9 is aggressive, as I'd like to know the build
> isn't going to be unknowingly broken in really bad ways on current
> Debian stable or RHEL 4/5, both of which are much older (though Debian
> stable will soon become a more recent release).
> 
>  I was reading it as where do we want to do test builds to ensure we
> catch the new issues that are going to arise.  Apparently there are
> already issues building with the new Ubuntu release due to a
> backported gcc 4.4 patch, but I haven't been able to verify this as I
> don't have software installed that is so bleeding edge ;)
> 
> I don't see why anyone other than developers or prospective developers
> would be building OpenJDK.  Actual users would find it much easier
> just using the package for their distro and you'll find one in Fedora,
> Ubuntu, Debian and (with some work) RHEL and Gentoo.
> 
>>  > But I don't get the point of this mail anyway.  OpenJDK already builds
>>  > fine on F9 and F10 for me.
>>
>>
>> It is of great interest to me.  In future, if my build is broken,
>>  I will first ask, "How is my system different from Fedora 9?".
>>
>>
> 
> Then should we be posting successful build testimonials here? Would
> that help? My own builds and blogs I've seen by others suggest builds
> on a variety of GNU/Linux platforms over and above just F9.
> 
>>  Martin
>>
> 

I would hope that all users would get the built OpenJDK from the distro,
that is definitely the right answer in my book.
That gets them the custom bits built for that system.
I would also hope that only developers (or the distro builders) would be
having to actually "build" OpenJDK7.

The Sun JDK has traditionally been built and tested on one Linux system,
then those built bits are installed and extreme tested (very detailed and
long running tests) on a set of Linux systems defined by the testing group
and the release support matrix. With each release of the Sun JDK we would
revisit this list and the selected build system (which impacts the support matrix).
The build systems would then be nailed down for each release, including every
bit on them.
It is that Sun JDK build system that has advanced to Fedora 9 for JDK7, and
consequently the list of Linux systems getting extreme testing will change too,
the details of that remain to be seen.

How does that impact OpenJDK7? As you say, not much, but it does
tell you that we will be hitting it hard with Fedora 9.
Does this risk the builds on other Linux systems any more than the current
antique Linux systems we are using? Probably not, but we really don't know.

If we had a rack of hardware or set of vmware images that contained every
possible Linux&gcc combination, I suppose we could constantly monitor all
OpenJDK builds... but some scary system administration thoughts are popping
into my head :^{

-kto


From gnu_andrew at member.fsf.org  Mon Nov 24 05:52:05 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 24 Nov 2008 05:52:05 +0000
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <1ccfd1c10811230941x2e777cb0x37b91344ad90ae63@mail.gmail.com>
References: <490938A9.9050201@sun.com>
	<194f62550811220759t669a2fd5mf99cd53df1634a6e@mail.gmail.com>
	<49284B38.70707@sun.com>
	<17c6771e0811221731h5a4d75baocd5d7eb62ab48544@mail.gmail.com>
	<1ccfd1c10811221918o71fd40d8l8e6c995e98555448@mail.gmail.com>
	<17c6771e0811230041h421c08e4xb2ae07e6e287bcfd@mail.gmail.com>
	<1ccfd1c10811230941x2e777cb0x37b91344ad90ae63@mail.gmail.com>
Message-ID: <17c6771e0811232152ha8bbc95mc75620f1ee0b01a2@mail.gmail.com>

On 23/11/2008, Martin Buchholz <martinrb at google.com> wrote:
> Andrew,
>
>  I think we still have a mismatch of expectations.
>  Sun has historically provided binaries as their primary deliverable,
>  and continues to operate the "business" side of JDK development
>  in that way.    The problem of building a binary distribution that
>  will run well on as many systems in actual use as possible is a
>  different (and probably, harder) problem than what distro
>  maintainers do, which is to always take source, never binaries,
>  from upstream, and build binaries designed only to ever run
>  on the same system they were built on.

I've never really looked at or been interested in the proprietary
binaries Sun provides for obvious reasons.  I can see binaries still
being needed for proprietary platforms that still gravitate towards
this distribution model (I don't think anyone else would want to build
on Windows for example and are happy Sun do) but for the GNU/Linux
distributions which we're talking about here, they are going to be
apply to provide a superior experience for the reasons you've
outlined.  Notably, ensuring security updates are performed is going
to be much easier and centralised.

BTW, are the OpenJDK builds Sun provides completely Free[1]?

 A packager at a
>  company might want to use Sun's approach, and build
>  one set of supported binaries that will work on a relatively
>  disparate set of target machines within the company.
>

Would they really need to build it themselves on each target rather
than using the supplied build?

>  Another way of looking at it - it's a (Sun) bug
>  if Sun-built Fedora 9 binaries fail to run well on Ubuntu dapper,
>  whereas I doubt that the Fedora community itself is aiming
>  for that kind of compatibility.
>

I doubt it.  I also doubt there's much worth in any JDK claims for the
resulting binaries if they are run on a different platform than that
on which they were tested.

>  Your suggestion of advertising test build successes is a good one.
>  For the record, I have been and will continue to build all releases
>  of openjdk6 and openjdk7 on Ubuntu dapper, and will attempt
>  to fix (or report) any failures doing so.
>

Thanks. FWIW, I've successfully built most build drops on Gentoo and
also succeeded in building on Debian stable and Fedora.

>  Martin
>
>  On Sun, Nov 23, 2008 at 00:41, Andrew John Hughes
>
> <gnu_andrew at member.fsf.org> wrote:
>
>
> > Then should we be posting successful build testimonials here? Would
>  > that help? My own builds and blogs I've seen by others suggest builds
>  > on a variety of GNU/Linux platforms over and above just F9.
>

[1] http://www.fsf.org/licensing/essays/free-sw.html
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Xiomara.Jayasena at Sun.COM  Mon Nov 24 07:15:15 2008
From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena)
Date: Sun, 23 Nov 2008 23:15:15 -0800
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <17c6771e0811221731h5a4d75baocd5d7eb62ab48544@mail.gmail.com>
References: <490938A9.9050201@sun.com>
	<194f62550811220759t669a2fd5mf99cd53df1634a6e@mail.gmail.com>
	<49284B38.70707@sun.com>
	<17c6771e0811221731h5a4d75baocd5d7eb62ab48544@mail.gmail.com>
Message-ID: <492A5483.7080502@sun.com>

Andrew John Hughes wrote:
> On 22/11/2008, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
>   
>> To clarify a little, yes this means gcc4, or whatever the default
>>  gcc/g++ on the Fedora 9 system is, if Fedora 9 changes it, we change too.
>>
>>  I would not read too much into the pick of Fedora 9, we needed to pick one
>>  that we could focus on, the important message is that we want to advance
>>  a newer Linux system. If a new Fedora releases we might even change to it,
>>  we want to be as flexible as possible.
>>
>>  Our hope is that the OpenJDK developers will use lots of different
>>  Linux systems and gcc compiler versions in their day-to-day development
>>  work, reporting any issues they run into.
>>
>>  I know there are lots of things we can do to improve the build situation,
>>  this one was considered a major first step.
>>
>>  -kto
>>
>>
>>  Clemens Eisserer wrote:
>>
>>     
>>> So JDK7 (the SUN builds) will be built with GCC-4.2.1 instead of the
>>>       
>> 3.2.1?
>>     
>>> Would be a really welcome change ;)
>>>
>>> Thx, Clemens
>>>
>>> 2008/10/30 Xiomara Jayasena <Xiomara.Jayasena at sun.com>:
>>>
>>>       
>>>> Hi,
>>>>
>>>> The official Release Engineering builds for JDK 7 will be moving from
>>>>         
>> the
>>     
>>>> following OSs:
>>>>
>>>> *32 bit builds*
>>>> ==========
>>>> *From: *RH AS 2.1 to Fedora 9
>>>>
>>>> *64 bit builds*
>>>> ==========
>>>> *From: *SUSE 8 to: Fedora 9
>>>>
>>>> All required Makefile changes are in place, there are still  other items
>>>> that are still being investigated for this OS upgrade to happen but
>>>>         
>> wanted
>>     
>>>> to inform of the changes that are on the way.
>>>> *When:*  It is expected that this change will happen by build 42.
>>>>
>>>> Please let me know if there are any questions.
>>>>
>>>> Thanks,
>>>> -Xiomara
>>>>
>>>>
>>>>
>>>>         
>
>
> Well F10 is out on Tuesday so choosing F9 seems strange...
>   

This change has been in the pipeline for sometime, so F9 was chosen. 

The builds may move up to F10 during the development lifetime of JDK 7.


-Xiomara



From aph at redhat.com  Mon Nov 24 11:05:52 2008
From: aph at redhat.com (Andrew Haley)
Date: Mon, 24 Nov 2008 11:05:52 +0000
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <1ccfd1c10811230941x2e777cb0x37b91344ad90ae63@mail.gmail.com>
References: <490938A9.9050201@sun.com>	<194f62550811220759t669a2fd5mf99cd53df1634a6e@mail.gmail.com>	<49284B38.70707@sun.com>	<17c6771e0811221731h5a4d75baocd5d7eb62ab48544@mail.gmail.com>	<1ccfd1c10811221918o71fd40d8l8e6c995e98555448@mail.gmail.com>	<17c6771e0811230041h421c08e4xb2ae07e6e287bcfd@mail.gmail.com>
	<1ccfd1c10811230941x2e777cb0x37b91344ad90ae63@mail.gmail.com>
Message-ID: <492A8A90.5030308@redhat.com>

Martin Buchholz wrote:

> Sun has historically provided binaries as their primary deliverable,
> and continues to operate the "business" side of JDK development in
> that way.  The problem of building a binary distribution that will
> run well on as many systems in actual use as possible is a different
> (and probably, harder) problem than what distro maintainers do,
> which is to always take source, never binaries, from upstream, and
> build binaries designed only to ever run on the same system they
> were built on.  A packager at a company might want to use Sun's
> approach, and build one set of supported binaries that will work on
> a relatively disparate set of target machines within the company.
>
> Another way of looking at it - it's a (Sun) bug if Sun-built Fedora
> 9 binaries fail to run well on Ubuntu dapper, whereas I doubt that
> the Fedora community itself is aiming for that kind of
> compatibility.

Indeed not.

Fedora 9 is a good choice.  The main issues when building OpenJDK on
newer GNU/Linux systems are to do with the C++ compiler, which has
changed very significantly since Red Hat AS 2.1 and SUSE 8.  In
particular, standard conformance is much closer and optimization more
aggressive.  Some previous releases of OpenJDK would not compile on
Fedora 9's compiler and contained bugs that would compile but would
fail in obscure ways.

I think you'll be fine: my only concern would be whether a (statically
linked) recent version of libstdc++ has any dependencies on a newer
libc.

Andrew.


From aph at redhat.com  Mon Nov 24 16:00:12 2008
From: aph at redhat.com (Andrew Haley)
Date: Mon, 24 Nov 2008 16:00:12 +0000
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <490938A9.9050201@sun.com>
References: <490938A9.9050201@sun.com>
Message-ID: <492ACF8C.9050109@redhat.com>

Xiomara Jayasena wrote:
> 
> Hi,
> 
> The official Release Engineering builds for JDK 7 will be moving from
> the following OSs:
> 
> *32 bit builds*
> ==========
> *From: *RH AS 2.1 to Fedora 9
> 
> *64 bit builds*
> ==========
> *From: *SUSE 8 to: Fedora 9
> 
> All required Makefile changes are in place, there are still  other items
> that are still being investigated for this OS upgrade to happen but
> wanted to inform of the changes that are on the way.
> *When:*  It is expected that this change will happen by build 42.
> 
> Please let me know if there are any questions.

We've had to fix a few compatibility bugs in IcedTea.  Do you want us to
send you the patches?

Andrew.


From Xiomara.Jayasena at Sun.COM  Mon Nov 24 16:45:53 2008
From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM)
Date: Mon, 24 Nov 2008 08:45:53 -0800
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <492ACF8C.9050109@redhat.com>
References: <490938A9.9050201@sun.com> <492ACF8C.9050109@redhat.com>
Message-ID: <492ADA41.2060804@Sun.COM>

On 11/24/08 08:00, Andrew Haley wrote:
> Xiomara Jayasena wrote:
>   
>> Hi,
>>
>> The official Release Engineering builds for JDK 7 will be moving from
>> the following OSs:
>>
>> *32 bit builds*
>> ==========
>> *From: *RH AS 2.1 to Fedora 9
>>
>> *64 bit builds*
>> ==========
>> *From: *SUSE 8 to: Fedora 9
>>
>> All required Makefile changes are in place, there are still  other items
>> that are still being investigated for this OS upgrade to happen but
>> wanted to inform of the changes that are on the way.
>> *When:*  It is expected that this change will happen by build 42.
>>
>> Please let me know if there are any questions.
>>     
>
> We've had to fix a few compatibility bugs in IcedTea.  Do you want us to
> send you the patches?
>   

Yes, please -- send me the patches.

Thanks,
-Xiomara

> Andrew.
>   



From aph at redhat.com  Mon Nov 24 18:17:56 2008
From: aph at redhat.com (Andrew Haley)
Date: Mon, 24 Nov 2008 18:17:56 +0000
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <492ADA41.2060804@Sun.COM>
References: <490938A9.9050201@sun.com> <492ACF8C.9050109@redhat.com>
	<492ADA41.2060804@Sun.COM>
Message-ID: <492AEFD4.6090706@redhat.com>

Xiomara.Jayasena at Sun.COM wrote:
> On 11/24/08 08:00, Andrew Haley wrote:
>> Xiomara Jayasena wrote:
>>  
>>> Hi,
>>>
>>> The official Release Engineering builds for JDK 7 will be moving from
>>> the following OSs:
>>>
>>> *32 bit builds*
>>> ==========
>>> *From: *RH AS 2.1 to Fedora 9
>>>
>>> *64 bit builds*
>>> ==========
>>> *From: *SUSE 8 to: Fedora 9
>>>
>>> All required Makefile changes are in place, there are still  other items
>>> that are still being investigated for this OS upgrade to happen but
>>> wanted to inform of the changes that are on the way.
>>> *When:*  It is expected that this change will happen by build 42.
>>>
>>> Please let me know if there are any questions.
>>>     
>>
>> We've had to fix a few compatibility bugs in IcedTea.  Do you want us to
>> send you the patches?
>>   
> 
> Yes, please -- send me the patches.

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.



From gnu_andrew at member.fsf.org  Tue Nov 25 05:19:45 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 25 Nov 2008 05:19:45 +0000
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <492AEFD4.6090706@redhat.com>
References: <490938A9.9050201@sun.com> <492ACF8C.9050109@redhat.com>
	<492ADA41.2060804@Sun.COM> <492AEFD4.6090706@redhat.com>
Message-ID: <17c6771e0811242119t23c17041u2534ecd99c10c126@mail.gmail.com>

On 24/11/2008, Andrew Haley <aph at redhat.com> wrote:
> Xiomara.Jayasena at Sun.COM wrote:
>  > On 11/24/08 08:00, Andrew Haley wrote:
>  >> Xiomara Jayasena wrote:
>  >>
>  >>> Hi,
>  >>>
>  >>> The official Release Engineering builds for JDK 7 will be moving from
>  >>> the following OSs:
>  >>>
>  >>> *32 bit builds*
>  >>> ==========
>  >>> *From: *RH AS 2.1 to Fedora 9
>  >>>
>  >>> *64 bit builds*
>  >>> ==========
>  >>> *From: *SUSE 8 to: Fedora 9
>  >>>
>  >>> All required Makefile changes are in place, there are still  other items
>  >>> that are still being investigated for this OS upgrade to happen but
>  >>> wanted to inform of the changes that are on the way.
>  >>> *When:*  It is expected that this change will happen by build 42.
>  >>>
>  >>> Please let me know if there are any questions.
>  >>>
>  >>
>  >> We've had to fix a few compatibility bugs in IcedTea.  Do you want us to
>  >> send you the patches?
>  >>
>  >
>  > Yes, please -- send me the patches.
>
>
> 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.
>
>

Note that, according to the ChangeLog, icedtea-no-bcopy.patch and
icedtea-hotspot-citypeflow.patch were contributed by Matthias Klose
(doko) who doesn't have an SCA in place.  The rest are from Red Hat.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Xiomara.Jayasena at Sun.COM  Tue Nov 25 05:34:48 2008
From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena)
Date: Mon, 24 Nov 2008 21:34:48 -0800
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <17c6771e0811242119t23c17041u2534ecd99c10c126@mail.gmail.com>
References: <490938A9.9050201@sun.com> <492ACF8C.9050109@redhat.com>
	<492ADA41.2060804@Sun.COM> <492AEFD4.6090706@redhat.com>
	<17c6771e0811242119t23c17041u2534ecd99c10c126@mail.gmail.com>
Message-ID: <492B8E78.7010608@sun.com>

Andrew John Hughes wrote:
> On 24/11/2008, Andrew Haley <aph at redhat.com> wrote:
>   
>> Xiomara.Jayasena at Sun.COM wrote:
>>  > On 11/24/08 08:00, Andrew Haley wrote:
>>  >> Xiomara Jayasena wrote:
>>  >>
>>  >>> Hi,
>>  >>>
>>  >>> The official Release Engineering builds for JDK 7 will be moving from
>>  >>> the following OSs:
>>  >>>
>>  >>> *32 bit builds*
>>  >>> ==========
>>  >>> *From: *RH AS 2.1 to Fedora 9
>>  >>>
>>  >>> *64 bit builds*
>>  >>> ==========
>>  >>> *From: *SUSE 8 to: Fedora 9
>>  >>>
>>  >>> All required Makefile changes are in place, there are still  other items
>>  >>> that are still being investigated for this OS upgrade to happen but
>>  >>> wanted to inform of the changes that are on the way.
>>  >>> *When:*  It is expected that this change will happen by build 42.
>>  >>>
>>  >>> Please let me know if there are any questions.
>>  >>>
>>  >>
>>  >> We've had to fix a few compatibility bugs in IcedTea.  Do you want us to
>>  >> send you the patches?
>>  >>
>>  >
>>  > Yes, please -- send me the patches.
>>
>>
>> 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.
>>
>>
>>     
>
> Note that, according to the ChangeLog, icedtea-no-bcopy.patch and
> icedtea-hotspot-citypeflow.patch were contributed by Matthias Klose
> (doko) who doesn't have an SCA in place.  The rest are from Red Hat.
>   

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




From martinrb at google.com  Tue Nov 25 06:07:33 2008
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 24 Nov 2008 22:07:33 -0800
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <17c6771e0811242119t23c17041u2534ecd99c10c126@mail.gmail.com>
References: <490938A9.9050201@sun.com> <492ACF8C.9050109@redhat.com>
	<492ADA41.2060804@Sun.COM> <492AEFD4.6090706@redhat.com>
	<17c6771e0811242119t23c17041u2534ecd99c10c126@mail.gmail.com>
Message-ID: <1ccfd1c10811242207p28cf7108h121a15b9adb38f6@mail.gmail.com>

On Mon, Nov 24, 2008 at 21:19, Andrew John Hughes
<gnu_andrew at member.fsf.org> wrote:

> Note that, according to the ChangeLog, icedtea-no-bcopy.patch and
> icedtea-hotspot-citypeflow.patch were contributed by Matthias Klose
> (doko) who doesn't have an SCA in place.  The rest are from Red Hat.

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


From Xiomara.Jayasena at Sun.COM  Tue Nov 25 06:27:44 2008
From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena)
Date: Mon, 24 Nov 2008 22:27:44 -0800
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <1ccfd1c10811242207p28cf7108h121a15b9adb38f6@mail.gmail.com>
References: <490938A9.9050201@sun.com> <492ACF8C.9050109@redhat.com>
	<492ADA41.2060804@Sun.COM> <492AEFD4.6090706@redhat.com>
	<17c6771e0811242119t23c17041u2534ecd99c10c126@mail.gmail.com>
	<1ccfd1c10811242207p28cf7108h121a15b9adb38f6@mail.gmail.com>
Message-ID: <492B9AE0.80404@sun.com>

Martin Buchholz wrote:
> On Mon, Nov 24, 2008 at 21:19, Andrew John Hughes
> <gnu_andrew at member.fsf.org> wrote:
>
>   
>> Note that, according to the ChangeLog, icedtea-no-bcopy.patch and
>> icedtea-hotspot-citypeflow.patch were contributed by Matthias Klose
>> (doko) who doesn't have an SCA in place.  The rest are from Red Hat.
>>     
>
> The citypeflow patch is already in openjdk.
>   

Thanks for the clarification, Martin. 

-Xiomara

> There were several variations on this very small patch,
> but the one in openjdk is the one authored by Google.
>
> Martin
>   



From aph at redhat.com  Tue Nov 25 09:52:47 2008
From: aph at redhat.com (Andrew Haley)
Date: Tue, 25 Nov 2008 09:52:47 +0000
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <17c6771e0811242119t23c17041u2534ecd99c10c126@mail.gmail.com>
References: <490938A9.9050201@sun.com> <492ACF8C.9050109@redhat.com>	
	<492ADA41.2060804@Sun.COM> <492AEFD4.6090706@redhat.com>
	<17c6771e0811242119t23c17041u2534ecd99c10c126@mail.gmail.com>
Message-ID: <492BCAEF.4040603@redhat.com>

Andrew John Hughes wrote:
> On 24/11/2008, Andrew Haley <aph at redhat.com> wrote:
>> Xiomara.Jayasena at Sun.COM wrote:
>>  > On 11/24/08 08:00, Andrew Haley wrote:
>>  >> Xiomara Jayasena wrote:
>>  >>
>>  >>> Hi,
>>  >>>
>>  >>> The official Release Engineering builds for JDK 7 will be moving from
>>  >>> the following OSs:
>>  >>>
>>  >>> *32 bit builds*
>>  >>> ==========
>>  >>> *From: *RH AS 2.1 to Fedora 9
>>  >>>
>>  >>> *64 bit builds*
>>  >>> ==========
>>  >>> *From: *SUSE 8 to: Fedora 9
>>  >>>
>>  >>> All required Makefile changes are in place, there are still  other items
>>  >>> that are still being investigated for this OS upgrade to happen but
>>  >>> wanted to inform of the changes that are on the way.
>>  >>> *When:*  It is expected that this change will happen by build 42.
>>  >>>
>>  >>> Please let me know if there are any questions.
>>  >>>
>>  >>
>>  >> We've had to fix a few compatibility bugs in IcedTea.  Do you want us to
>>  >> send you the patches?
>>  >>
>>  >
>>  > Yes, please -- send me the patches.
>>
>>
>> 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.

> Note that, according to the ChangeLog, icedtea-no-bcopy.patch and
> icedtea-hotspot-citypeflow.patch were contributed by Matthias Klose
> (doko) who doesn't have an SCA in place.  The rest are from Red Hat.

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.


From gnu_andrew at member.fsf.org  Wed Nov 26 06:06:06 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 26 Nov 2008 06:06:06 +0000
Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9
In-Reply-To: <492BCAEF.4040603@redhat.com>
References: <490938A9.9050201@sun.com> <492ACF8C.9050109@redhat.com>
	<492ADA41.2060804@Sun.COM> <492AEFD4.6090706@redhat.com>
	<17c6771e0811242119t23c17041u2534ecd99c10c126@mail.gmail.com>
	<492BCAEF.4040603@redhat.com>
Message-ID: <17c6771e0811252206o3fff4e7le13153b8fae805c4@mail.gmail.com>

2008/11/25 Andrew Haley <aph at redhat.com>:
> Andrew John Hughes wrote:
>> On 24/11/2008, Andrew Haley <aph at redhat.com> wrote:
>>> Xiomara.Jayasena at Sun.COM wrote:
>>>  > On 11/24/08 08:00, Andrew Haley wrote:
>>>  >> Xiomara Jayasena wrote:
>>>  >>
>>>  >>> Hi,
>>>  >>>
>>>  >>> The official Release Engineering builds for JDK 7 will be moving from
>>>  >>> the following OSs:
>>>  >>>
>>>  >>> *32 bit builds*
>>>  >>> ==========
>>>  >>> *From: *RH AS 2.1 to Fedora 9
>>>  >>>
>>>  >>> *64 bit builds*
>>>  >>> ==========
>>>  >>> *From: *SUSE 8 to: Fedora 9
>>>  >>>
>>>  >>> All required Makefile changes are in place, there are still  other items
>>>  >>> that are still being investigated for this OS upgrade to happen but
>>>  >>> wanted to inform of the changes that are on the way.
>>>  >>> *When:*  It is expected that this change will happen by build 42.
>>>  >>>
>>>  >>> Please let me know if there are any questions.
>>>  >>>
>>>  >>
>>>  >> We've had to fix a few compatibility bugs in IcedTea.  Do you want us to
>>>  >> send you the patches?
>>>  >>
>>>  >
>>>  > Yes, please -- send me the patches.
>>>
>>>
>>> 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.
>
>> Note that, according to the ChangeLog, icedtea-no-bcopy.patch and
>> icedtea-hotspot-citypeflow.patch were contributed by Matthias Klose
>> (doko) who doesn't have an SCA in place.  The rest are from Red Hat.
>
> 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.
>

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.
>From the original e-mail, it might have been assumed that they were
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.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From pdoubleya at gmail.com  Thu Nov 27 21:24:27 2008
From: pdoubleya at gmail.com (Patrick Wright)
Date: Thu, 27 Nov 2008 22:24:27 +0100
Subject: Java binary, can't redirect stderr on VM crash
Message-ID: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>

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
>/tmp/err.txt

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


From Tim.Bell at Sun.COM  Thu Nov 27 21:59:29 2008
From: Tim.Bell at Sun.COM (Tim Bell)
Date: Thu, 27 Nov 2008 13:59:29 -0800
Subject: Java binary, can't redirect stderr on VM crash
In-Reply-To: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
References: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
Message-ID: <492F1841.6030200@sun.com>

Patrick:

> 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.

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.

> 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]

Looks as if this output is coming from down inside the free() implementation
in the libc library on the native platform.

   :
   :

> 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_.

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


From Christopher.Hegarty at Sun.COM  Thu Nov 27 22:11:06 2008
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems)
Date: Thu, 27 Nov 2008 22:11:06 +0000
Subject: Java binary, can't redirect stderr on VM crash
In-Reply-To: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
References: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
Message-ID: <492F1AFA.9060002@sun.com>

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:
> 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
>> /tmp/err.txt
> 
> 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


From mark at klomp.org  Thu Nov 27 22:04:16 2008
From: mark at klomp.org (Mark Wielaard)
Date: Thu, 27 Nov 2008 23:04:16 +0100
Subject: Java binary, can't redirect stderr on VM crash
In-Reply-To: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
References: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
Message-ID: <1227823456.29153.19.camel@hermans.wildebeest.org>

Hi Patrick,

On Thu, 2008-11-27 at 22:24 +0100, Patrick Wright wrote:
> 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]

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.

> 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
> >/tmp/err.txt
> 
> 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_.

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



From pdoubleya at gmail.com  Thu Nov 27 22:19:39 2008
From: pdoubleya at gmail.com (Patrick Wright)
Date: Thu, 27 Nov 2008 23:19:39 +0100
Subject: Java binary, can't redirect stderr on VM crash
In-Reply-To: <492F1841.6030200@sun.com>
References: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
	<492F1841.6030200@sun.com>
Message-ID: <64efa1ba0811271419x7a36d583n4b2620f48228278d@mail.gmail.com>

Hi Tim

Thanks for the reply.

> Is this test program ("RenderFontTest") something you could share with
> the list?  Also, what font(s) are you testing when the crash happens?

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.


> With this information we can try the testing on other platforms and
> throw additional troubleshooting resources such as libumem on Solaris
> at the problem.

That would be great. It's painstaking work given the nature of the problem.

> Looks as if this output is coming from down inside the free() implementation
> in the libc library on the native platform.

OK

>  java -cp out/production/Samples RenderFontTest "AR PL UMing CN" >
> /tmp/err.txt 2>&1

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;
    }
}
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fontlist.txt
URL: <http://mail.openjdk.java.net/pipermail/discuss/attachments/20081127/5e996cfa/fontlist.txt>

From pdoubleya at gmail.com  Thu Nov 27 22:21:15 2008
From: pdoubleya at gmail.com (Patrick Wright)
Date: Thu, 27 Nov 2008 23:21:15 +0100
Subject: Java binary, can't redirect stderr on VM crash
In-Reply-To: <492F1AFA.9060002@sun.com>
References: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
	<492F1AFA.9060002@sun.com>
Message-ID: <64efa1ba0811271421j22f0c152i19a66a32b4ea4211@mail.gmail.com>

Hi Chris

> 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

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


From pdoubleya at gmail.com  Thu Nov 27 22:26:04 2008
From: pdoubleya at gmail.com (Patrick Wright)
Date: Thu, 27 Nov 2008 23:26:04 +0100
Subject: Java binary, can't redirect stderr on VM crash
In-Reply-To: <1227823456.29153.19.camel@hermans.wildebeest.org>
References: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
	<1227823456.29153.19.camel@hermans.wildebeest.org>
Message-ID: <64efa1ba0811271426i11a7fa59r871f153a076dcfc5@mail.gmail.com>

Hi Mark


> 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.

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.

> And probably also in a hs_err_pid[0-9].log file in your working
> directory.

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!

> If you could post the RenderFontTest.java file then I could try to
> replicate locally if you want.

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


From mark at klomp.org  Fri Nov 28 11:33:40 2008
From: mark at klomp.org (Mark Wielaard)
Date: Fri, 28 Nov 2008 12:33:40 +0100
Subject: Java binary, can't redirect stderr on VM crash
In-Reply-To: <64efa1ba0811271426i11a7fa59r871f153a076dcfc5@mail.gmail.com>
References: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
	<1227823456.29153.19.camel@hermans.wildebeest.org>
	<64efa1ba0811271426i11a7fa59r871f153a076dcfc5@mail.gmail.com>
Message-ID: <1227872020.3333.69.camel@dijkstra.wildebeest.org>

Hi Patrick,

On Thu, 2008-11-27 at 23:26 +0100, Patrick Wright wrote:
> > If you could post the RenderFontTest.java file then I could try to
> > replicate locally if you want.
> 
> 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.

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=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x0082c028 in abort () at abort.c:88
#3  0x0086764d in __libc_message (do_abort=<value optimized out>, 
    fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:170
#4  0x0086d874 in malloc_printerr (action=<value optimized out>, 
    str=<value optimized out>, ptr=<value optimized out>) at malloc.c:5949
#5  0x0086f8d6 in __libc_free (mem=<value optimized out>) 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=<value optimized out>, 
    max=1, script=33, lang=-1, typo_flags=0, pt=0x164ae8, gvdata=0x164ae4, 
    upem=<value optimized out>, layoutTables=<value optimized out>)
    at ../../../src/share/native/sun/font/layout/SunLayoutEngine.cpp:217

This was with "AR PL UKai CN".

Cheers,

Mark



From pdoubleya at gmail.com  Fri Nov 28 11:35:40 2008
From: pdoubleya at gmail.com (Patrick Wright)
Date: Fri, 28 Nov 2008 12:35:40 +0100
Subject: Java binary, can't redirect stderr on VM crash
In-Reply-To: <1227872020.3333.69.camel@dijkstra.wildebeest.org>
References: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
	<1227823456.29153.19.camel@hermans.wildebeest.org>
	<64efa1ba0811271426i11a7fa59r871f153a076dcfc5@mail.gmail.com>
	<1227872020.3333.69.camel@dijkstra.wildebeest.org>
Message-ID: <64efa1ba0811280335g903a7e1ra426a334770c9cc@mail.gmail.com>

Hi Mark

> 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.

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


From Igor.Nekrestyanov at Sun.COM  Fri Nov 28 11:35:13 2008
From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov)
Date: Fri, 28 Nov 2008 14:35:13 +0300
Subject: Java binary, can't redirect stderr on VM crash
In-Reply-To: <1227872020.3333.69.camel@dijkstra.wildebeest.org>
References: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
	<1227823456.29153.19.camel@hermans.wildebeest.org>
	<64efa1ba0811271426i11a7fa59r871f153a076dcfc5@mail.gmail.com>
	<1227872020.3333.69.camel@dijkstra.wildebeest.org>
Message-ID: <492FD771.9090500@sun.com>

Mark,

Could you send me copy of the font file?

-igor

Mark Wielaard wrote:
> Hi Patrick,
>
> On Thu, 2008-11-27 at 23:26 +0100, Patrick Wright wrote:
>   
>>> If you could post the RenderFontTest.java file then I could try to
>>> replicate locally if you want.
>>>       
>> 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.
>>     
>
> 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=<value optimized out>)
>     at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #2  0x0082c028 in abort () at abort.c:88
> #3  0x0086764d in __libc_message (do_abort=<value optimized out>, 
>     fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:170
> #4  0x0086d874 in malloc_printerr (action=<value optimized out>, 
>     str=<value optimized out>, ptr=<value optimized out>) at malloc.c:5949
> #5  0x0086f8d6 in __libc_free (mem=<value optimized out>) 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=<value optimized out>, 
>     max=1, script=33, lang=-1, typo_flags=0, pt=0x164ae8, gvdata=0x164ae4, 
>     upem=<value optimized out>, layoutTables=<value optimized out>)
>     at ../../../src/share/native/sun/font/layout/SunLayoutEngine.cpp:217
>
> This was with "AR PL UKai CN".
>
> Cheers,
>
> Mark
>
>   



From mark at klomp.org  Fri Nov 28 12:11:38 2008
From: mark at klomp.org (Mark Wielaard)
Date: Fri, 28 Nov 2008 13:11:38 +0100
Subject: Java binary, can't redirect stderr on VM crash
In-Reply-To: <492FD771.9090500@sun.com>
References: <64efa1ba0811271324v23186e26vb95ecb0f74037df0@mail.gmail.com>
	<1227823456.29153.19.camel@hermans.wildebeest.org>
	<64efa1ba0811271426i11a7fa59r871f153a076dcfc5@mail.gmail.com>
	<1227872020.3333.69.camel@dijkstra.wildebeest.org>
	<492FD771.9090500@sun.com>
Message-ID: <1227874298.3333.85.camel@dijkstra.wildebeest.org>

Hi Igor,

On Fri, 2008-11-28 at 14:35 +0300, Igor Nekrestyanov wrote:
> Could you send me copy of the font file?

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