commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)
Date Wed, 09 Aug 2017 23:55:24 GMT
On Thu, 10 Aug 2017 01:48:48 +0200, Gilles wrote:
> On Thu, 10 Aug 2017 00:30:59 +0100, sebb wrote:
>> On 10 August 2017 at 00:08, Gilles <gilles@harfang.homelinux.org> 
>> wrote:
>>> On Wed, 9 Aug 2017 23:48:30 +0100, sebb wrote:
>>>>
>>>> On 9 August 2017 at 23:19, Gilles <gilles@harfang.homelinux.org> 
>>>> wrote:
>>>>>
>>>>> On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:
>>>>>>
>>>>>>
>>>>>> On 9 August 2017 at 13:51, Gilles <gilles@harfang.homelinux.org>

>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>> Build with Java 8 runs fine:
>>>>>>>   https://travis-ci.org/apache/commons-math/jobs/262647212
>>>>>>>
>>>>>>> But with Java 7:
>>>>>>>   https://travis-ci.org/apache/commons-math/jobs/262647211
>>>>>>>
>>>>>>> Is anyone willing to debug this failure?
>>>>>>
>>>>>>
>>>>>>
>>>>>> 1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it 
>>>>>> cannot
>>>>>> find the current git info
>>>>>
>>>>>
>>>>>
>>>>> That's not what makes the build fail since it happens in both.
>>>>>
>>>>>> 2) Bug in JVM - buffer overflow.
>>>>>
>>>>>
>>>>>
>>>>> That's the issue.
>>>>>
>>>>> [I should have mentioned that I had also read the job log,
>>>>> before posting.]
>>>>
>>>>
>>>> Yes, that would have saved others some effort.
>>>
>>>
>>> Hmm, when asking for help to "debug the issue", I thought that
>>> it was obvious that reading the log was involved necessary but
>>> not sufficient...
>>
>> But there is no debugging involved here...
>>
>>>>>>
>>>>>> Both of these could happen with any Java version.
>>>>>>
>>>>>>> Or is this a hint for making Java 8 the minimum supported
>>>>>>> version for the next release?
>>>>>>
>>>>>>
>>>>>>
>>>>>> That is not a valid conclusion from the evidence.
>>>>>
>>>>>
>>>>>
>>>>> How do you draw that conclusion?
>>>>
>>>>
>>>> Because there is no proof that the failure is caused by using Java 
>>>> 7
>>>> rather than because the test uses a specific version of the Java 7
>>>> JVM.
>>>>
>>>> JVM crashes tend to be specific to particular implementations.
>>>> It any case, a test that fails with a JVM crash is not a failure 
>>>> of
>>>> the code being tested but of the JVM itself.
>>>
>>>
>>> Sure. Never implied that the problem was in the Java code...
>>
>> But you did imply that the problem was related to Java 7, which it 
>> is not.
>>
>>>>> More to the point, my request is: What to do to fix the negative
>>>>> advertisement for the project which this Travis issue propagates
>>>>> (see badge):
>>>>>   https://github.com/apache/commons-math
>>>>
>>>>
>>>> No idea. Ask a Travis guru.
>>>
>>>
>>> More more to the point, that's the purpose of my posting here!
>>
>> You asked for debugging help, which is not the same.
>>
>>>> The negative publicity belongs to the specific Java 7 JVM which is
>>>> crashing.
>>>
>>>
>>> Sure. Never implied anything else.
>>
>> But you did imply that the problem was related to Java 7, which it 
>> is not.
>>
>>>> Commons Math should really be praised for exposing the bug.
>>>
>>>
>>> And what will we do of it?
>>> That was the "hint" referred to above: if there is no interest in
>>> fixing that bug in a Java7 JVM, we should at least stop submitting
>>> that job to Travis.
>>>
>>> You are, of course, right that we do not have to target Java 8.
>>> My point was: Is there anyone reading this interested in keeping
>>> Java 7 compatibility?
>>> And, if yes, then _those_ people should IMHO be interested in
>>> fixing the problem reported here.
>>
>> The obvious thing to try is to use a different Java 7 compiler.
>>
>>>> I think this just shows that automated checks are only useful if 
>>>> it is
>>>> clearly understood how the checkers measure success/failure.
>>>
>>>
>>> I don't follow.
>>
>> Travis is an automated check.
>> People who rely on the check need to know what success/failure means
>> to avoid being misled by the report.
>>
>>> [Or do you suggest that Travis should report
>>> "success" because the code succeeded in crashing the JVM ;-) ].
>>
>> I am saying that Travis is reporting failure against Commons Math 
>> when
>> it is the JVM that failed.
>>
>> The most that can be said of Math in this case is that the testing 
>> was
>> incomplete, so its state is unknown.
>> (If the JVM had not crashed, the test might still have failed later)
>>
>> The point is that Travis reports failure, but failure in this case
>> does not mean a problem with Math.
>
> But where did you see that I implied there was a problem with Math?
> All along, I asked whether someone knows how to fix Travis (what to
> do, where to ask).

A search on the web[1] seems to point to an old problem:
   https://github.com/travis-ci/travis-ci/issues/5227
but no solution from there (IIUC).

Gilles

[1] "*** buffer overflow detected ***: 
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java terminated"

>
> Thanks,
> Gilles
>
>>
>>> Gilles
>>>
>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Gilles
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message