Skip to content

Conversation

@ndossche
Copy link
Member

The reason why freeing was not done yet is because the pointer in these variables may be:

  • Static data set by the readline/libedit library initially, not heap data.
  • Data set by another thread. Although the libraries appear to be not thread-safe anyway.

To solve this, introduce some TLS variables to hold a pointer for us when we override the settings, such that we can free them and are certain they are allocated by us.

…ne_info()

The reason why freeing was not done yet is because the pointer in these
variables may be:
- Static data set by the readline/libedit library initially, not heap
  data.
- Data set by another thread. Although the libraries appear to be not
  thread-safe anyway.

To solve this, introduce some TLS variables to hold a pointer for us
when we override the settings, such that we can free them and are
certain they are allocated by us.
@ndossche
Copy link
Member Author

Worth noting that this also fixes #17154, although that issue had a different PR with a different root cause / discussion?.
CC @devnexen

@devnexen
Copy link
Member

devnexen commented Dec 28, 2025

I have not look at readline source for a long time, but it seems to use globals and thread safety care falls upon the code consumer I believe so your comments make sense.

@ndossche
Copy link
Member Author

I believe it can't be fully made thread-safe. Perhaps at least the existing globals we have in the extension itself can be made thread-safe, but that's kinda out of scope for this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Memory leak when overriding some settings via readline_info()

2 participants