Можно ли предсказать переполнение стека в C в Linux?

The deprecated alloca() routine (like malloc(), but uses the stack, automatically frees itself, and also blows up with SIGSEGV if it's too big).

Почему alloca устарела?

Во всяком случае, насколько быстрее в вашем случае alloca vs malloc? (Стоит ли оно того?)

И разве вы не вернете null из alloca, если не хватит места? (так же, как malloc?)

А когда происходит сбой вашего кода, где он падает? это в alloca или в doStuff ()?

/ Йохан

Приносим извинения, если это констатирует очевидное, но вы можете легко написать функцию для проверки определенного размера выделения стека, просто попробовав alloca (такого размера) и перехватив исключение переполнения стека. Если вы хотите, вы можете поместить его в функцию с некоторой заранее определенной математикой для накладных расходов стека функций. Например:

bool CanFitOnStack( size_t num_bytes )
{
    int stack_offset_for_function = 4; // <- Determine this
    try
    {
        alloca( num_bytes - stack_offset_for_function );
    }
    catch ( ... )
    {
        return false;
    }

    return true;
}

alloca () будет возвращать NULL в случае сбоя, я считаю, что поведение alloca (0) не определено и является вариантом платформы. Если вы проверите это до do_something (), вы никогда не попадете под удар SEGV.

У меня есть пара вопросов:

1. Зачем, ну почему вам нужно что-то такое большое в стеке? Размер по умолчанию в большинстве систем составляет 8 МБ, это все еще слишком мало?
2. Если функция, вызывающая alloca (), блокируется, будет ли защита такого же количества кучи с помощью mlock () / mlockall () гарантировать примерно такую ​​же производительность доступа (например, «Не меняй местами, брат!») С течением времени? Если вы используете более агрессивный планировщик rt, его все равно рекомендуется вызывать.

Вопрос интересный, но поднимает бровь. Он поднимает стрелку моего квадратного колышка-круглого отверстия-о-метра.

Вы можете определить пространство стека, доступное процессу, найдя размер пространства стека процесса, а затем вычтя использованное количество.

ulimit -s

показывает размер стека в системе Linux. Для программного подхода см. getrlimit (). Затем, чтобы определить текущую глубину стека, вычтите указатель на верх стека из единицы в нижнюю. Например (непроверенный код):

unsigned char *bottom_of_stack_ptr;

void call_function(int argc, char *argv) {
    unsigned char top_of_stack;
    unsigned int depth = (&top_of_stack > bottom_of_stack_ptr) ? 
        &top_of_stack-bottom_of_stack_ptr : 
        bottom_of_stack_ptr-&top_of_stack;

    if ( depth+100 < PROGRAMMATICALLY_DETERMINED_STACK_SIZE ) {
        ...
    }
}

int main(int argc, char *argv) {
    unsigned char bottom_of_stack;
    bottom_of_stack_ptr = &bottom_of_stack;
    my_function();
    return 0;
}

Даже если это не прямой ответ на ваш вопрос, я надеюсь, вы знаете о существовании Valgrind - замечательного инструмента для обнаружения таких проблем во время выполнения в Linux.

Что касается проблемы стека, вы можете попытаться динамически выделить объекты из фиксированного пула, который обнаруживает эти переполнения. С помощью простого мастера макросов вы можете выполнить этот запуск во время отладки, с реальным кодом, работающим во время выпуска, и, таким образом, знать (по крайней мере, для сценариев, которые вы выполняете), что вы не берете слишком много. Вот дополнительная информация и ссылка к примерной реализации.

Функция alloca устарела. Однако его нет в POSIX, и он также зависит от машины и компилятора. На странице руководства Linux по alloca отмечается, что «для некоторых приложений его использование может повысить эффективность по сравнению с использованием malloc, а в некоторых случаях оно также может упростить освобождение памяти в приложениях, которые используют longjmp () или siglongjmp (). В противном случае, его использование не рекомендуется ".

В справочной странице также говорится, что «нет индикации ошибки, если кадр стека не может быть расширен. Однако после неудачного распределения программа, скорее всего, получит SIGSEGV».

Производительность malloc фактически упоминалась в Подкаст Stackoverflow # 36.

(Я знаю, что это неправильный ответ на ваш вопрос, но я все равно подумал, что это может быть полезно.)

Не уверен, что это применимо к Linux, но в Windows можно столкнуться с нарушениями доступа с большими выделениями стека даже если им это удастся!

Это связано с тем, что по умолчанию VMM Windows фактически отмечает только несколько верхних (не знаю, сколько именно) 4096-байтовых страниц ОЗУ стека как выгружаемые (т. Е. Поддерживаемые файлом подкачки), поскольку он считает, что доступ к стеку обычно идет вниз от вершина; по мере того, как доступ становится все ближе и ближе к текущей «границе», нижняя и нижняя страницы помечаются как листаемые. Но это означает, что раннее чтение / запись в память намного ниже вершины стека вызовет нарушение прав доступа, поскольку эта память фактически еще не выделена!

Я не могу придумать ничего хорошего. Может быть, это возможно с помощью getrlimit () (предложенного ранее) и некоторой арифметики указателей? Но сначала спросите себя, действительно ли вы этого хотите.

void *closeToBase;

main () {
  int closeToBase;
  stackTop = &closeToBase;
}

int stackHasRoomFor(int bytes) {
  int currentTop;
  return getrlimit(...) - (&currentTop  - closeToBase) > bytes + SomeExtra;
}

Лично я бы этого не сделал. Размещайте большие вещи в куче, стек не предназначен для этого.

Вы не очень много говорите о том, почему вы хотите выделять память в стеке, но если вам нравится модель памяти стека, вы также можете реализовать выделение стека в куче. Выделите большой кусок памяти в начале программы и сохраните стек указателей на него, который будет соответствовать кадрам в обычном стеке. Вам просто нужно не забыть вывести указатель личного стека при возврате функции.

Некоторые компиляторы, например Откройте Watcom C / C++, поддерживают функцию stackavail (), которая позволяет вам делать именно это.

Вы можете использовать GNU libsigsegv для ручка ошибки страницы, включая случаи, когда происходит переполнение стека (с его веб-сайта):

In some applications, the stack overflow handler performs some cleanup or notifies the user and then immediately terminates the application. In other applications, the stack overflow handler longjmps back to a central point in the application. This library supports both uses. In the second case, the handler must ensure to restore the normal signal mask (because many signals are blocked while the handler is executed), and must also call sigsegv_leave_handler() to transfer control; then only it can longjmp away.

Конец области стека определяется ОС динамически. Хотя вы можете найти «статические» границы стека, просмотрев области виртуальной памяти (VMA) в зависимости от ОС (см. Файлы stackvma * в libsigsegv / src /), вам дополнительно придется учитывать

• значения getrlimit,
• размер стека на поток (см. pthread_getstacksize)