@rustlang_ru - страница 965

Vladimir

ошибка программного обеспечения, возникающая при попытке обращения к недоступным для записи участкам памяти либо при попытке изменения памяти запрещённым способом.

Маjко

Стек офверфлоу это выход за пределы памяти стека. Определеление ошибки сегментации, по сути.

big

ну это уже как запрограммировать ) стековерфлоу может быть сегфолтом (как в данном случае), а может и не быть — пример — без стекпробов/гуардпейджей

big

Стек офверфлоу это выход за пределы памяти стека. Определеление ошибки сегментации, по сути.

первое — да, второе — нет. для этого и нужны стекпробы

big

чтобы при выходе из области стека ограничить ушерб

Denis

С каких пор?

https://en.wikipedia.org/wiki/Segmentation_fault#Stack_overflow

big

без стекбробов будет возможен т.н. stack clashing

Маjко

Стекпроб как метод защиты по сути не меняет сути того, что ошибка происходит из-за нарушения границ памяти стека.

Маjко

Проб его детектит просто раньше)

big

Стекпроб как метод защиты по сути не меняет сути того, что ошибка происходит из-за нарушения границ памяти стека.

представь случай что у тебя вообще нету MMU.

Маjко

представь случай что у тебя вообще нету MMU.

Плохо будет

big

и единое адресное пространство. Stackoverflow есть, segfault нета )

Alexey

дык я не понял, это нормально, что растопрога схлопывается даже мяв сказать не успев? какое поведение нормальное, когда abort с коркой, или когда сегфолт с коркой?

Alexey

и почему на некоторых системах одно поведение, а на других другое? причем всегда одинаковое.

big

дык я не понял, это нормально, что растопрога схлопывается даже мяв сказать не успев? какое поведение нормальное, когда abort с коркой, или когда сегфолт с коркой?

происходит переполнение стека и програма завершается. В целом это "нормально", альтернативы это не делать защиту и просто дать программе закораптить память (в итоге — stack clashing). Или фрейм стека открывать сразу на хипе (убьет производительность). про abort я так понимаю это про мой кейс? Я так понимаю, там нету вызова abort как такового. Это просто OS X / мой шел так пишет. Кроме того, в моем случае core dump'а небыло. В любом случае, это все зависит от системы, как она ловит ошибки доступа в целом или как она ловит ошибки доступа к стеку в частности. Как я уже замечал, у системы вообще возможно не будет возможности отловить такую проблему (представьте себе маленький микроконтролер без MMU или просто WASM ) )

Victor

происходит переполнение стека и програма завершается. В целом это "нормально", альтернативы это не делать защиту и просто дать программе закораптить память (в итоге — stack clashing). Или фрейм стека открывать сразу на хипе (убьет производительность). про abort я так понимаю это про мой кейс? Я так понимаю, там нету вызова abort как такового. Это просто OS X / мой шел так пишет. Кроме того, в моем случае core dump'а небыло. В любом случае, это все зависит от системы, как она ловит ошибки доступа в целом или как она ловит ошибки доступа к стеку в частности. Как я уже замечал, у системы вообще возможно не будет возможности отловить такую проблему (представьте себе маленький микроконтролер без MMU или просто WASM ) )

вообще, как я понял, вопрос был в том почему в одних случаях программа перехватывает сигнал, пишет красивое "Чао" в виде "thread 'main' has overflowed its stack fatal runtime error: stack overflow Aborted" и крэшится, а на некоторых системах просто валится с выводом стандартного "Segmentation fault".

big

а, имеет смысл

big

т.е. есть утверждение что thread 'main' has overflowed its stack это пишет раст

big

да, действительно, это rust пишет

Victor

полагаю что так. Врятли система бы угадала что ошибка в трэде "main"

big

https://github.com/rust-lang/rust/blob/a559452b05c20041a27f518d262573c56b876b64/src/libstd/sys/unix/stack_overflow.rs#L100

big

вот для windows https://github.com/rust-lang/rust/blob/b1363a73ede57ae595f3a1be2bb75d308ba4f7f6/src/libstd/sys/windows/stack_overflow.rs#L38

big

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

big

я могу предположить: - старый компилятор (пальцем в небо, но мб где-то 1.20 может сегфолтить, а 1.21 уже нет) - не Intel

big

@I_vlxy_I а есть возможность узнать ^^^ ?

Alexey

я могу предположить: - старый компилятор (пальцем в небо, но мб где-то 1.20 может сегфолтить, а 1.21 уже нет) - не Intel

Intel. 1.21.1

Alexey

Ой. 1.22.1 даже

big

Alexey

x86_64

Loo

eee

Safort

Всё встаёт на свои места.

Vlad

> Faster Project Search Tools - We’d like to start using The Silver Searcher or ripgrep to power our project search and fd or similar to populate our fuzzy-finder list. This would improve the experience of using Atom in very large directories.

Alexey

это что же, vscode будет на растe?