Mettre à jour
J'ai trouvé la ligne dans debug.c mentionnée dans l'OP et nous pouvons voir à partir de deux lignes au-dessus de ce code :
redisLog(REDIS_WARNING,"(forcing SIGSEGV to print the bug report.)");
et le même code peut être trouvé dans _redisPanic aussi, donc il semble que leur façon de forcer un SIGSEGV lorsqu'une assertion échoue ou qu'il y a une panique.
Original
Cela ressemble à un outil de débogage, nous pouvons voir dans ce document le guide de débogage Redis et la section pertinente indique :
Redis a une commande pour simuler un défaut de segmentation (en d'autres termes un mauvais crash) en utilisant la commande DEBUG SEGFAULT (ne l'utilisez pas contre une vraie instance de production bien sûr;). Je vais donc utiliser cette commande pour planter mon instance afin de montrer ce qui se passe du côté GDB :
et affiche cette sortie 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';
^^^^^^^^^^^^^^^^^^^
Ce qu'il fait est de lancer -1 à un *char ** puis en effectuant une indirection sur celui-ci et en lui attribuant 'x' à cet emplacement mémoire. En tant que fil de discussion lié à Alk, est-ce que ((void *) -1) est une adresse valide ? indique que sur la plupart des systèmes, il ne sera pas valide d'y accéder, et encore moins d'attribuer une valeur à. Cela générera une erreur de segmentation sur la plupart des systèmes d'exploitation modernes.
Il s'agit d'un comportement indéfini et, comme cela a été expliqué dans le fil, quelle est la manière la plus simple de se conformer à la norme pour produire une erreur de segmentation en C? on ne peut pas s'y fier. Les compilateurs deviennent de plus en plus intelligents et il existe des exemples célèbres où le compilateur est intelligent pour exploiter un comportement indéfini de manière inattendue et mauvaise.
