- 21 Jul, 2021 1 commit
-
-
Rob Snyder authored
Adds call to intrev16ifbe to ensure ZIPLIST_LENGTH is compared correctly (cherry picked from commit eaa52719)
-
- 10 May, 2019 1 commit
-
-
唐权 authored
Hi, @antirez In the code, to get the size of ziplist, "unsigned int bytes = ZIPLIST_HEADER_SIZE+1;" is correct, but why not make it more readable and easy to understand
-
- 03 Jul, 2018 1 commit
-
-
Jack Drogon authored
-
- 12 Jun, 2018 1 commit
-
-
antirez authored
-
- 07 Jun, 2018 1 commit
-
-
antirez authored
-
- 23 Feb, 2018 1 commit
-
-
antirez authored
-
- 16 Jan, 2018 1 commit
-
-
qinchao authored
, see issue: https://github.com/antirez/redis/issues/4587
-
- 01 Feb, 2017 2 commits
-
-
antirez authored
-
antirez authored
Ziplists had a bug that was discovered while investigating a different issue, resulting in a corrupted ziplist representation, and a likely segmentation foult and/or data corruption of the last element of the ziplist, once the ziplist is accessed again. The bug happens when a specific set of insertions / deletions is performed so that an entry is encoded to have a "prevlen" field (the length of the previous entry) of 5 bytes but with a count that could be encoded in a "prevlen" field of a since byte. This could happen when the "cascading update" process called by ziplistInsert()/ziplistDelete() in certain contitious forces the prevlen to be bigger than necessary in order to avoid too much data moving around. Once such an entry is generated, inserting a very small entry immediately before it will result in a resizing of the ziplist for a count smaller than the current ziplist length (which is a violation, inserting code expects the ziplist to get bigger actually). So an FF byte is inserted in a misplaced position. Moreover a realloc() is performed with a count smaller than the ziplist current length so the final bytes could be trashed as well. SECURITY IMPLICATIONS: Currently it looks like an attacker can only crash a Redis server by providing specifically choosen commands. However a FF byte is written and there are other memory operations that depend on a wrong count, so even if it is not immediately apparent how to mount an attack in order to execute code remotely, it is not impossible at all that this could be done. Attacks always get better... and we did not spent enough time in order to think how to exploit this issue, but security researchers or malicious attackers could.
-
- 30 Jan, 2017 1 commit
-
-
antirez authored
-
- 13 Jan, 2017 1 commit
-
-
antirez authored
-
- 19 Dec, 2016 1 commit
-
-
Justin Carvalho authored
-
- 16 Dec, 2016 2 commits
- 02 Jan, 2015 2 commits
-
-
Matt Stancliff authored
Freeing our test lists helps keep valgrind output clean
-
Matt Stancliff authored
This started out as #2158 by sunheehnus, but I kept rewriting it until I could understand things more easily and get a few more correctness guarantees out of the readability flow. The original commit created and returned a new ziplist with the contents of both input ziplists, but I prefer to grow one of the input ziplists and destroy the other one. So, instead of malloc+copy as in #2158, the merge now reallocs one of the existing ziplists and copies the other ziplist into the new space. Also added merge test cases to ziplistTest()
-
- 23 Dec, 2014 6 commits
-
-
Matt Stancliff authored
Valgrind can't detect 'memset' initializes things, so let's statically initialize them to remove some unnecessary warnings.
-
Matt Stancliff authored
The previous test wasn't returning the new ziplist, so the test was invalid. Now the test works properly. These problems were simultaenously discovered in #2154 and that PR also had an additional fix we included here.
-
Matt Stancliff authored
It's valid to delete from negative offsets, so we *don't* want unsigned arguments here.
-
Matt Stancliff authored
zipEntry was returning a struct, but that caused some problems with tests under 32 bit builds. The tests run better if we operate on structs allocated in the caller without worrying about copying on return.
-
Matt Stancliff authored
Previously, many files had individual main() functions for testing, but each required being compiled with their own testing flags. That gets difficult when you have 8 different flags you need to set just to run all tests (plus, some test files required other files to be compiled aaginst them, and it seems some didn't build at all without including the rest of Redis). Now all individual test main() funcions are renamed to a test function for the file itself and one global REDIS_TEST define enables testing across the entire codebase. Tests can now be run with: - `./redis-server test <test>` e.g. ./redis-server test ziplist If REDIS_TEST is not defined, then no tests get included and no tests are included in the final redis-server binary.
-
Matt Stancliff authored
Only happen when compiled with the test define.
-
- 29 Sep, 2014 2 commits
-
-
Xiaojie Zhang authored
Closes #1523
-
Matt Stancliff authored
- Remove trailing newlines from redis.conf - Fix comment misspelling - Clarifies zipEncodeLength usage and a C API mention (#1243, #1242) - Fix cluster typos (inspired by @papanikge #1507) - Fix rewite -> rewrite in a few places (inspired by #682) Closes #1243, #1242, #1507
-
- 08 Aug, 2014 1 commit
-
-
Xiaojie Zhang authored
Closes #1519
-
- 19 Aug, 2013 1 commit
-
-
antirez authored
Also a warning was suppressed by including unistd.h in redisassert.h (needed for _exit()).
-
- 28 Jan, 2013 1 commit
-
-
Pierre Chapuis authored
-
- 19 Nov, 2012 1 commit
-
-
charsyam authored
-
- 08 Nov, 2012 1 commit
-
-
antirez authored
-
- 13 Aug, 2012 2 commits
-
-
Pieter Noordhuis authored
-
Pieter Noordhuis authored
-
- 18 Jul, 2012 1 commit
-
-
antirez authored
For the C standard char can be either signed or unsigned, it's up to the compiler, but Redis assumed that it was signed in a few places. The practical effect of this patch is that now Redis 2.6 will run correctly in every system where char is unsigned, notably the RaspBerry PI and other ARM systems with GCC. Thanks to Georgi Marinov (@eesn on twitter) that reported the problem and allowed me to use his RaspBerry via SSH to trace and fix the issue!
-
- 14 Jun, 2012 1 commit
-
-
antirez authored
Because Redis 2.6 introduced new integer encodings it is no longer true that if two entries have a different encoding they are not equal. An old ziplist can be loaded from an RDB file generated with Redis 2.4, in this case for instance a small unsigned integers is encoded with a 16 bit encoding, while in Redis 2.6 a more specific 8 bit encoding format is used. Because of this bug hashes ended with duplicated values or fields lookup failed, causing many bad behaviors. This in turn caused a crash while converting the ziplist encoded hash into a real hash table because an assertion was raised on duplicated elements. This commit fixes issue #547. Many thanks to Pinterest's Marty Weiner and colleagues for discovering the problem and helping us in the debugging process.
-
- 06 May, 2012 1 commit
-
-
Pieter Noordhuis authored
Because of the introduction of new integer encoding types for ziplists in the 2.6 tree, the same integer value may have a different encoding in different versions of the ziplist implementation. This means that the encoding can NOT be used as a fast path in comparing integers.
-
- 24 Apr, 2012 4 commits
-
-
antirez authored
-
antirez authored
1) One integer "immediate" encoding that can encode from 0 to 12 in the encoding byte itself. 2) One 8 bit signed integer encoding that can encode 8 bit signed small integers in a single byte. The idea is to exploit all the not used bits we have around in a backward compatible way.
-
antirez authored
-
Grisha Trubetskoy authored
fit in 24 bits (thanks to antirez for catching and solving the two's compliment bug). Increment REDIS_RDB_VERSION to 6
-
- 23 Mar, 2012 1 commit
-
-
antirez authored
-
- 14 Feb, 2012 1 commit
-
-
antirez authored
-