Fix #12007 (partially): use RVec for RLog callbacks#25412
Fix #12007 (partially): use RVec for RLog callbacks#25412seifreed wants to merge 1 commit intoradareorg:masterfrom
Conversation
Partially addresses radareorg#12007. Replace the RLog callback list (RList) with an RVec-based implementation to reduce allocations and simplify callback storage, keeping the public API unchanged. Add a unit test to ensure r_log_del_callback unregisters callbacks.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 083362bf31
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| r_list_foreach (rlog->cbs, iter, cbu) { | ||
| if (cbu->cb (cbu->user, level, origin, out)) { | ||
| RLogCallbackUser *iter; | ||
| R_VEC_FOREACH (rlog->cbs, iter) { |
There was a problem hiding this comment.
This loop walks rlog->cbs with a raw element pointer, but callbacks are allowed to call r_log_add_callback/r_log_del_callback while handling a log message. With the new RVec backend, push_back can realloc at capacity boundaries (e.g. when growing from 8 to 9 callbacks), which invalidates iter mid-loop and can lead to use-after-free or corrupted iteration; removals can also shift elements and skip callbacks. A safer approach is to iterate by index over a captured length (or clone/snapshot the vector) before invoking user callbacks.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
maybe good to fix what this comment mentions. even if its stupid to add and dlete log callbacks in the event of a logcallback execution it can happen and cause ugly crashes. i can think of two solutions:
-
forbid that (easier, fster, more direct). just have a boolean inside rlog that tells addcallback and delcallback that we are iterating and we wont accept them to run, just return error if thats the case. this boolean can be set and unset before and after this R_VEC_FOREACH loop.
-
add a second list of callbacks that is not iterated from here, fill it when we call add/dell a callback and sync it in an atomic way if there's any call. this will add more runtime code weight. and make log more complicated. but the resulting implementation will be more flexible.
i vote for the 1st option. what do you think? is there any relevant situation that im missing to be able to do that?
There was a problem hiding this comment.
I agree with option 1 to keep it simple and avoid extra runtime weight.
One detail: r_log_add_callback/r_log_del_callback currently return void, so we can’t return an error without API changes.
I propose to guard callback iteration with a boolean lock and make add/del no-op while iterating.
That prevents iterator invalidation/crashes with minimal complexity.
There was a problem hiding this comment.
sounds good to me, lets do that
2 participants
Partially addresses #12007.
This PR migrates the internal RLog callback storage from RList to the newer RVec implementation.
Changes:
Note:
This does not yet integrate REvent logging.