Напишите кратчайший код, который вызывает ошибку сегментации (SIGSEGV) на любом языке программирования.
Напишите кратчайший код, который вызывает ошибку сегментации (SIGSEGV) на любом языке программирования.
Ответы:
main;
Это объявление переменной - int
тип подразумевается (функция скопирована с языка B) и 0
является значением по умолчанию. При выполнении это пытается выполнить число (числа не являются исполняемыми) и вызывает SIGSEGV
.
0
. static
переменные начинаются как 0
и main;
есть static
, как я объявил вне функции. c-faq.com/decl/initval.html
main
- это int, в котором он находится .bss
, обычно в нем находятся функции .text
, когда ядро загружает программу elf, для которой она создает исполняемую страницу .text
и не -executable для .bss
, поэтому, вызывая main, вы переходите на неисполняемую страницу, и выполнение чего-либо на такой странице является ошибкой защиты.
main __attribute__((section(".text#")))=0xc3;
FTFY (по крайней мере, он возвращается без сбоев на моем x86).
const main=195;
. Интересно то, что он работает, и задача этого гольф-кода заключалась в том, чтобы сделать код сегфоутом, а не работать :).
kill -11 $$
RET
Этот код segfaults.
exec'()'*7**6
Windows сообщает код ошибки c00000fd (переполнение стека), который, как я предполагаю, является подтипом ошибки сегментации.
Благодаря Алексу А. и Мего, подтверждается, что это также вызывает ошибки сегментации в системах Mac и Linux. Python является языком выбора для переносимого сбоя ваших программ.
Segmentation fault: 11
на Mac
Segmentation fault (core dumped)
на Linux
\def~#1{\meaning}\write0{\expandafter~\string}\bye
На самом деле это, вероятно, ошибка , но ее нет в оригинальной версии TeX, написанной Knuth: компиляция кода с использованием tex filename.tex
вместо pdftex filename.tex
не приводит к возникновению ошибки.
OBTW
Не работает онлайн, только в интерпретаторе C.
>>> import ctypes;ctypes.string_at(0)
Segmentation fault
Источник: http://bugs.python.org/issue1215#msg143236
>>> import sys;sys.setrecursionlimit(1<<30);f=lambda f:f(f);f(f)
Segmentation fault
Источник: http://svn.python.org/view/python/trunk/Lib/test/crashers/recursive_call.py?view=markup
Это версия Python, на которой я тестирую:
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
В общем, интерпретатор Python трудно сломать, но вышеизложенное - это избирательное оскорбление ...
main(){raise(11);}
int func()
. то есть функция, возвращающая int
, принимая неопределенные параметры. В этом случае raise
это функция, возвращающая int и принимающая аргумент int, так что это работает (даже если компилятор жалуется).
/(?{??})/
В 5.14 механизм регулярных выражений был повторно введен, так что он не мог быть аварийно завершен таким образом, но 5.12 и более ранние версии будут работать с ошибками, если вы попробуете это.
Это может показаться странным, но в 32-битных системах Windows создание и выполнение пустого .com-файла может вызвать segfault, в зависимости от ... чего-то. DOS просто принимает его (8086 не имеет управления памятью, нет значимых сегментов для сбоя), и 64-битная Windows отказывается его запускать (x86-64 не имеет режима v86 для запуска файла .com).
<.
Да, это зависит от реализации. SIGSEGV - вероятный результат от хорошего компилятора.
<
должно либо не иметь никакого эффекта, либо обернуться вокруг.
foreign import ccall main::IO()
Это создает segfault при компиляции с GHC и запуске. Флаги расширения не требуются, так как интерфейс внешних функций соответствует стандарту Haskell 2010.
C версия:
*(int*)0=0;
Вся программа (не совсем ISO-совместимая, давайте предположим, что это K & R C) имеет длину 19 символов:
main(){*(int*)0=0;}
Вариант ассемблера:
orl $0,0
Вся программа длиной 24 символа (только для оценки, так как она на самом деле не ассемблер):
main(){asm("orl $0,0");}
РЕДАКТИРОВАТЬ :
Пара вариантов C Первый использует нулевую инициализацию глобальной переменной указателя:
*p;main(){*p=0;}
Второй использует бесконечную рекурсию:
main(){main();}
Последний вариант самый короткий - 7 (15) символов.
РЕДАКТИРОВАТЬ 2 :
Придумал еще один вариант, который короче любого из вышеперечисленных - 6 (14) символов. Предполагается, что буквенные строки помещаются в сегмент только для чтения.
main(){*""=0;}
РЕДАКТИРОВАТЬ 3 :
И моя последняя попытка - 1 символ длиной:
P
Просто скомпилируйте это так:
cc -o segv -DP="main(){main();}" segv.c
main
это глобальная переменная int с нулевой инициализацией, поэтому мы получаем результат выполнения нескольких нулевых байтов. В x86 это будет что-то вроде add %al,(%rax)
идеальной инструкции, которая пытается получить доступ к памяти по адресу, сохраненному в %rax
. Шансы на хороший адрес там минимальны.
[dx0]dx
вызывает переполнение стека
[dx0]
сохраняет dx0
в стеке, затем d
дублирует верхний элемент стека, затем x
извлекает верхний элемент стека ( dx0
) и выполняет его. Который дублирует верхний элемент стека и начинает его выполнять ... 0
должен быть там, чтобы это не было хвостовым вызовом, чтобы они все накапливались.
Немного обманывающее решение состоит в том, чтобы сбрить один символ с хитрости Джои Адамса :
kill 11,$$
Тем не менее, чтобы получить реальный segfault в Perl, unpack p
это очевидное решение:
unpack p,1x8
Технически, это не гарантирует segfault, поскольку адрес 0x31313131 (или 0x3131313131313131 в 64-разрядных системах) может просто случайно указать на правильное адресное пространство. Но шансы против этого. Кроме того, если perl когда-либо портируется на платформы, где указатели длиннее 64 бит, x8
нужно будет увеличить.
1x8
вещь?
"11111111".
Obj.magic 0 0
При этом используется функция Obj.magic
, которая небезопасно приводит к любым двум типам. В этом случае он приводит 0 (сохраненный как непосредственное значение 1, из-за бита тега, используемого GC) к типу функции (сохраненный как указатель). Таким образом, он пытается разыменовать адрес 1, и это, конечно же, segfault.
it coerces 0 (stored as the immediate value 1)
- почему 0 хранится как 1?
Obj.magic()0
на один символ короче :)
Golfed
. $0
Рекурсивно включить скрипт в себя.
Разъяснения
Рекурсивная операция «source» (.) В конечном итоге вызывает переполнение стека, и, поскольку Bash не интегрируется с libsigsegv , это приводит к SIGSEGV.
Обратите внимание, что это не ошибка, а ожидаемое поведение, как описано здесь .
Контрольная работа
./bang
Segmentation fault (core dumped)
⌠[]+⌡9!*.
Если приведенное выше не дает сбоя, попробуйте увеличить число (многозначные числа указаны в поле «На самом деле с начальным двоеточием»)
Сбой интерпретатора, используя ошибку в python, включающую глубоко вложенные itertools.chain
объекты, которые фактически используются для реализации +
оператора.
System.Runtime.InteropServices.Marshal.ReadInt32(IntPtr.Zero);
unsafe{int i=*(int*)0;}
Необходимо скомпилировать с / unsafe, чтобы этот работал. По какой-то причине я не понимаю, *(int*)0=0
просто выдает исключение NullReferenceException, в то время как эта версия дает правильное нарушение доступа
int i=*(int*)0;
возвращает NullReferenceException для меня.
*(int*)-1=0
получить и получить нарушение прав доступа.
*(int*)0=0
генерируется исключение, скорее всего, связана с оптимизацией. В частности, чтобы избежать затрат на проверку null
, оптимизатор может удалить нулевые проверки, но когда происходит сбой, он может отбросить его как должное NullReferenceException
.
$ pil
: ('0)
Segmentation fault
Это намеренное поведение. Как описано на их сайте:
Если некоторые языки программирования претендуют на звание «Швейцарского армейского ножа программирования», то PicoLisp вполне можно назвать «Скальпелем программирования»: острый, точный, маленький и легкий, но в то же время опасный для руки неопытного.
real,pointer::p(:)=>null()
p(1)=0.
end
Компиляция:
gfortran segv.f90 -o segv
Исполнение:
./segv
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x7FF85FCAE777
#1 0x7FF85FCAED7E
#2 0x7FF85F906D3F
#3 0x40068F in MAIN__ at segv.f90:?
Erreur de segmentation (core dumped)
материалы:
gfortran --version
GNU Fortran (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
main(a){*(&a-1)=1;}
Он искажает значение адреса возврата основной функции, поэтому он возвращает SIGSEGV при возврате main
.
(это становится темой для меня, возможно, потому что это единственный язык, который я знаю, что никто другой здесь не делает.)
inc(r0)
Увеличивает единичный байт, адресуемый начальным значением r0 [которое, по данным отладчика simh, равно 05162] при запуске программы.
0000000 000407 000002 000000 000000 000000 000000 000000 000000
0000020 005210 000000
И, как всегда, посторонние байты на конце могут быть удалены с помощью полосы.
Я сделал несколько попыток сократить исходный код, но всегда получал либо ошибку синтаксиса, либо SIGBUS.
В ответ на мой вопрос Амро придумал такую причуду:
S = struct();
S = setfield(S, {}, 'g', {}, 0)
clear()
Удаляет абсолютно все, не только текущую область видимости, которая, очевидно, приводит к большому количеству ошибок, что приводит к взрыву и сбою JS
j1Z
В этой части я объясню, как я пришел с этим ответом, за исключением того, что я не имею ни малейшего понятия . Если бы кто-нибудь мог объяснить это для меня, я был бы благодарен.
объяснение
j
возводит в квадрат базу и вызывает себя рекурсивно, пока база не станет хотя бы такой же большой, как число. Поскольку база равна 0 , этого никогда не происходит. При достаточно высоком рекурсивном пределе вы получаете ошибку сегмента.
j
на 1
и 0
, который пытается преобразовать 1
в базу 0
. Почему это segfaults, я понятия не имею ...