You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems there is a concurrency bug that can cause nil pointer dereferences.
This GitHub issue first presents the stack trace, then a test case that can (sometimes) cause it and finally a best bet on the root cause. As a bonus, a stack trace against an older version of the library is also presented.
The stack trace
This is the stack trace I get running against v2.27.0.
I have created a test case that can (sometimes) cause failures. I need to run it multiple times. Since our build system is bazel, I run it with runs_per_test=20.
Then maybe we could have an internal cache used while parsing.
When parsing is done, everything from the internal cache is added to the final cache.
In that way, one in-process parsing call cannot add not-finished-parsing content that is used by a different parse call.
I have not had time to dig into this properly yet, end of year time pressures and all.
The local cache seems like a good option, but I would look in the direction of a wrapper around the SchemaCache, to not burden the rest of the parser with this.
Hi there.
It seems there is a concurrency bug that can cause nil pointer dereferences.
This GitHub issue first presents the stack trace, then a test case that can (sometimes) cause it and finally a best bet on the root cause. As a bonus, a stack trace against an older version of the library is also presented.
The stack trace
This is the stack trace I get running against
v2.27.0
.The test case
I have created a test case that can (sometimes) cause failures. I need to run it multiple times. Since our build system is bazel, I run it with
runs_per_test=20
.The root cause
I think it is caused by adding a RecordSchema to the schema cache before it is fully parsed.
Let me try to elaborate.
First a slice of fields containing all nils is allocated at
avro/schema_parse.go
Line 247 in 45d131b
A record is constructed at
avro/schema_parse.go
Lines 254 to 262 in 45d131b
The record is added to the cache at
avro/schema_parse.go
Line 272 in 45d131b
but the fields are not populated before the code reaches
avro/schema_parse.go
Lines 277 to 283 in 45d131b
This can cause others to use the cache with nil fields, causing the stack trace above.
I think the solution would be to parse the fields before adding it to the cache.
Bonus stack trace against
v2.8.1
The bug was found while on an older version (
v2.8.1
). The stack trace below is when tested against that version:The text was updated successfully, but these errors were encountered: