diff options
| author | ranshid <88133677+ranshid@users.noreply.github.com> | 2023-02-26 11:54:29 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-02-26 11:54:29 +0200 |
| commit | 4972760b67e793413ff885d1e05c01627497d360 (patch) | |
| tree | 0336ec510d6148c7c985a208631323229e488166 | |
| parent | c8226ae37875da285ebedeef78ced87666ca1be7 (diff) | |
| download | redis-4972760b67e793413ff885d1e05c01627497d360.tar.gz | |
assert in case resize output buffer will attempt to shrink too much (#11839)
Currently there is no BUG. However during some internal code changes
I found that it can happen (for example in case new code will not update
the buf_peak) which can currently lead to memory overrun which is much
harder to detect and root cause.
Why did I please the assert here? The reason is to be able to have the
buf_peak value without the risk of it being overriden by the peak_reset
| -rw-r--r-- | src/server.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/src/server.c b/src/server.c index 5685cce6d..60522acb0 100644 --- a/src/server.c +++ b/src/server.c @@ -789,6 +789,8 @@ int clientsCronResizeOutputBuffer(client *c, mstime_t now_ms) { server.stat_reply_buffer_expands++; } + serverAssertWithInfo(c, NULL, (!new_buffer_size) || (new_buffer_size >= (size_t)c->bufpos)); + /* reset the peak value each server.reply_buffer_peak_reset_time seconds. in case the client will be idle * it will start to shrink. */ |