-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concurrent schema parsing and unmarshalling causes nil pointer dereference #481
Comments
The issue with your solution is that it does not account for circular schemas. |
Then maybe we could have an internal cache used while parsing. |
@nrwiersma any updates? What do you think of the local-cache-while-parsing solution? |
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. |
@nrwiersma hi again. Is this something you will look into at some point or is the pressure still on and you would rather like a pull request? We would like to update to a version with a fix as soon as it is available. This is causing one of our services to crash at random times. |
Hi, I have not forgotten but have not gotten to it yet. A PR is welcome if you want to speed things along. |
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: