Fixing potential buffer overflows when using the bitop shift and cron commands, as well as comparing ACL user passwords in constant time.
Former-commit-id: 3c716ee33d2d14d517271b674dd57c8328d14522
The change does 3 things:
1. It limits RocksDB to 256 file descriptors instead of unlimited
2. It includes the fd limit in its estimation for total file descriptors needed
3. It raises the system fd limit if possible before we open rocksdb but accounting for the 256 limit we added
Former-commit-id: 1447288209c5e7daf8a1203511fc262500ebe5e1
This affects later distribution of clients among threads if there had been many connection attempts during loading phase.
Former-commit-id: 889bcd1bf1adeb246af04bbeb7f9e51c0c4eff1b
The execution of the RPOPLPUSH command by the fuzzer created junk keys,
that were later being selected by RANDOMKEY and modified.
This also meant that lists were statistically tested more than other
files.
Fix the fuzzer not to pass junk key names to RPOPLPUSH, and add a check
that detects that new keys are not added by the fuzzer to detect future
similar issues.
(cherry picked from commit 3f3f678a4741e6af18230ee1862d9ced7af79faf)
this means the assertion that checks that when deep sanitization is enabled,
there are no crashes, was missing.
(cherry picked from commit 3db0f1a284e4fba703419b892b2d5b8d385afc06)
This was recently broken in #9321 when we validated stream IDs to be
integers but did that after to the stepping next record instead of before.
(cherry picked from commit 5a4ab7c7d2da1773c5ed3dcfc6e367b5af03a33e)
A write request may be paused unexpectedly because `server.client_pause_end_time` is old.
**Recreate this:**
redis-cli -p 6379
127.0.0.1:6379> client pause 500000000 write
OK
127.0.0.1:6379> client unpause
OK
127.0.0.1:6379> client pause 10000 write
OK
127.0.0.1:6379> set key value
The write request `set key value` is paused util the timeout of 500000000 milliseconds was reached.
**Fix:**
reset `server.client_pause_end_time` = 0 in `unpauseClients`
(cherry picked from commit f560531d5b8a6e6d810b62114e69a5ffda7730f7)
When a replica paused, it would not apply any commands event the command comes from master, if we feed the non-applied command to replication stream, the replication offset would be wrong, and data would be lost after failover(since replica's `master_repl_offset` grows but command is not applied).
To fix it, here are the changes:
* Don't update replica's replication offset or propagate commands to sub-replicas when it's paused in `commandProcessed`.
* Show `slave_read_repl_offset` in info reply.
* Add an assert to make sure master client should never be blocked unless pause or module (some modules may use block way to do background (parallel) processing and forward original block module command to the replica, it's not a good way but it can work, so the assert excludes module now, but someday in future all modules should rewrite block command to propagate like what `BLPOP` does).
(cherry picked from commit 1b83353dc382959e218191f64d94edb9703552e3)
