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
Out of memory on binary extract #557
Comments
It seems like your OS just refused a request for more memory to the process when it was inside the |
because it is an extract from binary, it's also possible that the binary was malformed and contained a jaeger-client-go/propagation.go Lines 243 to 249 in 9a2c34e
We could add a check if that number is greater than say 128 (which iirc is the limit that W3C imposes on the number of baggage entries) and fail the parsing, but it's unlikely to precisely catch malformed binary headers |
Thank's for your replies. My os, which is alpine container, was not under low memory issue. I will try to do an exemple to reproduce it. I seem to happen when I try to extract binary content from carrier which not contains any jaeger informations. I will check @yurishkuro. I am interested by thrift bug you disvovered. |
Are you using We just had the issue on one of our binary where |
Have the same problem nats-io/not.go#6 |
Similar issue on the server side when receiving spans jaegertracing/jaeger#2638. We're going to use a patched version of Thrift on the server. Since client has explicit code for parsing binary header, one simple fix is to do what Thrift did and just have an upper bound for the |
Having an upper bound would fix the out-of-memory but it won't prevent the Extract() function from reading garbage and possibly creating random, unrelated, traces. |
#529 must fix your problem. Waiting for version bump |
2.26 was released |
The text was updated successfully, but these errors were encountered: