Debugging segmentation faults in the JVM on linux-powerpc

[Thomas Stüfe]

On Mon, Jun 12, 2017 at 1:51 PM, Severin Gehwolf <sgehwolf at redhat.com>
wrote:

> Hi,
>
> On Fri, 2017-06-09 at 20:57 +0200, John Paul Adrian Glaubitz wrote:
> > On 06/09/2017 07:54 PM, John Paul Adrian Glaubitz wrote:
> > > On 06/09/2017 05:58 PM, John Paul Adrian Glaubitz wrote:
> > > > I'll rebuild everything with --enable-debug
> --with-debug-level=slowdebug
> > >
> > > Just rebuilding with "--with-debug-level=slowdebug", of course. Both
> options
> > > are mutually exclusive.
> >
> > Surprise, surprise. Building with "--with-debug-level=slowdebug" instead
> of
> > "--with-debug-level=release" made the crash go away. Does gcc optimize
> too
> > aggressively here?
>
> It smells a lot like the GCC issues we've run across when building with
> newer compilers in Fedora/RHEL.
>
> Here is one example which turned out to be a GCC bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341
>
> Others were UB in hotspot code:
> https://bugs.openjdk.java.net/browse/JDK-8078666
>
> Which GCC version is this?
>
> Provided this is a GCC issue:
>
> In order to figure out which new optimization might have caused this,
> I'd suggest to go through the list of new opto flags that are on by
> default in the new version and disable one by one.
>
> Once you know which opto flag causes it, you might be able to figure
> out which object file causes the problem with something like this:
> https://github.com/jerboaa/hotspot-tools-find-bad-object
>
> It might be something else entirely.
>
> Cheers,
> Severin
>

I agree with Severin. It makes sense to rule out a compiler failure before
spending more work on it. The coding in question is completely architecture
independent, and the fact that it only happens on one platform, and that
the error vanishes in slowdebug, is suspicious.

Kind Regards, Thomas