Fix generics stack leak that poisoned reused Kryo instances

[Icesource]

Fixes #1281.

Problem

When a serializer throws while (de)serializing a field, entries are left on Kryo's generics stacks:

• ReflectField skips its popGenericType (it was after the nested read/write, not in a finally).
• FieldSerializer skips popTypeVariables (it is after the field loop, outside the try/catch).

Kryo.reset() did not clear these stacks, so the leaked state survives autoReset and poisons a reused (thread-local or pooled) Kryo instance — a later, unrelated (de)serialization then mistakes the stale generic for its own and fails with a misleading ArrayIndexOutOfBoundsException. The instance stays broken for the rest of its lifetime.

Fix

Following the approach suggested in the issue:

1. Generics.reset(), called from Kryo.reset() — centralized so it always runs, even if a finally is forgotten somewhere. It has a fast path that returns immediately when the stacks are already empty (the normal case after a balanced serialization), so the per-serialization cost is negligible. The slow path nulls out the leaked entries and zeroes the sizes. Both the genericTypes stack and the type-variable (arguments) stack are cleared, since both leak on exception. NoGenerics gets a no-op.
2. popGenericType moved to a finally in ReflectField.read/write — the most likely source of serialization exceptions — so the common case keeps the stack balanced without relying on reset(). popGenericType is already safe to call when nothing was pushed.

Tests

GenericsResetTest covers both directions end-to-end:

• Deserialization: a read that throws inside a List<Item> field, followed by an unrelated HashMap with two non-empty nested maps. Before the fix the generics stack is left at size 2 and the second read throws ArrayIndexOutOfBoundsException; after the fix the stack is empty and the second read succeeds.
• Serialization: a write that throws inside the same field, then asserting the stack is empty and a subsequent serialization/deserialization succeeds.

Both fail on master without the fix and pass with it.

Full suite: the only failure is DefaultSerializersTest#testLocaleSerializer (zh_CN vs zh_CN_#Hans), a pre-existing locale-data difference in my environment that also fails on unmodified master.

[Copilot]

Pull request overview

Fixes a long-lived state leak in Kryo’s generics tracking where exceptions during field (de)serialization could leave entries on the generics/type-variable stacks, poisoning reused Kryo instances across subsequent operations.

Changes:

• Add Generics.reset() and invoke it from Kryo.reset() to centrally clear leaked generics/type-variable stack state.
• Make ReflectField.read/write exception-safe by moving popGenericType() into finally.
• Add GenericsResetTest to reproduce the failure and assert correct behavior after both read- and write-time exceptions.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
test/com/esotericsoftware/kryo/serializers/GenericsResetTest.java	New end-to-end regression tests covering generics stack leaks on exception for both read and write paths.
src/com/esotericsoftware/kryo/util/NoGenerics.java	Adds reset() no-op implementation for the no-generics mode.
src/com/esotericsoftware/kryo/util/Generics.java	Introduces reset() API for clearing tracked generic info (called from Kryo.reset()).
src/com/esotericsoftware/kryo/util/DefaultGenerics.java	Implements stack-clearing reset() for the default generics tracker.
src/com/esotericsoftware/kryo/serializers/ReflectField.java	Ensures generics stack is popped via finally even when nested (de)serialization throws.
src/com/esotericsoftware/kryo/Kryo.java	Calls generics.reset() as part of Kryo.reset() to prevent stale generics from surviving reuse.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Icesource]

Thanks for the review. Addressed both points:

• Made Generics.reset() a default no-op method so it is not a breaking change for external Generics implementations; DefaultGenerics still overrides it with the real reset.
• Updated the Javadoc to note it runs after both serialization and deserialization (when auto-reset is enabled).

[theigl]

That looks great! Thank you @Icesource.