commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: [math] Attempt to circumvent some errors which seem to be platform-dependent.
Date Tue, 05 May 2015 07:57:01 GMT
In fact we do not need real physical / remote access to the machine. It
would be sufficient if somebody can install the hotspot disassembler plugin
for the Java runtime:

Could not load hsdis-i386.so; library not loadable; PrintAssembly is
disabled

Then the assembly for the method in question will be present in the console
output.

Thomas

On Mon, May 4, 2015 at 10:16 PM, Thomas Neidhart <thomas.neidhart@gmail.com>
wrote:

> On 05/04/2015 05:43 PM, luc wrote:
> > Le 2015-05-04 14:48, Thomas Neidhart a écrit :
> >> Problem still remains, see here:
> >> https://builds.apache.org/job/Commons%20Math%20H10/49/console
> >>
> >> The test failures only occur on the following slaves it seems:
> >>
> >>  * H10
> >>  * ubuntu-2
> >
> > This looks like what happened a few months ago then.
> >
> > I will try to look at it. As we are only able to reproduce this on this
> > build system, I guess this implies committing lots of small changes (with
> > System.out.println and the like) and triggering a custom buid from the
> > Jenkins configuration above. I can do that, but wonder if there is
> another
> > way without committing the tests in the master branch. Can we set up an
> > h10-builds branch that would be used by the job above and would be
> ignored
> > by the regular job ?
> >
> > If I remember well, when the previous problem arose even putting simple
> > print
> > statements in the code made the bug appear and disappear without control.
>
> yes indeed. I tried different ways to figure out what exact statement
> went wrong due to JIT compilation (e.g. with System.out statement), but
> this already alters the compilation itself thus making it
> difficult/impossible to track down the problem like that.
>
> The advantage we had previously was that we had a good idea which
> statement went wrong (it was a cast). This time, I do not yet have an
> idea, so I think the only way to track this down would be to get
> physical access to the machine and analyze the resulting JIT assembly.
>
> You can see in the console output above that I enabled JIT debugging and
> that the method in question was optimized 2 times.
>
> Thomas
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message