~axino/redis/+git/trunk:2.8

Last commit made on 2019-09-02
Get this branch:
git clone -b 2.8 https://git.launchpad.net/~axino/redis/+git/trunk

Branch merges

Branch information

Name:
2.8
Repository:
lp:~axino/redis/+git/trunk

Recent commits

eb5e35b... by Salvatore Sanfilippo <email address hidden>

Merge pull request #6326 from yunsou/yunsu-2.8

Fix to dict int problem at 2.8 version

6a439c9... by Lee Yunsu <email address hidden>

update dict.c

fix to https://github.com/antirez/redis/issues/4493 at 2.8 version

4a63c44... by Lee Yunsu <email address hidden>

update dict.h

fix to [#4493](https://github.com/antirez/redis/issues/4493) at 2.8 version

b2ab1e0... by antirez <email address hidden>

Remove Lua state reference from buffers in lua_cmsgpack.

42cb422... by Yoav Steinberg

cmsgpack: pass correct osize values to lua allocator, update correct buf free space in cmsgpack

32535ff... by antirez <email address hidden>

Redis 2.8.24

0d58155... by antirez <email address hidden>

Fix CMD_DENYOOM macro name after backporting.

e0b7388... by antirez <email address hidden>

Fix a race that may lead to the active (slave) client to be freed.

In issue #2948 a crash was reported in processCommand(). Later Oran Agra
(@oranagra) traced the bug (in private chat) in the following sequence
of events:

1. Some maxmemory is set.
2. The slave is the currently active client and is executing PING or
   REPLCONF or whatever a slave can send to its master.
3. freeMemoryIfNeeded() is called since maxmemory is set.
4. flushSlavesOutputBuffers() is called by freeMemoryIfNeeded().
5. During slaves buffers flush, a write error could be encoutered in
   writeToClient() or sendReplyToClient() depending on the version of
   Redis. This will trigger freeClient() against the currently active
   client, so a segmentation fault will likely happen in
   processCommand() immediately after the call to freeMemoryIfNeeded().

There are different possible fixes:

1. Add flags to writeToClient() (recent versions code base) so that
   we can ignore the write errors, and use this flag in
   flushSlavesOutputBuffers(). However this is not simple to do in older
   versions of Redis.
2. Use freeClientAsync() during write errors. This works but changes the
   current behavior of releasing clients ASAP when possible. Normally
   we write to clients during the normal event loop processing, in the
   writable client, where there is no active client, so no care must be
   taken.
3. The fix of this commit: to detect that the current client is no
   longer valid. This fix is a bit "ad-hoc", but works across all the
   versions and has the advantage of not changing the remaining
   behavior. Only alters what happens during this race condition,
   hopefully.

2478790... by antirez <email address hidden>

Log address causing SIGSEGV.

01173bc... by Sun He <email address hidden>

lua_struct.c/getnum: throw error if overflow happen

Fix issue #2855