Актуализиране
Намерих реда в debug.c, споменат в OP и можем да видим от два реда над този код:
redisLog(REDIS_WARNING,"(forcing SIGSEGV to print the bug report.)");
и същият код може да бъде намерен в _redisPanic също така, така че изглежда, че техният начин да наложат SIGSEGV когато едно твърдение се провали или има паника.
Оригинал
Това изглежда като инструмент за отстраняване на грешки, можем да видим от този документ ръководство за отстраняване на грешки на Redis и съответния раздел казва:
Redis има команда за симулиране на грешка при сегментиране (с други думи лош срив) с помощта на командата DEBUG SEGFAULT (разбира се, не я използвайте срещу реален производствен екземпляр;). Така че ще използвам тази команда за срив на моя екземпляр, за да покажа какво се случва в GDB страната:
и показва този 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';
^^^^^^^^^^^^^^^^^^^
Това, което прави, е прехвърляне на -1 към *char ** и след това извършване на индиректна посока върху него и присвояване на 'x' до това място в паметта. Тъй като нишката, която alk е свързана ((void *) -1) е валиден адрес? казва в повечето системи, че няма да е валидно за достъп, да не говорим за присвояване на стойност. Това ще генерира грешка при сегментиране на повечето съвременни операционни системи.
Това е недефинирано поведение и както беше разгледано в нишката Какъв е най-простият стандартен начин за създаване на Segfault в C? не може да се разчита. Компилаторите стават все по-умни и има някои известни примери, при които компилаторът е умен за използване на недефинирано поведение по неочаквани и лоши начини.
