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