Кресты / Говнокод #27267 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
#include <iostream>
#include <ctime>
using namespace std;

#define SIZE 200000000

struct StackRazrivator {
	int data[SIZE];
};

void razorvi() {
	cout << "nachinau razrivat\n";
	StackRazrivator r;
}

void razrivator() {
	cout << "razrivator\n";
	razorvi();
}

int main() {
    cout << "start" << endl;
	razrivator();
	return 0;
}

Что выведет программа, если скомпилировать без оптимизаций и почему?

https://godbolt.org/z/75Yzer

Запостил: 3_dar 3_dar, (Updated )

Комментарии (64) RSS

  • а какой размер стека в той среде, где она будет выполнятьс?

    с оптимизацией наверное она выеинет нахуй твой разрыватор, и ничего не разорвет
    а без оптимизации может в теории и порваца, не?
    Ответить
    • > без оптимизации может в теории и порваца

      На винде должен порваться т.к. chkstk пойдёт протыкивать страницы палочкой.

      На прыщах, мне кажется, нет. Просто RSP уменьшится на 200кк, потом вернётся обратно. Надо какой-нибудь лог вывести после разрыватора, тогда порвёт.
      Ответить
      • а если добавлю коньструктор типа "data{0}", то порвеца и на прыще? *

        *при условии, что компилятор писание это не выкинет нахцй

        pps: проверил на прыще, segfault там
        Ответить
        • > проверил на прыще, segfault там

          Стек протектор сработал:

          orq $0x0,(%rsp)

          Тоже по страничке протыкивает, получается.
          Ответить
        • Забавно, что на годболте нету этой проверки.

          Стек рвётся из-за того, что весь фрейм резервируется сразу, а потом вызывается operator <<.
          Ответить
          • -fstack-clash-protection за это отвечает. С ним протыкивает странички по одной, как виндовый chkstk.
            Ответить
    • Разумеется, рассматривается случай, когда стек рвётся. Ссылка на годболт прикреплена.
      Ответить
      • К слову, для таких логов лучше юзать std::endl вместо "\n". Он буфер флашит.
        Ответить
        • Ты довольно долго отсутствовало. Нам без тебя было ничем не хуже.
          Сделай милость, обидься и уйди, хлопнув дверью.
          Ответить
        • А что, после сегфолта деструктор не вызывается, который пофлашит буфер? /color
          Ответить
          • а, так шутка в том, что что-то не успеет попасть в stdout, а что-то попадет, потому что компилятор поменяет местами вызоы?
            Ответить
            • 17 строка не вывелась потому что застряла в буфере. Если поменяешь \n на endl её будет видно.

              12 строка не вывелась потому что до нее управление реально не дошло. Место под фрейм выделилось в самом начале функции (конструкторы всегда срабатывают вовремя, а вот место может выделиться сразу). И вызов << упал от вылета за стек. Ну или прям во время выделения места сработал stack protector, если опция была включена.
              Ответить
              • Про 12ю интересно. При входе во фрейм он сразу выделил ему достаточное количество места в стеке, попал ногой в говно, и умер, верно?

                Иными словами, я могу разбрасывать автоматические переменные по всему блоку, но указатель стека крутанется сразу?

                с89 в этом плане честнее, конечно
                Ответить
                • Если стек протектор включен: выделил фрейм, протыкал странички до защитной, напоролся неё и упал.

                  Если стек протектор выключен: выделил фрейм, начал сохранять текущий адрес перед вызовом << и упал. Но мог и не упасть, а писнуть в чужую память. Раз на раз не приходится.
                  Ответить
                • > но указатель стека крутанется сразу

                  Ну это просто оптимизация такая. Нафиг нужны лишние сложения и вычитания, если достаточно одного в начале и одного в конце.

                  Ничто не обязывает конпелятор делать именно так. И на других всё может быть по-другому.
                  Ответить
    • Добрый день, сегфолт!
      Сегфолт говорит: "Здравтвуй"
      Ответить
  • > Что выведет программа, если скомпилировать без оптимизаций и почему?

    А это где-то определено? Например что вывод на консоль должен фактически завершиться раньше, чем будет вызвана вложенная функция (program order-то при этом не нарушается, главное только порядок вывода сообщений на сосноль). Без оптимизаций - это не в режиме интерпретатора.
    Ответить
    • На 89% уверен, что нигде не определено.
      Если ты писнул в буфер, и не влашнул его, а потом упала программа, то гарантий нет
      Ответить
    • Любой краш это UB. А при UB ничего не определено.

      Крестобляди соснули.
      Ответить
      • а какой-то есть язык, где смерть процесса дает какие-то гарантии?
        Ответить
    • > режиме интерпретатора

      Как-будто в интерпретаторах этой проблемы с флашем при смерти проги нет. Тоже запросто могут оборвать вывод на середине.
      Ответить
      • теоретически можно флашить каждый символ (быстро будет работать!), но если ты пишешь не в файл, то ос наверное не обязана вот прямо сразу чото куда-то рисовать
        Ответить
        • Ну да, и эмулятор терминала поди не обязан вычитывать последние слова проги если пайп порвался. Т.е. я даже за флаш то не уверен...
          Ответить
          • А блин, EPIPE только на write() можно получить. read() обрыв трубы просто как EOF обрабатывает.
            Ответить
            • а, ну тогда флашнет

              А обязан-ли? А если пол байта считал? А если ты пишешь в псевдотерминал? или опхуй?
              Ответить
              • > пол байта

                Хер знает... Я где-то здесь постил багу про усб-ком адаптер, который проёбывал хвост пакета если его закрыть.
                Ответить
    • > disable hyper threading

      Мало было потери пирфоманса от патчей против спектры, осталось добить отключением половины ядер...
      Ответить
    • Или оффтопь в другое место, здесь для другого тред.
      Ответить
      • Я уж подумал, что это тот крымский орк с Яхве Мацы теперь про ляликс пишет

        А так хуйня какая-то: не лочьте версии, а то бабайка придёт
        Ответить
        • нет, жырный лялха не трогает, слва богу

          чего хуйня?

          Вот например вышла новая версия libFOO, в которой залатали уязвимость

          В кклассическом юниксе админ обновил либу, и ссыт спокойно

          А с этими вашими локфайлами, докерами, снапами, и прочими "go" он лапу сосет, пока 30 вендоров не обновят либу


          Я не говорю, что это всегда лучше. Но есть трейдоф определенный
          Ответить
          • Если там только уязвимость поправили, то это хорошо.

            А если там добавили, убрали и поменяли перделок?
            Ответить
            • У хороших либ есть стабильные версии, в которых только баги да уязвимости фиксят.

              Проблема в том, что это дорого для разраба либы. Особенно если он хочет регулярно выкатывать новые фичи. И многие из них забивают хуй и поддерживают только последнюю версию. И вот тут-то у юзера и начинаются проблемы -- он не может получить фикс без новых фич. Такой версии либы тупо не существует. И никакие локи-хуёки его не спасут.
              Ответить
              • Откровенно говоря, а сколько там тех либ на линуксе, в которых уязвимости страшны? Крипта, а что ещё?
                Ответить
                • любая либа, которая имеет отношение к юзер инпуту

                  сраные модули к сраному вордпрессу с скулинъекциями могут тоже как либы в линуксе распостраняться
                  Ответить
                • А как это зависит от назначения либы?

                  Если в либу пролезло какое-нибудь переполнение буфера (на сишке) или sql/eval инъекция (на скриптушне), то совершенно похуй чем она занималась.

                  Плюс очень много либ работает с недоверенными данными -- картинки, видео, архивы, книжки, сетевые протоколы...
                  Ответить
                  • Броманд, что ты думаешь про ссылку-то?
                    Согласен с оратором, или категорически нет?
                    Ответить
                    • А хуй знает, я не читал статью, я просто посраться пришёл 😉
                      Ответить
                      • tl;tr

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

                          Я как раз таки за такую модель, когда приложуха по-минимуму зависит от системы. В идеале только от ядра или каких-то очень стабильных либ, как в винде.

                          Если мейнтейнер снапа/контейнера/статикпроги не умеет в секьюрити, ну, возможно, не стоит его софт юзать?
                          Ответить
                          • на винде ничто не мешает тебе ставить редистрибьютибл CRT, а уж во времена до SxS так и вовсе срать в system32

                            но в целом кульутура шареных либ там меньше, бо нет репозитория

                            А у меня нет строгого мнения, я вижу плюсы и в одном, и в другом подходе. Но в целом, большинство программистов похоже согласно с тобой, а не с автором
                            Ответить
                            • Просто тут я наверное больше смотрю с точки зрения разработчика: отсутствие фиксированных версий может ненароком порвать пердак при невинном pod update
                              Ответить
                              • разумеется.

                                разрабу вообще приятнее вручную выбрать нужные версии, протестировать всё 20 раз, и ровно их и отдать пользователю

                                а админу наоборот хочется обновить openssl не трогая разраба
                                Ответить
                                • Ну кстати, мейнтейнеры же обычно собирают всё сами, получая от разрабов только сырцы. Т.е. пересобрать контейнеры или снапы им не составит труда. Админ разницы особо не заметит.

                                  Проблема тут в том, что они не хотят и не могут патчить 100500 разных версий библиотеки, которая юзается в этих снапах. Именно поэтому у них так горит от локов на версию. Именно поэтому они хотят иметь всего 1-2 на всю систему.

                                  В случае с openssl это довольно легко т.к. её разрабы понимают что такое поддержка. В случае со скриптопарашей это нереально.
                                  Ответить
                                  • > со скриптопарашей

                                    Да и с крестами в общем-то. Попробуй тот же буст обновить без пересборки всего софта, который его юзает. Не уверен, что это прокатит.
                                    Ответить
                                  • мейнтейнеры могут и на каникулы уйти

                                    проблему с разными версиями я понял, тут конечно сосат6
                                    Ответить
                • Факапы у всех случаются, угу.

                  Но блин, что для glibc факап, то для скриптуха на руби или питоне -- образ жизни.
                  Ответить
                • Ахаха. Даже не открывая: постгресники сожрали говна там, где не мог вообще никто.
                  Ответить
                  • > Due to this our production Postgres database started work very slowly

                    ну естественно, проблема здесь в локалях
                    Ответить
          • > А с этими вашими локфайлами, докерами, снапами, и прочими "go" он лапу сосет, пока 30 вендоров не обновят либу

            Да это пофиг, перелочить все зависимости на пофиксанную версию да пересобрать контейнер/снап -- не такая уж проблема.

            Корень зла в том, что такой версии нет. Её физически нет. А свежую пофиксанную воткнуть вместо неё нельзя потому что всё пидорасит. Вот она плата за быструю доставку изменений.
            Ответить
            • это не проблема, если ты автор софта

              >версии нет
              это еще бОльший пиздец
              Ответить
              • > это еще бОльший пиздец

                Угу. Но это именно то, что пропагандируют адепты локов: мы не осилили обратную совместимость, поэтому у нас есть одна поддерживаемая версия -- последняя.
                Ответить
    • Иди оффтопь в другое место, здесь для другого тред.
      Ответить

Добавить комментарий

Из-за тебя ушел bormand, guest!

    А не использовать ли нам bbcode?


    8