Отладка *

Неопределённое поведение (undefined behavior, UB) в языке программирования C — постоянный источник жарких споров между программистами. С одной стороны, UB может быть важным для оптимизаций компилятора. С другой стороны, оно упрощает появление багов, которые приводят к проблемам безопасности.

Хорошая новость: N3322 был принят для C2y, что позволит устранить неопределённое поведение из этого конкретного участка языка C и сделать всё показанное ниже чётко определённым:

memcpy(NULL, NULL, 0);
memcmp(NULL, NULL, 0);
(int *)NULL + 0;
(int *)NULL - 0;
(int *)NULL - (int *)NULL;

Утечка горутин в Go происходит, когда горутина продолжает существовать и потреблять ресурсы, даже если она больше не выполняет полезной работы или не может завершиться. Это может произойти по разным причинам.
Мы рассмотрим 3 примера из которых: 2 будут на каналах, 1 с использованием mutex.

Введение

• Дистанционно запускать и глушить двигатель, выполнять блокировку и разблокировку, получать текущее местоположение любого автомобиля.
• Получать полную историю местонахождения любого автомобиля за последний год с точностью до пяти метров, обновляемую при запуске двигателя.
• Запрашивать и получать личную информацию (personally identifiable information, PII) любого покупателя, в том числе контакты для экстренной связи, авторизованных пользователей, физический адрес, платёжную информацию (например, последние четыре цифры кредитной карты) и PIN автомобиля.
• Получать доступ к различным пользовательским данным, в том числе к истории звонков, сведениям о предыдущих владельцах, показаниям одометра, истории продаж и многому другому.

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

pgTap – это расширение PostgreSQL для разработки юнит-тестов. Сами тесты, как, собственно, и pgTap, пишутся на plpgSQL, что означает низкий порог вхождения для разработчиков PG.

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

В этой статье мы разберём небольшой инструмент для трассировки системных вызовов. В отличие от strace и аналогов, здесь трассировка будет происходить внутри процесса, без применения ptrace() или эквивалентных вещей. Должен добавить, что это всего лишь демонстрационный пример, поэтому на практике он и близко не сравнится с strace. В частности, он пока не может точно выводить в консоль аргументы для большинства системных вызовов.

Именно на примере системных вызовов удобно продемонстрировать цепочную загрузку, и на то есть три причины...

Я ненавижу код бенчмаркинга, как и любой другой человек. Гораздо веселее притвориться, что твоё кэширование значения увеличило производительность на 1000%, чем проверять это тестами. Увы, бенчмаркинг JavaScript по-прежнему необходим, особенно потому, что JavaScript используется (когда не должен?) во всё более чувствительных к производительности приложениях. К сожалению, из-за множества базовых архитектурных решений языка, JavaScript никак не упрощает выполнение бенчмаркинга.

Нашего клиента донимали отчёты о вылетах, показывавшие, что его программа ломается на самой первой команде.

Я открыл один из дампов вылета, он оказался настолько странным, что отладчик даже не мог понять, что пошло не так.

Приветствую еще раз.

Это 2 часть небольшой статьи об отладчиках. В прошлой мы разобрали базу: инструкции + системные вызовы, написали свой отладчик, препарировали gdb и смотрели на отладку в высокоуровневых ЯП со своим рантаймом.

В этой мы посмотрим на процесс отладки в IDE изнутри, а потом пойдем еще глубже...

Приветствую.

Вы когда нибудь отлаживали программы? Не врите, что нет. Благодаря отладчикам наши программы работают корректно (или хотя бы близко к этому).

Но вот знаете ли вы как отладка устроена: точки останова, шаги, бэктрейс, чтение переменных?

Нет или да - ответ не важен. Эта статья даст ответы на многие вопросы об отладке, которые вы, возможно, и не задавали себе.

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

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

Цель этой статьи максимально коротко и понятно посвятить читателей в отладку.

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

В нашем предыдущем посте Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models мы рассказали о фреймворке для исследований уязвимостей при помощи языковых моделей и продемонстрировали его потенциал, усовершенствовав показатели современных бенчмарков CyberSecEval2 компании Meta. С тех пор Naptime эволюционировал в Big Sleep — совместный проект Google Project Zero и Google DeepMind.

Сегодня мы с радостью готовы поделиться первой уязвимостью из реального мира. обнаруженной агентом Big Sleep: отрицательным переполнением (underflow) буфера стека с возможностью реализации эксплойтов в SQLite, — широко используемом опенсорсном движке баз данных. Мы обнаружили уязвимость и сообщили о ней разработчикам в начале октября, и они устранили её в тот же день. К счастью, мы обнаружили эту проблему до её появления в официальном релизе, так что она не затронула пользователей SQLite.

Мы считаем, что это первый публичный пример обнаружения ИИ-агентом ранее неизвестной уязвимости безопасности по памяти в широко используемом реальном ПО. В этом же году на мероприятии DARPA AIxCC команда Team Atlanta обнаружила разыменование нулевого указателя в SQLite, что вдохновило нас использовать его в нашем тестировании, чтобы проверить, сможем ли мы найти более серьёзную уязвимость.

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

Сама уязвимость довольно любопытна, к тому же существующая инфраструктура тестирования SQLite (и через OSS-Fuzz, и через собственную инфраструктуру проекта) не обнаружила проблему, так что мы провели дополнительное исследование.

Я, как и многие, пользуюсь дискордом и китайскими прокси клиентами, но, к сожалению, голосовой чат дискорда не поддерживает работу через прокси. Из-за этого постоянно приходится включать режим TUN/VPN, который заворачивает в туннель много лишнего.

Можно ли с этим что-то сделать? Конечно! Добро пожаловать под кат, там вас ждет готовое решение и куча технических подробностей.

• Когда следует перехватывать исключения, генерируемые вызываемыми вами функциями, а когда этого делать не нужно?
• Как узнать, какие классы исключений нужно перехватывать?
• Что нужно делать при перехвате исключений для их «обработки»?
• Почему перехватывание всех исключений считается порочной практикой, и когда делать это приемлемо?

Выпускаю первую ВМ. По сети не пингуется. Локально с гипервизора — всё ок. Лезу на консоль, запускаю что-то типа "tcpdump -nvvvi any" (по-умолчанию выставляется promisc-режим) — ping побежал. Выключаю tcpdump — опять глухо. При запуске с ключом "-p" (запретить неразборчивый режим) tcpdump вообще ничего не видит.

Настройка визуального представления сигналов при моделировании в среде ModelSim (часть 1)

Добрый день читателям Хабра! Меня зовут Алексей, я занимаюсь работой с ПЛИС (FPGA) уже более 15 лет. Хабр читаю давно, но статьи здесь никогда не писал. В общем решил попробовать. Не знаю, насколько на Хабре интересны темы, связанные с ПЛИС? Но всё же, вдруг кому-то эта небольшая статья будет полезна.

Недавно столкнулся с интересным багом в Next.js. Если на странице not-found делать навигацию через router.push(pathname), теряются все переменные окружения, которые мы инициализируем через библиотеку next-runtime-env (значение window.__ENV становится undefined).

В проекте мы используем next-runtime-env, так как придерживаемся подхода Build once, deploy many — это позволяет держать один Docker-образ, в который при запуске прокидываются нужные переменные окружения. Next.js из коробки не поддерживает такое поведение, ведь он хочет собирать env-переменные на этапе сборки приложения.

Баг проявился на not-found странице, где у нас есть кнопка, позволяющая создать элемент в один клик, если что-то не найдено. Этот же компонент кнопки используется и на других страницах, и вот что интересно: на остальных страницах router.push(pathname) работает корректно, а на not-found — нет.

Сначала я подумал, что проблема кроется в next-runtime-env. Наверное, библиотека переопределяется при обновлении страницы, потому что скрипт, устанавливающий переменные в window.__ENV, размещён в root layout. Я также пробовал версионировать Next.js, предполагая, что баг связан с определёнными версиями фреймворка, но это не дало результатов. В итоге, временным решением стало использование window.location.href, что предотвращало рефреш страницы и помогало сохранить переменные.

Однако на этом история не закончилась.

Привет, Хабр! Меня зовут Роман Вернин, я разработчик систем на кристалле в компании Аквариус. Вместе с коллегами мы разрабатываем микросхемы ASIC. В этой статье я хотел бы поделиться опытом, как можно использовать отладочное средство ПЛИС от фирмы Intel для тестирования, настройки или исследования устройств и стендовых систем.