You can file it as follows:
Product: jct_tools
Category: jct_tools
Subcategory: regtest
and for a good measure add jon to the interest list.
Kumar
David,
I'm not sure where we can file bugs on jtreg, probably have to wait
for Jon to come back on line and drop him a mail.
This is even wors
David,
I'm not sure where we can file bugs on jtreg, probably have to wait for
Jon to come back on line and drop him a mail.
This is even worse that I originally though. Any thread that throws an
unchecked exception followed by another thread starting a thread ( or
invoking any operation on
So the jtreg uncaughtException code is doing a join() on the target
Thread while holding the monitor lock of the ThreadGroup - ouch! Where
do we file jtreg bugs?
David
On 11/10/2011 1:44 AM, Chris Hegarty wrote:
On 10/10/2011 15:52, Alan Bateman wrote:
Chris Hegarty wrote:
Naoto,
Forgot to
Thanks, Chris. Will do it after confirming all's well with the JPRT
(currently it's down).
Naoto
On 10/10/11 7:27 AM, Chris Hegarty wrote:
Naoto,
Forgot to add, you can probably just push the changes for the test along
with your source changes. I modified it a little since last review.
Reprod
On 10/10/2011 15:52, Alan Bateman wrote:
Chris Hegarty wrote:
Naoto,
Forgot to add, you can probably just push the changes for the test
along with your source changes. I modified it a little since last
review. Reproduces one in about every ten times on one of our Dual
core Linux x64 boxes.
Is
Chris Hegarty wrote:
Naoto,
Forgot to add, you can probably just push the changes for the test
along with your source changes. I modified it a little since last
review. Reproduces one in about every ten times on one of our Dual
core Linux x64 boxes.
Is it the CME that duplicates for you? I'm
Naoto,
Forgot to add, you can probably just push the changes for the test along
with your source changes. I modified it a little since last review.
Reproduces one in about every ten times on one of our Dual core Linux
x64 boxes.
>: hg diff Bug6989440.java
diff -r 1e89a13d9d8f test/java/util
Thumbs up from me too.
-Chris.
On 10/10/2011 05:44, David Holmes wrote:
On 10/10/2011 1:35 PM, Naoto Sato wrote:
Hi David,
Thank you for your review. availableJRELocales is already declared with
volatile keyword in the current source, so no change is involved.
Sorry - my mistake. I misread
On 10/10/2011 1:35 PM, Naoto Sato wrote:
Hi David,
Thank you for your review. availableJRELocales is already declared with
volatile keyword in the current source, so no change is involved.
Sorry - my mistake. I misread something Chris posted earlier.
Cheers,
David
Naoto
On 10/9/11 6:22 PM,
Hi David,
Thank you for your review. availableJRELocales is already declared with
volatile keyword in the current source, so no change is involved.
Naoto
On 10/9/11 6:22 PM, David Holmes wrote:
Hi Naoto,
This looks okay to me, but is missing the change to make
availableJRELocales volatile (
Hi Naoto,
This looks okay to me, but is missing the change to make
availableJRELocales volatile (which is needed to ensure safe publication)
David
On 8/10/2011 4:40 AM, Naoto Sato wrote:
OK here is the proposed fix (including David's suggestion for using
putIfAbsent). Can anyone please revie
Thanks of all of you.
This problem was introduced by the contribution from ICU project, and
I'm responsible to the specific code.
-Yoshito
On 10/6/2011 5:59 PM, Naoto Sato wrote:
Hi David,
Thank you for the quick look and the fix!
Naoto
On 10/6/11 10:09 AM, David Holmes wrote:
Hi Chris,
OK here is the proposed fix (including David's suggestion for using
putIfAbsent). Can anyone please review this?
--- a/src/share/classes/sun/util/LocaleServiceProviderPool.java
+++ b/src/share/classes/sun/util/LocaleServiceProviderPool.java
@@ -40,6 +40,7 @@
import java.util.ServiceLoader;
imp
Hi David,
Thank you for the quick look and the fix!
Naoto
On 10/6/11 10:09 AM, David Holmes wrote:
Hi Chris,
Thanks. Here's the bug:
private List getJRELocales() {
if (availableJRELocales == null) {
synchronized (LocaleServiceProviderPool.class) {
if (availableJRELocales == null) {
Locale[]
D'oh! I should have seen this. Thanks David
-Chris
David Holmes wrote:
>Hi Chris,
>
>Thanks. Here's the bug:
>
>private List getJRELocales() {
> if (availableJRELocales == null) {
> synchronized (LocaleServiceProviderPool.class) {
> if (availableJRELocale
Hi Chris,
Thanks. Here's the bug:
private List getJRELocales() {
if (availableJRELocales == null) {
synchronized (LocaleServiceProviderPool.class) {
if (availableJRELocales == null) {
Locale[] allLocales = LocaleData.getAvailableLocales(
David,
Expanding (more threads and more runs) and running this test on one of
our dual core Linux x64 boxes, reproduce the CME about one in every ten
runs.
I instrumented where the CME was being created to determine the
expected/actual modcount:
final void checkForComodification() {
This might not be related to the CME problem, but here:
public static LocaleServiceProviderPool getPool(ClassLocaleServiceProvider> providerClass) {
LocaleServiceProviderPool pool = poolOfPools.get(providerClass);
if (pool == null) {
LocaleServiceProviderPool newP
On 6/10/2011 2:58 AM, Alan Bateman wrote:
Chris Hegarty wrote:
Alan, Naoto, David
I filed CR 7098100: java/util/Locale/Bug6989440.java fails
intermittently.
If you're ok with it please review the patch (below) and I can push it
to the tl repo. Job done!
I assume there is also some underlying
I will look into this. Reopened the original CR.
Naoto
On 10/5/11 9:58 AM, Alan Bateman wrote:
Chris Hegarty wrote:
Alan, Naoto, David
I filed CR 7098100: java/util/Locale/Bug6989440.java fails
intermittently.
If you're ok with it please review the patch (below) and I can push it
to the tl r
Chris Hegarty wrote:
Alan, Naoto, David
I filed CR 7098100: java/util/Locale/Bug6989440.java fails
intermittently.
If you're ok with it please review the patch (below) and I can push it
to the tl repo. Job done!
I assume there is also some underlying issue in the Locale code and this
might
Looks good to me. Thanks!
Naoto
On 10/5/11 8:42 AM, Chris Hegarty wrote:
Alan, Naoto, David
I filed CR 7098100: java/util/Locale/Bug6989440.java fails intermittently.
If you're ok with it please review the patch (below) and I can push it
to the tl repo. Job done!
>: hg diff test/java/util/L
Alan, Naoto, David
I filed CR 7098100: java/util/Locale/Bug6989440.java fails intermittently.
If you're ok with it please review the patch (below) and I can push it
to the tl repo. Job done!
>: hg diff test/java/util/Locale/Bug6989440.java
diff -r 24741fe639a8 test/java/util/Locale/Bug6989440
Hi Chris,
I appreciate it, and will fix the test case.
Naoto
On 10/5/11 7:07 AM, Chris Hegarty wrote:
Alan, David,
I noticed CR 7027061 was closed as 'not a defect'. Should I file a new
CR to have the jtreg test fixed (join on all created threads)? The test
will still exercise what it is supp
Alan, David,
I noticed CR 7027061 was closed as 'not a defect'. Should I file a new
CR to have the jtreg test fixed (join on all created threads)? The test
will still exercise what it is supposed to, and the
ConcurrentModificationException issue can be investigated at another
time. This way w
Thanks Chris and Alan.
On 4/10/2011 11:24 PM, Alan Bateman wrote:
Chris Hegarty wrote:
Trivially, should the main thread in the test be waiting on the three
other threads to complete before exiting?
I think jtreg will try to cleanup once the main thread completes. The
main thread should keep a
off-list recently about
the same issue (same test, same failure mode). I've cc'ed the i18n
folks
in case they recognize it. My guess is that this is an implementation
bug in LocaleServiceProviderPool rather than a test bug.
-Alan.
Kelly O'Hair wrote:
Anyone s
Chris Hegarty wrote:
Trivially, should the main thread in the test be waiting on the three
other threads to complete before exiting?
I think jtreg will try to cleanup once the main thread completes. The
main thread should keep an array of the threads it creates and invoke
join() on each of th
x27;ed the i18n folks
in case they recognize it. My guess is that this is an implementation
bug in LocaleServiceProviderPool rather than a test bug.
-Alan.
Kelly O'Hair wrote:
Anyone seen this testcase failure before?
-kto
--
TEST: java/uti
ode). I've cc'ed the i18n folks
>>> in case they recognize it. My guess is that this is an implementation
>>> bug in LocaleServiceProviderPool rather than a test bug.
>>>
>>> -Alan.
>>>
>>> Kelly O'Hair wrote:
>>>> Anyone seen this test
ut Olivier Lagneau asked me off-list recently about
the same issue (same test, same failure mode). I've cc'ed the i18n folks
in case they recognize it. My guess is that this is an implementation
bug in LocaleServiceProviderPool rather than a test bug.
-Alan.
Kelly O'Hair wrote:
Anyone s
ssue (same test, same failure mode). I've cc'ed the i18n folks
in case they recognize it. My guess is that this is an implementation
bug in LocaleServiceProviderPool rather than a test bug.
-Alan.
Kelly O'Hair wrote:
Anyone seen this testc
.
Kelly O'Hair wrote:
Anyone seen this testcase failure before?
-kto
--
TEST: java/util/Locale/Bug6989440.java
JDK under test:
(/tmp/jprt/P1/001456.jprtadm/testproduct/solaris_i586_5.10-product)
openjdk version "1.8.0-internal"
Open
33 matches
Mail list logo
