Atualizar
Encontrei a linha em debug.c mencionada no OP e podemos ver em duas linhas acima deste código:
redisLog(REDIS_WARNING,"(forcing SIGSEGV to print the bug report.)");
e o mesmo código pode ser encontrado em
_redisPanic também, então parece que eles forçam um SIGSEGV quando uma afirmação falha ou há pânico. Original
Isso parece uma ferramenta de depuração, podemos ver neste documento o guia de depuração do Redis e a seção relevante diz:
O Redis tem um comando para simular uma falha de segmentação (em outras palavras, uma falha grave) usando o comando DEBUG SEGFAULT (não o use contra uma instância de produção real, é claro;). Então, usarei este comando para travar minha instância para mostrar o que acontece no lado do GDB:
e mostra esta saída gdb:
(gdb) continue
Continuing.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xffffffffffffffff
debugCommand (c=0x7ffc32005000) at debug.c:220
220 *((char*)-1) = 'x';
^^^^^^^^^^^^^^^^^^^
O que ele está fazendo é lançar
-1 para um *char ** e, em seguida, realizando a indireção nele e atribuindo 'x' para esse local de memória. Como o thread que alk linkou é ((void *) -1) um endereço válido? diz que na maioria dos sistemas não será válido acessar, muito menos atribuir um valor. Isso gerará uma falha de segmentação na maioria dos sistemas operacionais modernos. Este é um comportamento indefinido e como foi abordado no thread Qual é a maneira mais simples de conformidade padrão para produzir um Segfault em C? não pode ser invocado. Os compiladores estão ficando mais inteligentes e há alguns exemplos famosos em que o compilador é inteligente em explorar o comportamento indefinido de maneiras inesperadas e ruins.
