-
Notifications
You must be signed in to change notification settings - Fork 996
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
Panic due to index out of bounds #3063
Comments
What code are you running with buildkit? It is unclear if buildkit is generating unexpected telemetry, if we are generating unexpected telemetry, or the thrift library is not handling valid telemetry. |
Have you raised this issue with buildkit? It looks like they are using a custom controller to handle interaction with the exporter. That controller has a mutex on it, implying it might be used concurrently, but that mutex is not locked around interactions with the exporter, which is not safe for concurrent use. |
Thanks for the quick responses! @MrAlias - I'm not sure what code you are referring to. We use @Aneurysm9 - I haven't yet. Thanks for the pointer! I'll take a look and bring it up with them. |
Same issue 2022-08-09 09:10:06 | library/http_caller/http_caller.go:428 +0x65 |
@tritueviet - What service is this from? Is this @Aneurysm9 - From preliminary testing, it looks like adding a mutex around the |
Hi! I've opened a PR to the buildkit repo, and they had some questions. @Aneurysm9 - would you mind participating in that discussion as well? I'm not sure I know how to answer. moby/buildkit#3058 I've also noticed the following comment in the SpanExporter interface:
I'm not sure how the function being called synchronously relates to the concurrency safety requirement, and whether that is at all correct given that it seems there actually is a requirement. Should that be changed? Or am I just not understanding the comment? |
That comment is valid from the perspective of the consumers of the interface (or, at least, those that live in this repository). i.e., the batch span processor will not make concurrent invocations of its associated exporter. If there are other components that may invoke that method then the exporter will need to ensure that it is safe to call that method concurrently. |
It seems like that comment needs to rephrased to communicate to the user of the interface (not the implementer). E.g:
|
Since this is confusing, I'd like to change the wording - can I add what @MrAlias wrote? |
I disagree. The interface should communicate the contract for the implementer. The implementation should have its own documentation and can communicate its concurrent safety. I decide to close this issue as it is stale and there is no consensus on how to resolve it. |
Description
I'm using Buildkitd (v0.10.3) in a container, and have used the JAEGER_TRACE env var to enable open telemetry tracing pointed to a Jaeger all in one instance. Occasionally, the Buildkitd process will panic with a stack trace such as (two examples below). This is bad because any running builds will be discontinued, and clients get an ugly error.
Stack trace 1:
Stack trace 2:
Environment
go.opentelemetry.io/otel v1.4.1
Steps To Reproduce
Unsure, unfortunately, beyond running
buildkitd
, with JAEGER_TRACE on.Expected behavior
No panic? :)
I'm not entirely sure this is the right project to report this panic. Please let me know if there is any other info I can supply that will help.
The text was updated successfully, but these errors were encountered: