Skip to content
View cset.c
#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;
View align.c
/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 {
View debug.txt
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.
View Git question.md

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.
View fuzzer.c
#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 {
View ae.patch
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;
-
View gist:3cf6d701795f179e1a5b
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]
View QSTAT.txt
QSTAT foo
1) "name"
2) "foo"
3) "len"
4) (integer) 0
5) "age"
6) (integer) 95
7) "idle"
8) (integer) 1
9) "blocked"
View wh.md

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.

View IDs.txt
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$
Something went wrong with that request. Please try again.