should we hold off on `1.4.30-1.0.0-alpha02`?

# ksp

[Zac Sweers]

should we hold off on 1.4.30-1.0.0-alpha02?

[Ting-Yuan Huang]

well, we planned to announce it tomorrow 😛

[Zac Sweers]

haha ok just checking, wasn't sure since it came right after alpha01 and figured you might be double checking something

[Ting-Yuan Huang]

Yeah, we found something funky after the alpha01 while testing and therefore need to pull it down. The alpha02 should be in a good shape but please allow us to give it more tests.

[Zac Sweers]

I just tested it out and seeing huge memory usage spikes. It OOMs kotlin-compile-testing tests

[Zac Sweers]

https://github.com/ZacSweers/kotlin-compile-testing/tree/z/ksp1430alpha2

[Ting-Yuan Huang]

Thanks for trying it out. Let me take a look to see if we need alpha03 😢

[Jiaxiang]

One thing I could think of from the commit is you didn’t check if the processor has been invoked. With multiple round, if you have some files generated every round regardless of the input from annotated symbols, then multiple round will continue retrying for a fix point which never comes

[Jiaxiang]

https://github.com/ZacSweers/kotlin-compile-testing/blob/z%2Fksp1430alpha2/ksp/src/test/kotlin/com/tschuchort/compiletesting/KspTest.kt#L202 I think this is the culprit

[Ting-Yuan Huang]

I can repro. From the log, there are ~500 rounds for each of the failing tests.

[Zac Sweers]

That could do it, I don't think kotlin-compile-testing is aware of multiple rounds

[Zac Sweers]

Maybe this is me learning I should contribute it 😅

[Ting-Yuan Huang]

Thanks again for trying it out. We'll make a note of this API change in the release.

[yigit]

hmm we did have this OOM when updating kotlin to 1.4.30 in androidX infra

[yigit]

but it went away after ksp also updated to 1.4.30

[Zac Sweers]

yeah I'm not actually sure where kotlin-compile-testing is doing anything wrong 🤔

[Zac Sweers]

I think I've figured it out, it has some tests that always generate files regardless of inputs, so it gets into a loop

[Zac Sweers]

https://github.com/tschuchortdev/kotlin-compile-testing/pull/112

[Zac Sweers]

even with this though, I see a stackoverflow crash coming from kotlinc analysis handling in my own tests here. Not totally sure what I'm looking at though, would be curious for thoughts https://github.com/ZacSweers/auto-service-ksp/pull/10#issuecomment-777281721

[Ting-Yuan Huang]

This looks like many rounds. @Jiaxiang?

org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.repeatAnalysisIfNeeded(KotlinToJVMBytecodeCompiler.kt:478)

[Zac Sweers]

I can't spot anything obviously wrong with what my plugin does though, unless it's something related to the fact that it only generates resources?

[Ting-Yuan Huang]

We'll investigate. Could be some termination problem. Repro is checking out the branch and ./gradlew :ksp:test right?

[Zac Sweers]

just ./gradlew :processor:test, no :ksp module

[Ting-Yuan Huang]

Thanks, let us try

[Jiaxiang]

it looks that generateConfigFiles() is called every round?

[Zac Sweers]

yes but it should only generate new files

[Zac Sweers]

unless....

[Zac Sweers]

wait I have an idea

[Jiaxiang]

it looks that a clear() on the providers might be a fix

[Zac Sweers]

yup that's what I'm thinking

[Zac Sweers]

yup that did it

[Zac Sweers]

sorry for the fire drill 😅

[Jiaxiang]

good to hear! Yeah I do think the multiple round infinite loop seems to be quite confusing and I might want to emphasis it in the next release note..

[Zac Sweers]

would it be helpful to maybe check for "re-generated" files? I.e. detect when something is in a loop

[Jiaxiang]

it is doable, I can simply add a check for file path in that case

[Zac Sweers]

👍

[Jiaxiang]

but on the other hand, a processor should not generate to the same file in different rounds (it is not easy for ksp to check if the contents are identical), does it make sense for CodeGenerator to throw exceptions when user tries to create a new files that has been created in previous rounds?

[Zac Sweers]

I think so, it would have undefined behavior at best unless the goal is to allow later overwrites