Hi Shai,

 

just install J9 and the run *all* core tests in a loop, ideally with 
“-Dtests.jvms=1”. It is important to run *all* tests, because it does not 
happen on a single test case alone.

In fact, it could be that some recent changes in FSTs may have worked around 
that issue. I testes the last time approx. half a year ago when I installed the 
last J9 update. Maybe search for occurrences in the mailing list archive. I 
actually ran Jenkins a few days without the disabled optimization and failures 
happened quite often.

 

In addition to the TAR.GZ issue: What the status about the full encryption 
support? Why does Oracle offers downloads with full encryption support (we need 
that for Lucene), but J9 has to be patched first? With unpatched policy files 
you cannot even run the build at all, because it already fails while trying to 
connect to issues.apache.org with SSL/TLS or some of the Maven repositories 
with https:// URLs. It looks like J9 only supports 1024 bits certificates, 
which are no longer used and got replaced by most providers recently (so 
affecting Maven and issues.apache.org).

 

Unfortunately I have no time to test J9 locally at the moment, sorry.

 

Uwe

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: [email protected]

 

From: Shai Erera [mailto:[email protected]] 
Sent: Wednesday, February 04, 2015 2:16 PM
To: [email protected]
Subject: Re: FST.pack() J9 bug

 

Thanks guys, I understand and I recently raised this issue again w/ the J9 
team. I am told that the TAR.GZ is probably not an option, for legal reasons 
which I do not understand. I am taking it one step at a time, and currently 
they would like to investigate this FST.pack() issue since it can lead to index 
corruption, and this is not acceptable.

I also asked them to figure out a process which would allow us (the community) 
to file bug reports and have them work with us on these issues. I hope they 
will be able to figure out such a process. I will update the list when such 
process will be in place.

Back to the FST.pack(), from what Uwe says it seems it reproduces very easily 
(he tries new J9 versions, they fail and he disables the optimization). If so, 
does someone have an example such failure which I can ask them to reproduce?

Shai

 

On Wed, Feb 4, 2015 at 12:20 PM, Dawid Weiss <[email protected]> 
wrote:

I agree with Uwe -- even trying to get J9 (on Windows, for example)
used to be a headache. Not to mention there is no clear channel to
report bugs to (and receive feedback from)... it makes testing on J9 a
burden. Some kind of (official or semi-official) help from IBM to get
this rolling more smoothly would be great.

Dawid


On Wed, Feb 4, 2015 at 11:12 AM, Uwe Schindler <[email protected]> wrote:
> Hi Shai,
>
>
>
> the current Jenkins disables the optimization, with the listed flag.
> Whenever I update the version, I check if the bug still happens. And it
> still happens at least with the version currently installed.
>
>
>
> serv1:/var/lib/jenkins/tools/java/64bit/ibm-j9-jdk7# bin/java -version
>
> java version "1.7.0"
>
> Java(TM) SE Runtime Environment (build pxa6470_27sr1-20140411_01(SR1))
>
> IBM J9 VM (build 2.7, JRE 1.7.0 Linux amd64-64 Compressed References
> 20140410_195893 (JIT enabled, AOT enabled)
>
> J9VM - R27_Java727_SR1_20140410_1931_B195893
>
> JIT  - tr.r13.java_20140410_61421
>
> GC   - R27_Java727_SR1_20140410_1931_B195893_CMPRSS
>
> J9CL - 20140410_195893)
>
> JCL - 20140409_01 based on Oracle 7u55-b13
>
>
>
> I have not yet updated to last J9 version, but the reason for this is the
> brokenness of the installation (InstallShield in a console, haha). If IBM
> would provide a simple TAR.GZ file and also a version with the “extended
> encryption java policy files”, I would do this more often. But currently
> this costs me half an hour per platform to install this and it is all
> voluntary!
>
>
>
> In addition there is no IBM J9 for Java 8, so we don’t run TRUNK tests
> anymore with J9 (requires Java 8).
>
>
>
> See my other message about this a while back on this mailing list.
>
> Uwe
>
>
>
> -----
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: [email protected]
>
>
>
> From: Shai Erera [mailto:[email protected]]
> Sent: Wednesday, February 04, 2015 11:02 AM
> To: [email protected]
> Subject: FST.pack() J9 bug
>
>
>
> Hi
>
> I was asked by someone in IBM about this bug which is listed under our
> JavaBugs page:
>
> FST.pack() produces corrupt index (Lucene 4) because a loop is miscompiled
>
> The J9 team would like to investigate that and they I've asked me for some
> more details. Since we don't have an issue reported, I searched and came up
> with several links:
>
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201404.mbox/%3Calpine.DEB.2.02.1404031005110.14297@frisbee%3E
> http://marc.info/?l=solr-dev <http://marc.info/?l=solr-dev&m=134454323703970> 
> &m=134454323703970
>
> Since the Wiki page describes a work around to disable JIT optimization for
> FST.pack(), I wanted to ask:
>
> Are our Jenkins builds with J9 disable this optimization currently?
> Do we know if this bug still happens?
> Is there a test which can reproduce the bug (even if it doesn't always
> reproduce it) so the J9 folks can debug?
> I am not sure if the tests in the above link are still relevant or were good
> at reproducing the bug.
>
> If it's not easily reproducible, is there additional information besides
> what's written on the Wiki page that you think can help them investigate
> this?
>
> Shai

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

 

Reply via email to