kvrocks: Memory leaks in Lua::redisGenericCommand
Search before asking
- I had searched in the issues and found no similar issues.
Version
redisGenericCommand use raiseError to process errors, but raiseError will perform a longjmp in the lua_error api call, so raiseError never returns.
longjmp does not compatible with RAII in C++ (C++ exceptions may use longjmp in implementation but the compiler will insert some dtor call autometically and carefully, i.e. stack unwinding), so every object in the stack of redisGenericCommand will never be destroyed, i.e. no destructor will be call, hence all resource allocated in ctor like std::vector, std::unique_ptr etc. cannot be released.
Minimal reproduce step
./runtest --dont-clean on a kvrocks binary with Address Sanitizer enabled. (try to build with #599)
You can only run tests in unit/scripting to save time : )
What did you expect to see?
No memory leaks
What did you see instead?
Memory leaks are reported by Address Sanitizer
Anything Else?
No response
Are you willing to submit a PR?
- I’m willing to submit a PR!
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 15 (15 by maintainers)
@tisonkun @git-hulk Agree with that. I’ll try the first solution.
@tisonkun Yes, many guys proposed this in Redis community, but didn’t have any progress. The main issue is that will break the old Lua scripts, coz Lua 5.2+ have many breaking changes compared with 5.1. That’s the reason why we still stuck in 5.1.
@PragmaTwice Go ahead!
@PragmaTwice Really good catch, I wasn’t aware the destructor would be ignored by longjump. Lua supported using
try..catchto workaround the C++ condition: https://github.com/KvrocksLabs/lua/blob/3e2d94b3b98d774dcd4fb448b1cb64615ae0590d/src/luaconf.h#L606Cool, Thanks for Twice great investigation.