Hi, I have an issue with an old version (4.10.2), in a jar task, when I try to filter like -> from (sourceSets.main.output.classesDirs) { include(fileContent) } // where fileContent is a String array with more than 10000 String, list of .class to include in the jar Issue is: [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] * Exception is: 171441 171441.909 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] java.lang.StackOverflowError 171441 171441.909 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] at org.gradle.api.internal.file.pattern.PatternMatcherFactory.compile(PatternMatcherFactory.java:50) 171441 171441.910 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] at org.gradle.api.internal.file.pattern.PatternMatcherFactory.compile(PatternMatcherFactory.java:59) 171441 171441.910 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] at org.gradle.api.internal.file.pattern.PatternMatcherFactory.compile(PatternMatcherFactory.java:59) ... This fail in Jenkins environment, in my local environment with same versions of java / gradle it,s ok, no issue occured. Any idea?

could you paste more of the stack trace, skipping all the

PatternMatcherFactory.java

lines?

If you look at that code, there is this method

compile

that calls itself, fed by a path that is split to its path parts. The difference between your build and CI build is most probably that either on CI the paths are longer, so more recursive steps, or the stack-size (

-Xss

) is bigger which can depend on the OS and architecture if not specified explicitly. You could try to increase the stack-size to mitigate the problem, or you could try to use different filter-technique, like

include { ... }

instead of patterns. Ultimately, you should either way probably report a Gradle bug. The code in 8.13 is basically still the same, just using a

List

instead of an array. It should probably be rewritten somehow to not be recursive.

Thanks at all for your responses🙂. In addition if I do the same with a smaller array of .class to include (10 items for example) it's ok no StackOverflowException is throw, the issue is clearly due to the huge list of .class to include in the jar. I'll try to set -Xss to increase the stack, and in my local environment decrease it in order to try to reproduce in my local environment.

No, it is clearly unrelated to that fact, you are following a red herring. As I said, just read the code where the recursion happens. It is recursing over the path parts of a single path. That it does not happen locally is probably because you have shorter paths, or bigger stack size, that it does not happen with 10 paths is, that you happen to have picked 10 paths that are short enough. Pick the single longest path in that list and it will fail the same. You can also easily reproduce for example using

fileTree("x").matching {
    include(List(20000) { "x" }.joinToString("/"))
}.forEach {
}

anywhere in the build script and as soon as you run any task, it will fail with the SOE.

Now I understand, it's an issue with too long path. Effectively with your Kotlin example code the Gradle step compilation fail with a SOE, but at the compilation step not when the task run because I can't build it. I'll try to reproduce in my local environment with a huge path.

Not "at the compilation step", but when executing the configuration, as that is what I do. It is just to show that you can easily reproduce the issue. Just put instead the

include(List(20000) { "x" }.joinToString("/"))

where you have your

include(fileContent)

and it will fail at the same spot your CI is failing

Sorry for the channel, so noob for the moment🤭. I can reproduce the SOE in my local environment, for now I must retrieve the most longer path to set it in a other way that in an array of String. Thanks for your contribution