forbid module to unload when it holds ongoing timer#10187
forbid module to unload when it holds ongoing timer#10187oranagra merged 9 commits intoredis:unstablefrom
Conversation
|
@warriorguo It looks like missing a test for module unload while the timer is still running. |
|
@sundb thanks for the review, actually I tried to add a test for unloading as it would return an error, but it would be caught by (https://github.com/redis/redis/blob/unstable/tests/test_helper.tcl#L850) and caused the failure. Any suggestions for this situation? |
|
@warriorguo You can post or commit your test code, I will help to see it. |
|
@sundb please check 2f8fd8a. the failure message was something like. thanks in advance! |
|
@warriorguo @sundb isn't it better to delete the timer when the module is unloaded (rather than refuse the module unload)? |
|
@oranagra I thought about that, but I saw that returned an error when blocked_clients was not empty, and I gave up on that idea. |
|
@oranagra in the test case, deleting the timer directly would cause the memory leaks as well, to the ones were held by the parameter. |
The keyname here is leaked? User data provided to the timer needs to be freed... RedisModuleString *keyname;
if (RedisModule_StopTimer(ctx, id, (void **) &keyname) == REDISMODULE_OK) {
RedisModule_FreeString(ctx, keyname); |
|
@zuiderkwast yes, in the case, if the timer was deleted automatically when the module unload, the user data would be leaked that would have been supposed to be handled at (https://github.com/redis/redis/blob/unstable/tests/modules/timer.c#L12) |
Co-authored-by: sundb <[email protected]>
|
triggered daily CI cycle for module tests: |
This is done to avoid a crash when the timer fires after the module was unloaded.
Or memory leaks in case we wanted to just ignore the timer.
It'll cause the MODULE UNLOAD command to return with an error
fix #10186