[WIP][Profiling] Prevent panic from crossing FFI boundaries #815
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BenchmarksComparisonBenchmark execution time: 2025-01-06 14:04:28 Comparing candidate commit d8e4924 in PR branch Found 0 performance improvements and 3 performance regressions! Performance is the same for 48 metrics, 2 unstable metrics. scenario:normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて
scenario:tags/replace_trace_tags
CandidateCandidate benchmark detailsGroup 1
Group 2
Group 3
Group 4
Group 5
Group 6
Group 7
Group 8
Group 9
Group 10
Group 11
Group 12
BaselineOmitted due to size. |
gleocadie
force-pushed
the
gleocadie/avoid-leaking-panic-in-ffi
branch
from
579730c to
6730452
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #815 +/- ##
==========================================
- Coverage 71.03% 71.03% -0.01%
==========================================
Files 313 313
Lines 45908 45912 +4
==========================================
+ Hits 32612 32614 +2
- Misses 13296 13298 +2
|
gleocadie
force-pushed
the
gleocadie/avoid-leaking-panic-in-ffi
branch
from
6730452 to
d8e4924
Compare
|
This is a complex subject, but I think we've been avoiding addressing it for a bit too long. The ideal mode of operation would be to have no aborts, but in the real world sometimes one slips by... I think having a "last line of defense" on FFI functions that returns a clean error makes sense. Of course in some cases returning an error means the rust state can be in an inconsistent state, but it seems reasonable to put the burden on the API client to properly handle errors by backing off and stopping e.g. profiling, rather than tearing the whole app down. E.g. an abort is an extreme event, so I think stopping datadog stuff and logging an error (possibly via crashtracking...) is a reasonable outcome to such an extreme event (and is a much better alternative than killing off the host app). We could look into enabling lints to make it easier for us to catch things that may cause abort, but I suspect that will hinder and make really awkward a lot of the code we want to write. The Linux kernel folks have faced similar challenges, so perhaps there's some learnings there (I found this link on a quick googling). TL;DR: If we could write a nice macro to add this feature to most of our FFI, I think it's a reasonable and worth improvement. |
That's why this draft is here :) to talk about that subject. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What does this PR do?
This PR is a communication channel to discuss about preventing panic from crossing FFI boundaries.
The code change here is to discuss, and find the best way to achieve this.
Motivation
Playing around with the new crashtracker api, we got a crash (#756) because there were missing information. The example was not modified nor ran which left with an unusable version of libdatadog (crashtracking)
This may be a misusage and the client's code must be changed, but in no case, this should panic. (at the minimum, there should be tests.
Additional Notes
Anything else we should know when reviewing?
How to test the change?
Describe here in detail how the change can be validated.