LINUX.ORG.RU

Кризис при продвижении языка программирования Rust в ядро Linux

 , ,

Кризис при продвижении языка программирования Rust в ядро Linux

2

5

В сообществе разработчиков ядра Linux возникли разногласия по поводу интеграции языка программирования Rust. Кристоф Хелвиг (Christoph Hellwig), мэйнтейнер подсистем DMA, KVM, Slab Allocator и архитектуры PowerPC в ядре Linux, в своё время входивший в управляющий технический комитет организации Linux Foundation и выступавший истцом в связанном с GPL судебном разбирательстве с VMware, отказался подтверждать патчи, связанные с поддержкой разработки драйверов на языке Rust.

Предложенные патчи, добавляющие обвязки для функций подсистемы DMA, вызвали опасения относительно усложнения сопровождения кода и возможного снижения качества программного обеспечения. Некоторые разработчики предпочитают сохранять программные интерфейсы на языке C, чтобы избежать дополнительных сложностей.

В качестве причины отказа упомянуто усложнение сопровождения кода при наличии обвязок на других языках и желание сохранить программные интерфейсы к DMA в читаемом виде на языке Си, без размазывания по непонятным обвязкам. Кристоф предложил напрямую обращаться к исходному Си API DMA в каждом драйвере на языке Rust, чтобы не создавать дополнительных абстракций, от которых вынуждены будут зависеть сопровождающие ядра.

Неcмотря на высказанное разработчиками проекта Rust for linux намерение о полностью самостоятельном сопровождении написанной на Rust кодовой базы, на прием патчей было наложено вето.

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

Суть проблем с сопровождением в том, что Rust-обвязки ставят сопровождающих в зависимость от кода на языке Rust. На первый взгляд кажется, что обвязки лишь надстройки над Си-структурами и функциями, которые никак не влияют на разработку и сопровождение кода на Си. Но это не так. При наличии подобных обвязок разработчики подсистем, написанных на Си, должны учитывать влияние их изменений на продолжение работоспособности обвязок. Любое изменение структур данных или внутренних функций на Си может привести к необходимости изменения кода обвязок, поэтому влияющие на обвязки изменения в Си коде нужно отслеживать и синхронизировать с кодом на Rust. Многие сопровождающие не готовы брать на себя дополнительную ответственность за исправление проблем, возникающих в коде на Rust, и не намерены тратить своё время на отслеживание состояния Rust-обвязок.

>>> Подробности (OpenNet)



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 5)
Ответ на: комментарий от X512

Не напомните, какой официальный и единственно рекомендуемый способ установки rust в linux?

Официальный у кого? У авторов Rust – curl https://sh.rustup.rs -sSf | sh. У авторов дистрибутивов – пакет rust в местном пакетном менеджере. Тут есть конфликт интересов.

Что за конфликт?

opcode
()
Ответ на: комментарий от Stanson

Судя по всему, те элементы API которые нужны для этого драйвера - не менялись. А потом поменялись.

Вроде пишет что после WinXP ставится но использование приводит к BSOD, если я правильно понял. Это просто значит что драйвер криво написан и тот старый интерфейс не спасал от кривых рук.

V1KT0P ★★
()
Ответ на: комментарий от V1KT0P

Я если честно не пробовал его на висту или 2000 ставить. Маргинальные венды же. На симёрочку и дрисняточку пробовал. На симёрочке валится в BSOD. На дрисняточке не устанавливается вообще. Под sane драйверов нет. Сканер халявный, но неплохой. Выкинуть жалко, ибо изредка бывает нужен и может ещё понадобиться. Лежит, жрать не просит и заодно является живым рабочим примером нестабильности драйверного API венды.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Я вспомнил тут историю из нулевых, про сказки о стабильном апи. Знакомый купил компудастер с вистой, и захотел поставить хр. Поставил, пошел за дровами на звук - а они не работают, только под висту.

Хваленая видновая совместимость, ага.

liksys ★★★★
()
Ответ на: комментарий от liksys

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

С каких пор контейнеры стали спецификой Питона? Питон появился примерно так же давно, как и Java. Тогда не было никаких контейнеров, а зависимости уже были. И даже зависимости от нативных (совсем необязательно системных) библиотек тоже.

Вот смотри. Логику можно писать на чем угодно: хоть на ассемблере, хоть на прологе, хоть на плюсах. Вопрос только в том, сколько человекочасов на это будет затрачено, и какие ощутимые преимущества при этом получены. А еще каков будет порог входа в поддержание полученной кодовой базы. Как-то так получается, что склеивать строки и танцевать с опциями компилятора у мезона получается довольно неплохо, а остальные проекты, как тут выяснилось, заметно от него отстают.

Прямо так принципиально отстают? Я пока не услышал ни одного настоящего аргумента против CMake.

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

Ну так и CMake решает эту же проблему, здесь и сейчас. При этом CMake - это не что-то модно молодёжное, а уже достаточно распространённая и знакомая сишниками вещь. Почему GNU и ядро Linux упорствуют с другими системами сборк, подчас неадекватными (Autotools) я никак понять не могу. Может быть ради удовлетворения своего религиозного зуда?

zg
()
Ответ на: комментарий от vbr

Ну берите домашнее задание - переписать пример так, чтобы clang не выдавал предупреждений.

Ты же утверждал что соберется. Тебе показали что с нужными флагами – нет. Теперь ты петросянишь…

iron ★★★★★
()
Ответ на: комментарий от Stanson

Под sane драйверов нет. Сканер халявный, но неплохой. Выкинуть жалко, ибо изредка бывает нужен и может ещё понадобиться.

Можно виртуалку для этого под VirtualBox/QEMU создать, XP-шке 128 мегабайт оперативы хватит. Можно даже попробовать какой-то софт установить который позволит через локалку управлять сканером если окно виртуалки будет бесить.

V1KT0P ★★
()
Ответ на: комментарий от liksys

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

В массе своей народ не понимал зачем ставить Питон и Меркуриал, когда можно просто поставить Гит. Да Гит использует Перл и в старых версиях использовал его даже больше, чем сейчас. Но в Linux Перл уже и так стоит, а под Винду его заботливо завезли в виде спецсборки MSYS2, стараниями проекта git-for-windows. Ещё у Меркуриала был кризис перехода со второго Питона на третий.

Возвращаясь к системам сборки, я так же не понимаю, зачем тащить Питон и Meson, когда есть нативный CMake.

zg
()
Ответ на: комментарий от zg

Я пока не услышал ни одного настоящего аргумента против CMake.

Он слишком сложный, у него убогий синтаксис. Непонятно где брать информацию о том, как правильно на нём писать.

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от zg

С каких пор контейнеры стали спецификой Питона?

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

Тогда не было никаких контейнеров, а зависимости уже были.

Тогда было тогда, а сейчас у нас сейчас. Нет смысла оглядываться на прошлые неудачные решения, если проблема решена теперь. Если ты используешь софт в системе, то мейнтейнеры позаботились о том, чтобы всё работало. Если деплоишь на сервер - используй контейнер или venv. Всё, решено.

Мы вообще говорим о том, что питон никуда не девается. Это факт, с которым ты зачем-то пытаешься спорить.

Прямо так принципиально отстают? Я пока не услышал ни одного настоящего аргумента против CMake.

Я говорю о мезоне, бозоне и мюоне. CMake же просто нифига не интуитивен. Хотели декларативно, а получилось как всегда.

Почему GNU и ядро Linux упорствуют с другими системами сборк, подчас неадекватными (Autotools) я никак понять не могу.

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

liksys ★★★★
()
Ответ на: комментарий от X512

Вряд-ли Линукс дистрибутивы с традиционными пакетными менеджерами, пакующими всякую мелочь вроде libpng, куда-то денутся.

Проблема не в том, чем они пакуют, а в том как они это делают и насколько разными все эти дистрибутивы вообще являются. Проблема в фрагментации. Не было бы её и авторы прикладного софта сами собирали и паковали бы его, например в RPM.

Snap/FlatPak продвигаются с трудом.

И это хорошо, потому что Snap/FlatPak - это ещё большее зло.

zg
()
Ответ на: комментарий от zg

В массе своей народ не понимал зачем ставить Питон и Меркуриал, когда можно просто поставить Гит.

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

Возвращаясь к системам сборки, я так же не понимаю, зачем тащить Питон и Meson, когда есть нативный CMake.

Тебе уже сказали про сложность CMake. Плюс мезона в том, что его проще кастомизировать, потому что это придется делать на нормальном языке, а не цмейковом суржике ежа с ужом.

liksys ★★★★
()
Ответ на: комментарий от zg

Проблема не в том, чем они пакуют, а в том как они это делают и насколько разными все эти дистрибутивы вообще являются. Проблема в фрагментации.

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

И это хорошо, потому что Snap/FlatPak - это ещё большее зло.

А что предлагаете взамен? Атомарные дистрибутивы?

X512 ★★★★★
()
Ответ на: комментарий от X512

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

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

А что предлагаете взамен? Атомарные дистрибутивы?

Унификацию и стандартизацию.

zg
()
Ответ на: комментарий от X512

То есть единственно верный дистрибутив.

Нет. Совместимость между дистрибутивами. И таки да, количество дистрибутивов должно уменьшиться.

zg
()
Ответ на: комментарий от zg

Что-то я не увидел в Мезоне каких-то принципиальных плюсов

Тебе уже несколько раз сказали разными словами:

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

liksys ★★★★
()
Ответ на: комментарий от zg

Совместимость между дистрибутивами.

А что тогда от дистрибутивов останется, если будет выбран единый стандарт форматов пакетов и компиляции программ и библиотек? Ну можно сказать, что RHEL – стандарт (RPM и правда в стандарт LSB записан). Но Debian/Ubuntu помирать и отказываться от своего формата DEB не собираются.

X512 ★★★★★
()
Ответ на: комментарий от V1KT0P

Так у меня есть образ диска в qcow2 для QEMU как раз на этот случай. Через локалку управлять потребности нет, сканер нужен раз в несколько лет, в последний раз, несколько лет, назад треснувшую печатную плату для блока управления кондеем Oldsmobile Delta 88 1986 года сканировал, чтобы новую вытравить и заменить. :)

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от X512

Формат пакетов - это вообще незначительное отличие.

zg
()
Ответ на: комментарий от liksys

Тебе уже несколько раз сказали разными словами:

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

zg
()
Ответ на: комментарий от zg

Я привёл конкретное сравнение на ютубе

Да, вот я сейчас все дела брошу и побегу твои видео смотреть.

У тебя на одной чаше весов лежит питон. На другой - цмейковый DSL. Тут вообще обсуждать даже нечего, первый будет априори удобнее и понятнее.

liksys ★★★★
()
Ответ на: комментарий от liksys

У тебя на одной чаше весов лежит питон. На другой - цмейковый DSL.

У Meson как бы тоже DSL. На Питоне реализация Meson. Но есть и альтернативная реализация языка Meson на C99 – Muon.

Так что Meson прямого отношения к Питону не имеет.

X512 ★★★★★
()
Ответ на: комментарий от X512

Да не в этом дело. При желании ты все равно можешь наговнякать любое расширение именно на питоне. И попатчить его сильно проще. С цмейком тебя ждет либо его DSL, либо увлекательная компиляция увлекательной кодовой базы цмейка.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от liksys

При желании ты все равно можешь наговнякать любое расширение именно на питоне.

Это может быть сложно поддерживать потому что у модулей Meson на Питоне нет стабильного API. Там ситуация примерно как с модулями ядра Линукса.

Но да, пропатчить код Meson не сложно.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

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

liksys ★★★★
()
Ответ на: комментарий от opcode

в дистрах может быть версия ниже той, которую растовики хотят считать стабильной и какой-нибудь крейт завалится В РАНТАЙМЕ потому что разраб идиот.

mittorn ★★★★★
()
Ответ на: комментарий от zg

Просто их нет.
Есть waf в котором ты сразу пишешь на нормальном питоне и который кладётся просто в проект, не нужно никаких зависимостей кроме питухона (но пользователей windows это напрочь отпугивает почему-то).
Есть cmake, который несмотря на весьма убогий синтаксис вполне удобен для маленьких проектов и поддерживается кучей всяких IDE и других инструментов, да и установлен почти везде (но лучше таргетировать что-то постарее т.к билдить новую версию в старый дистр долго)
Есть autotools, который при сгенерированном configure не имеет зависимостей кроме sh и может разворачиваться хоть на кофеварке с андройдом, если там будет компилятор.
А есть meson, который не имеет ничего из этого, зато который нужно ставить в систему, тащить кучу зависимостей под конкретную версию питона, при этом имеет свой нескучный язык и практическеи все проблемы автотулзов...

mittorn ★★★★★
()
Ответ на: комментарий от liksys

Порешали именно сервисы и медийный ресурс.

