experiment: detect re-entrancy in ddtrace_serialize_closed_spans #3562
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
We have crashes that deal with serializing
metainformation. After many hours spent including with different AI models, I think something "odd" or weird must be going on. Thus far I haven't been able to detect any basic cases of bad refcounting or anything like that. Sometimes it happens on request shutdown, other times during the request.For instance, we have some crashes caused by using
DDTrace\\close_span()from the Laravel integration. I don't know if Laravel or its Integration are specifically triggering this or if it's just popular, but many of these crashes are coming from the Laravel integration (but again, not all).We don't see re-entrancy in the crash frames, but the idea is that it would re-enter and succeed, but when the original resumes, the data has been freed or something and then crashes.
Honestly, this is a bit of guessing, but I wanted to experiment to see if this can trigger.
Crash Exhibit 1
Crash Exhibit 2
Reviewer checklist