Race condition with System.Json

[shargon]

Description

I'm not sure when or why, but my project sometimes serialize invalid json using the same objects, when the cpu is higger. Not sure why, still investigatin

Reproduction Steps

Investigating...

Expected behavior

Good serialization

Actual behavior

Invalid serialization

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

[stephentoub]

(I assume you meant System.Text.Json?)

Thanks, but this issue isn't actionable as written. I'm going to close it and you can re-open if/when you have more details. STJ is deterministic, so if you're seeing invalid results sporadically, I suspect it's something else in your app, eg something returning an array to the ArrayPool but then still using it, or something mutating an object concurrently with that object being serialized, or something like that.

[shargon]

(I assume you meant System.Text.Json?)

Thanks, but this issue isn't actionable as written. I'm going to close it and you can re-open if/when you have more details. STJ is deterministic, so if you're seeing invalid results sporadically, I suspect it's something else in your app, eg something returning an array to the ArrayPool but then still using it, or something mutating an object concurrently with that object being serialized, or something like that.

It is almost impossible to detect, not even when debugging. It is a very long, immutable JSON that, on certain occasions, begins to serialize truncated (the http request has not been cancelled) and Kestrel simply decides to truncate that property of about 4k characters and send the result of the truncated JSON. This happens when there is high concurrency.

[shargon]

Here you can see an example, Request object, is serialized and start with \0\0\0\0... impossible without a bug