Нененене. Меркуриал был убит своим питоном под капотом. Сильный удар был при переезде со второго на третий, и фатальный удар — скорость работы после всех оптимизаций. Так-то у Меркуриала были две киллер-фичи рядом с гитом (hg serve и tortoise-hg), очень жаль.

sarumeister
()
Ответ на: комментарий от gaylord

В сравнении с чем?

В сравнении с кол-вом пользователей неархаичных подходов.

Автор hyprland код cmake’ом собирает и ему тоже нормально. Парню около 20.

Наверное можно найти и тех, кто в свои 20 использует autotools. Наверное это должно что-то значить.

thegoldone ★★
()
Ответ на: комментарий от iron

Простая функция-обертка для указателя уже не позволяет компилятору выявить проблему:

#include <stdio.h>

char *wrap(char *s) {
    return s;
}

char *get_string(void) {
    char string[] = "hello";
    return wrap(string);
}

int main(void) {
    char *s = get_string();
    printf("%s\n", s);
}

godbolt

No ★★
()
Ответ на: комментарий от gaylord

В 2025 году для венды до сих пор никто не написал софтварного рейда, лол.

Как это нет софтварного рейда? Все там есть.

sabacs
()
Ответ на: комментарий от gaylord

Программистов на C и другом low level меньше было всегда.

Меньше чем на Расте? В какой-то момент их может и стало меньше.

thegoldone ★★
()
Ответ на: комментарий от mittorn

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

Моя любимая фишка autotools: когда после git-merge где-то потерялся fi к if и в итоге сгенерированный configure выдаёт ./configure: line 22328: syntax error: unexpected end of file. Просто обожаю, когда такое случается! Самые user friendly сообщения об ошибках синтаксиса ever!

hateyoufeel ★★★★★
()
Ответ на: комментарий от thegoldone

Меньше чем на Расте? В какой-то момент их может и стало меньше.

чем на языках где есть билдсистема

gaylord
()
Ответ на: комментарий от sarumeister

Я помню это, но второй питон жил аж до 2020 года и был во всех дистрах. Но даже во времена разговоров «да кому ваш третий питон нужен» в районе 2015, меркуриал уже помирал.

liksys ★★★★
()
Ответ на: комментарий от Stanson

сканер Canon

О, боль моя дырка задница. Работает только под XP. Ради него даже виртуалка на 1гб валяется и есть не просит.

einhander ★★★★★
()
Ответ на: комментарий от liksys

«да кому ваш третий питон нужен» в районе 2015, меркуриал уже помирал.

Дело-то не в наличии питона в системе. Переписывание меркуриала со второго питона на третий: баги, несовместимости, вырезание функционала. В районе 2015 года люди озаботились его плохой скоростью. На десктопах это было заметно в меньшей степени. На одноплатниках и в облаках в большей степени.

sarumeister
()
Ответ на: комментарий от gaylord

Важно то, что Linux – единственная из трёх популярных ОС без стабильного ядерного API (и ABI). Иногда это обходят через дрова в юзерспейсе, отсюда мы имеем вагон разных демонов с libusb для поддержки разных клавиатур, RGB и прочего мелкого говна.

Погодите, но это же буквально микроядро! Все же кипятком ссать должны.

Микроядро через костыли и такую-то задницу. Всё как мы любим!

hateyoufeel ★★★★★
()
Ответ на: комментарий от sarumeister

А разве все не пользовались версией для второго питона? Вот это я уже плохо помню, но всегда hg тащил второй питон в систему.

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

А где задница? API есть? Да. Функциональный? Да. Стабильный? Да. В userspace можно драйверы писать? Да. Микроядро по всем признакам.

gaylord
()
Ответ на: комментарий от No

не позволяет компилятору выявить проблему

clang-tidy:

/tmp/1.c:9:5: warning: Address of stack memory associated with local variable 'string' returned to caller [clang-analyzer-core.StackAddressEscape]
    9 |     return wrap(string);
      |     ^
/tmp/1.c:13:15: note: Calling 'get_string'
   13 |     char *s = get_string();
      |               ^~~~~~~~~~~~
/tmp/1.c:9:5: note: Address of stack memory associated with local variable 'string' returned to caller
    8 |     char string[] = "hello";
      |     ~~~~~~~~~~~~~~~~~~~~~~~
    9 |     return wrap(string);
      |     ^      ~~~~~~~~~~~~

valgrind --leak-check=full --track-origins=yes --show-leak-kinds=all -s:

