Hello, I faced some error, it happens very rare, but the project build fails due to the `Execution f...

# multiplatform

[Roman Belousov]

Hello, I faced some error, it happens very rare, but the project build fails due to the Execution failed for task ':XXX:podspec' no one came across this?

The modules themselves are assembled in parallel by:

./gradlew podspec -Dorg.gradle.daemon=false.

Here's the logs:

Task failed with an exception.

11:33:51 ------------
11:33:51 * What went wrong:
11:33:51 Execution failed for task ':XXX:podspec'.
11:33:51
11:33:51 > Could not create task ':wrapper'.
11:33:51 > java.util.ConcurrentModificationException (no error message)

Is there anything I can do with that? Thanks in advance 🙂

[Jeff Lockhart]

I've seen this or a similar ConcurrentModificationException (I can't recall the details). When I've seen it, I just do a clean build and it works afterwards, so I haven't bothered looking into it more.

[Roman Belousov]

Yeah, actually if I just re-run the build in 95% it compiles successfully

But it's kind of disturbing because usually it happens on CI, so every time it happened you need to re-run the build yourself

[a-dd]

Hi Roman, which Gradle version are you using?

[Roman Belousov]

We use Gradle 7.3.1

[Jeff Lockhart]

I'm using 8.1.1 myself.

[Jeff Lockhart]

The next time I see it, I'll share the stack trace.

[a-dd]

I don’t know the exact reason for the problem. But it probably will be fixed in 1.9.20 because I’ve rewritten this part in a more safe way 🙈

[Jeff Lockhart]

I just got the error again. This is the stack trace. I'm using the latest 1.9.0-RC-237 build and Gradle 8.1.1.

Untitled

[Roman Belousov]

https://kotlinlang.slack.com/archives/C3PQML5NU/p1685462877904119?thread_ts=1685426418.942459&cid=C3PQML5NU
Glad to hear that 🙂

For now the only way I found it is to set -Dorg.gradle.parallel=false
It's kind of fix the problem, but obviously it makes out build time bigger

Any ideas, is there something else i could do? 🙂

[a-dd]

You can try adding tasks.getByName("wrapper") call to you root build.gradle.

[Roman Belousov]

Sorry, don't really get it) Could you please tell it more extended, where should I add this tasks.getByName("wrapper") and how is it gonna help?

[a-dd]

Literally to top level of root build.gradle simple smile I know it looks a bit strange, you can wrap it into smth like logger.quiet(tasks.getByName("wrapper").name) to feel more secure.

[a-dd]

It should help because the problem (as I see it) is that we’re getting (and therefore sometimes creating) this task during execution of another task. It’s not really how you’re suppose to use gradle. This call will move the wrapper task creation to the configuration phase.

[Roman Belousov]

Thanks a lot, I'll try 🙂

[Jeff Lockhart]

@a-dd I removed the tasks.getByName("wrapper") workaround now with the 1.9.20-Beta and I'm getting `ConcurrentModificationException`s again. Here's the new stack trace.

ConcurrentModificationException

[hfhbd]

Honest question: What is the hell does KGP that affects other tasks, here the build-in wrapper task?

[a-dd]

@Jeff Lockhart that’s sad. Could you try to work out a reproducer and report the issue?

[a-dd]

@hfhbd nothing to scary actually, we’re just using an output of a public built-in Gradle task

[Jeff Lockhart]

I'm assuming org.gradle.parallel=true is likely necessary to reproduce. It seems likely something to do with the CocoaPods plugin, based on the podspec task. I have 10 modules, all of which use CocoaPods to add an Objective-C dependency, but only two actually generate C interop. The other modules are linkOnly. Beyond that, I'm not sure which combination of tasks and modules in my project create this scenario.

I will be open-sourcing my project soon though, and it's fairly easy to reproduce when doing a Gradle sync. Without the workaround in place, it happens 5-10% of the time. I plan to release my library when Kotlin 1.9.20 is released. I'll probably make the code public this week.

[hfhbd]

@a-dd Well, you do use coroutines inside KGP to create your own plugin lifecycle, so I am a little bit surprised/scaried 😄 Mostly to support (upcoming) isolation project and stable config cache.

[Jeff Lockhart]

https://youtrack.jetbrains.com/issue/KT-62040