There seems to be a mismatch in ownership semantics between valkeymodule-rs and the Valkey C API when handling string config getters, which may be causing a memory leak.
Problem:
- The Rust function
string_configuration_get returns a *mut RedisModuleString using .take(), which appears to transfer ownership.
- The C function
getModuleStringConfig calls this getter and duplicates the string (sdsdup(val->ptr)), assuming the original remains valid.
- This is done on purpose, as Valkey’s documentation states that "On string config gets, the string will not be consumed and will be valid after execution."
- Since the C code does not free the original, and Rust seems to allocate a new copy, this could lead to a memory leak.
Reproduction Steps:
- Compile Valkey with AddressSanitizer (ASan).
- Run Valkey with a module that registers string configs (e.g.,
valkey-bloom).
- In the CLI, run
CONFIG GET bf.bloom-fp-rate (or another registered config).
- Stop the server – ASan should report a memory leak.
Additional Context:
I'm not a Rust expert, but based on my understanding, .take() combined with ConfigurationContext::new() might be the cause.
|
extern "C" fn string_configuration_get<T: ConfigurationValue<ValkeyString> + 'static>( |
There seems to be a mismatch in ownership semantics between
valkeymodule-rsand the Valkey C API when handling string config getters, which may be causing a memory leak.Problem:
string_configuration_getreturns a*mut RedisModuleStringusing.take(), which appears to transfer ownership.getModuleStringConfigcalls this getter and duplicates the string (sdsdup(val->ptr)), assuming the original remains valid.Reproduction Steps:
valkey-bloom).CONFIG GET bf.bloom-fp-rate(or another registered config).Additional Context:
I'm not a Rust expert, but based on my understanding,
.take()combined withConfigurationContext::new()might be the cause.valkeymodule-rs/src/configuration.rs
Line 306 in 6497ac4