4.0.0: StackOverflowError in error-prone

[dmivankov]

Description of the problem / feature request:

Trying out bazel 4.0.0, with --javabase=@bazel_tools//tools/jdk:remote_jdk11 --java_toolchain=@bazel_tools//tools/jdk:toolchain_java11 and hit a bug in error-prone 2.4.0 (bazel 3.3.1 has 2.3.2 I think, and it works)

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Haven't yet reproduced in a small setup but likely is triggered by code generated by https://github.com/immutables/immutables 2.8.8

Any other information, logs, or outputs that you want to share?

Most recent error_prone is 2.5.1, but haven't tested if it'd fix the issue https://github.com/google/error-prone/releases

some_class.java:192: error: An unhandled exception was thrown by the Error Prone static analysis plugin.
                    SomeClass.builder().from(someInstance).build())
     Please report this at https://github.com/google/error-prone/issues/new and include the following:
  
     error-prone version: 2.4.0
     BugPattern: ArrayToString
     Stack Trace:
     java.lang.StackOverflowError
  	at jdk.compiler/com.sun.tools.javac.code.Types$UnaryVisitor.visit(Types.java:4937)
  	at jdk.compiler/com.sun.tools.javac.code.Types.supertype(Types.java:2462)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2128)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2117)
  	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:993)
  	at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4857)
  	at jdk.compiler/com.sun.tools.javac.code.Types.asSuper(Types.java:2114)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2130)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2117)
  	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:993)
  	at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4857)
  	at jdk.compiler/com.sun.tools.javac.code.Types.asSuper(Types.java:2114)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2130)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2117)
  	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:993)
  	at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4857)
...

Not sure if there's an easy way to upgrade error_prone version without the need to rebuild bazel itself

Bump of error_prone commit 239b2aa
Some issues with earlies attempts of upgrade 2.3.2->2.3.3 #9286

[cushon]

Do you have a repro?

It looks like it's just running out of stack. Does setting a higher stack size make a difference, e.g.:

load(
  "@bazel_tools//tools/jdk:default_java_toolchain.bzl",
  "default_java_toolchain", "JDK9_JVM_OPTS",
)

default_java_toolchain(
  name = "toolchain",
  jvm_opts = JDK9_JVM_OPTS + ["-Xss7m"],
)

bazel build --java_toolchain=:toolchain ...

[dmivankov]

Xss7m didn't help, stacktrace is quite repetitive, so could be an infinite recursion.
Small repro https://github.com/dmivankov/bug_reports/tree/bazel_12926

[cushon]

Thanks, taking a close look I see that immutables is generating a class that completes a cyclic type hierarchy:

$ javap -cp bazel-bin/liba-hjar.jar A\$Builder ImmutableA\$BuilderImpl
public class A$Builder extends ImmutableA$BuilderImpl {
  public A$Builder();
}
public final class ImmutableA$BuilderImpl extends A$Builder {
  public final ImmutableA$BuilderImpl from(A);
  public ImmutableA build();
}

This is an interaction between immutables and https://github.com/google/turbine's implementation of annotation processing.

This logic is relying on the toString() representation of ImmutableA.BuilderImpl in class Builder extends ImmutableA.BuilderImpl { before the code has been generated yet, while ImmutableA.BuilderImpl is still being modelled as an error type: https://github.com/immutables/immutables/blob/dd249064688af65ee3ff00fa5819e9deeb1bcf67/generator/src/org/immutables/generator/SourceExtraction.java#L396-L406

[dmivankov]

As a workaround

import org.immutables.value.Value;

@Value.Style(
    typeBuilder = "ABuilderImpl",
    builderVisibility = Value.Style.BuilderVisibility.PUBLIC,
    implementationNestedInBuilder = true
)
@Value.Immutable
interface A {
  static Builder builder() {
    return new Builder();
  }

  class Builder extends ABuilderImpl {
  }
}

seems to work on the repro case, class hierarchy is different, but may work well.

For the original setup, what looks like a correct place to implement a fix

• error_prone (something changed there?)
• bazel annotation processing (something changed there?)
• immutables (is such hierarchy really valid? or maybe there's a chance to have small modification of codegen to remove the cycle?)

[cushon]

bazel annotation processing (something changed there?)

This is the thing that actually changed in Bazel--as of 10ffddb Bazel uses a different annotation processing implementation by default (https://github.com/google/turbine).

The way errors are modeled in the annotation processing API isn't very well specified, but I think improving turbine here is a good resolution, I don't see anything in particular immutables should be doing differently.

Ideally javac would detect the cycle and not crash, but there are a lot of ways that invalid class files can cause problems for javac, so I'm not sure it's worth trying to handle that better.

The mention of Error Prone in the stack trace is a red herring, it just catches top-level exceptions and tries to log additional information.