==3671== 1 errors in context 1 of 3:
==3671== Syscall param write(buf) points to uninitialised byte(s)
==3671==    at 0x4989D7A: _write (in /lib/libc.so.7)
==3671==    by 0x496ED86: ??? (in /lib/libc.so.7)
==3671==    by 0x4967A9D: fflush_unlocked (in /lib/libc.so.7)
==3671==    by 0x496AA2E: ??? (in /lib/libc.so.7)
==3671==    by 0x4972C8A: ??? (in /lib/libc.so.7)
==3671==    by 0x496FBAC: vfprintf_l (in /lib/libc.so.7)
==3671==    by 0x496C6E9: printf (in /lib/libc.so.7)
==3671==    by 0x201765: main (1.c:14)
==3671==  Address 0x5553040 is 0 bytes inside a block of size 4,096 alloc'd
==3671==    at 0x484E0B4: malloc (vg_replace_malloc.c:448)
==3671==    by 0x496B9EF: ??? (in /lib/libc.so.7)
==3671==    by 0x497B504: ??? (in /lib/libc.so.7)
==3671==    by 0x496FE1D: ??? (in /lib/libc.so.7)
==3671==    by 0x496FBAC: vfprintf_l (in /lib/libc.so.7)
==3671==    by 0x496C6E9: printf (in /lib/libc.so.7)
==3671==    by 0x201765: main (1.c:14)
==3671==  Uninitialised value was created by a stack allocation
==3671==    at 0x496C650: printf (in /lib/libc.so.7)
==3671== 
==3671== 
==3671== 2 errors in context 2 of 3:
==3671== Conditional jump or move depends on uninitialised value(s)
==3671==    at 0x4855B73: memchr (vg_replace_strmem.c:989)
==3671==    by 0x496A960: ??? (in /lib/libc.so.7)
==3671==    by 0x4972BEB: ??? (in /lib/libc.so.7)
==3671==    by 0x496FBAC: vfprintf_l (in /lib/libc.so.7)
==3671==    by 0x496C6E9: printf (in /lib/libc.so.7)
==3671==    by 0x201765: main (1.c:14)
==3671==  Uninitialised value was created by a stack allocation
==3671==    at 0x496C650: printf (in /lib/libc.so.7)
==3671== 
==3671== 
==3671== 3 errors in context 3 of 3:
==3671== Conditional jump or move depends on uninitialised value(s)
==3671==    at 0x4854A19: strlen (vg_replace_strmem.c:518)
==3671==    by 0x49715E6: ??? (in /lib/libc.so.7)
==3671==    by 0x496FBAC: vfprintf_l (in /lib/libc.so.7)
==3671==    by 0x496C6E9: printf (in /lib/libc.so.7)
==3671==    by 0x201765: main (1.c:14)
==3671==  Uninitialised value was created by a stack allocation
==3671==    at 0x496C650: printf (in /lib/libc.so.7)

cc -g -fsanitize=address,undefined -fsanitize-address-use-after-return=always -fsanitize-address-use-after-scope -fno-omit-frame-pointer 1.c:

==3597==ERROR: AddressSanitizer: stack-use-after-return on address 0x000802a02020 at pc 0x00000028285c bp 0x7fffffffe990 sp 0x7fffffffe138
READ of size 6 at 0x000802a02020 thread T0
    #0 0x00000028285b in printf_common(void*, char const*, __va_list_tag*) asan_interceptors.cpp
    #1 0x000000285256 in printf (/tmp/a.out+0x285256)
    #2 0x00000038be6d in main /tmp/1.c:14:5
    #3 0x0008004ebff3 in __libc_start1 (/lib/libc.so.7+0x82ff3)
    #4 0x00000024a40f in _start (/tmp/a.out+0x24a40f)

Address 0x000802a02020 is located in stack of thread T0 at offset 32 in frame
    #0 0x00000038bd37 in get_string /tmp/1.c:7

  This frame has 1 object(s):
    [32, 38) 'string' (line 8) <== Memory access at offset 32 is inside this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-return asan_interceptors.cpp in printf_common(void*, char const*, __va_list_tag*)
Shadow bytes around the buggy address:
  0x000802a01d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a01e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a01e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a01f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a01f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x000802a02000: f5 f5 f5 f5[f5]f5 f5 f5 00 00 00 00 00 00 00 00
  0x000802a02080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a02100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a02180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a02200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a02280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==3597==ABORTING

…уж простите за портянки.

iron ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.