codecov-commenter
commented
5 months ago Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 92.84%. Comparing base (
41248ed) to head (8e914a7). Report is 58 commits behind head on main.
Additional details and impacted files
```diff @@ Coverage Diff @@ ## main #612 +/- ## ========================================== + Coverage 92.55% 92.84% +0.29% ========================================== Files 91 92 +1 Lines 11304 11234 -70 Branches 1581 2055 +474 ========================================== - Hits 10462 10430 -32 + Misses 837 804 -33 + Partials 5 0 -5 ``` | [Flag](https://app.codecov.io/gh/bloomberg/memray/pull/612/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=bloomberg) | Coverage Δ | | |---|---|---| | [cpp](https://app.codecov.io/gh/bloomberg/memray/pull/612/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=bloomberg) | `92.84% <ø> (+6.90%)` | :arrow_up: | | [python_and_cython](https://app.codecov.io/gh/bloomberg/memray/pull/612/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=bloomberg) | `92.84% <ø> (-2.88%)` | :arrow_down: | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=bloomberg#carryforward-flags-in-the-pull-request-comment) to find out more.:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
memray attachneeds to inject some custom code into the process it has attached to. It does this by usingdlopenand then calling a function we control, but that can't be done just anywhere: we need to ensure we're not currently in the middle of a call todlopen, or in the middle of a call tomalloc, etc.To work around this, we set a handful of breakpoints for known safe (probably) places to call into our custom code, and load and call it only when the breakpoint is hit.
Add 2 new breakpoints to our gdb script, on
PyCallable_CheckandPyError_CheckSignals. Also, usePy_AddPendingCallto schedule a call toPyCallable_Checkon the main thread, in the hopes of triggering one of our breakpoints to happen sooner.For now, apply this only to our gdb script, and not to our lldb script. Making the analogous changes to the lldb script results in lldb on Linux stopping at an already-deleted breakpoint, and I haven't figured out a workaround or fix for that yet.