antirez

#include <stdio.h>

int main(void) {
    int c;
    printf("char *cset = \"");
    for (c = 'A'; c <= 'Z'; c++) printf("%c",c);
    for (c = 'a'; c <= 'z'; c++) printf("%c",c);
    for (c = '0'; c <= '9'; c++) printf("%c",c);
    printf("-_\";\n");
    return 0;

antirez

/tmp ➤ gcc foo.c -m32
/tmp ➤ ./a.out
one offset: 0
two offset: 4
three offset: 12
/tmp ➤ cat foo.c
#include <stdio.h>
#include <stdint.h>

struct foo {

antirez

127.0.0.1:6379> debug
(error) ERR You must specify a subcommand for DEBUG. Try DEBUG HELP for info.
127.0.0.1:6379> debug help
 1) DEBUG <subcommand> arg arg ... arg. Subcommands:
 2) segfault -- Crash the server with sigsegv.
 3) restart  -- Graceful restart: save config, db, restart.
 4) crash-and-recovery <milliseconds> -- Hard crash and restart after <milliseconds> delay.
 5) assert   -- Crash by assertion failed.
 6) reload   -- Save the RDB on disk and reload it back in memory.
 7) loadaof  -- Flush the AOF buffers on disk and reload the AOF in memory.

antirez

Hello and thanks for reading,

I've a Redis pull request that no longer applies because, for example, one line where there was a < b is now a > b, otherwise the patch would apply cleanly.

if I try to cherry pick the commit and resolve the conflicts, it works, it's just a lot of useless work editing the conflicting code to merge properly and there is even the risk of making mistakes.

An alternative is to:

1. Modify back the source code to a < b with a commit called FOO.

antirez

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
#include <string.h>

#define C_OK 1
#define C_ERR 0

typedef struct clusterNode {

antirez

diff --git a/src/ae.c b/src/ae.c
index 63a1ab4..79fcde6 100644
--- a/src/ae.c
+++ b/src/ae.c
@@ -221,21 +221,12 @@ long long aeCreateTimeEvent(aeEventLoop *eventLoop, long long milliseconds,
 
 int aeDeleteTimeEvent(aeEventLoop *eventLoop, long long id)
 {
-    aeTimeEvent *te, *prev = NULL;
-

antirez

11822:M 16 Dec 09:20:15.613 # --- STACK TRACE
./redis-server *:6379(debugCommand+0x278)[0x459228]
./redis-server *:6379(logStackTrace+0x35)[0x459ce5]
./redis-server *:6379(sigsegvHandler+0xac)[0x45a25c]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f0de4c7d340]
./redis-server *:6379(debugCommand+0x278)[0x459228]
./redis-server *:6379(call+0x85)[0x421e15]
./redis-server *:6379(processCommand+0x39f)[0x424f9f]
./redis-server *:6379(processInputBuffer+0x97)[0x431927]
./redis-server *:6379(aeProcessEvents+0x250)[0x41c2f0]

antirez

QSTAT foo
 1) "name"
 2) "foo"
 3) "len"
 4) (integer) 0
 5) "age"
 6) (integer) 95
 7) "idle"
 8) (integer) 1
 9) "blocked"

antirez

Dear white hat attackers,

recently we observed a number of Redis instances that were targeted by a simple attack, consisting in setting a password using the CONFIG SET requirepass <password> command to instances which are left open on the internet.

This is, in my opinion, a good idea, since those Redis instances are going to be cracked anyway. I believe you are doing this in order to make Redis users aware they forgot to setup firewalling rules in order to make their instances not reachable from the outside.

antirez

    1) D-dcb833cf-8YL1NT17e9+wsA/09NqxscQI-05a1A$
    2) D-dcb833cf-RhKQ0BUwMGdystmSEqu+/t9R-05a0A$
    3) D-dcb833cf-u2k9/Rjd3ZLh4TbUFCAf367+-05a0A$
    4) D-dcb833cf-axzAwPMGBuogYEg6Omgrq090-05a1A$
    5) D-dcb833cf-BAe19SOtreohIX2Dw+oCwpyF-05a1A$
    6) D-dcb833cf-nHddnVDYmKccnIvkZH/2dr7S-05a0A$
    7) D-dcb833cf-kojYmJHjI9z+/nhqqpZp6WHK-05a0A$
    8) D-dcb833cf-UulLy4HQ0BjNTeHZWdwqqgC+-05a0A$
    9) D-dcb833cf-5BLNjZ55uT2raxvFBd9ERHoV-05a0A$
   10) D-dcb833cf-zsYLCz72dkSy8nahYat0tBmZ-05a0A$