Отладка *

Я ненавижу код бенчмаркинга, как и любой другой человек. Гораздо веселее притвориться, что твоё кэширование значения увеличило производительность на 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 для тестирования, настройки или исследования устройств и стендовых систем.

int safeDiv(int a, int b) {
   if (b == 0)
      throw Div0(); // Исключения передаются особым образом
   return a / b; // Теперь-то всё абсолютно безопасно, ведь так?
}

Pinterest поддерживает формирование отчётов по метрикам рекламных объявлений внешних рекламодателей и расчёт рекламных бюджетов в реальном времени. Всё это основано на потоковых конвейерах обработки данных, созданных с помощью на Apache Flink. Доступность заданий (job) Flink для пользователей находится на уровне 99-го перцентиля. Но время от времени некоторые задачи (task) «валятся» под ударами неприятных ошибок, вызванных утечками прямой памяти (Out-Of-Memory, OOM), возникающими сразу в нескольких операторах. Выглядит это примерно так:

Разбирался я в низкоуровневой работе камер iPhone, и дошёл до FaceID — системы распознавания лиц, используемой Apple для разблокировки смартфона. И наткнулся внутри на интересную вещь: чип, единственное предназначение которого в том, чтобы вывести из строя FaceID. Навсегда.

О том, как в iPhone вообще работает FaceID, где там этот чип стоит, что именно он делает, зачем его сделали таким злым, и как в ремонте справляются с этой напастью — под катом!

Мой провайдер помимо замедления (читай полная блокировка) YouTube так-же стали блокировать соединения с моими рабочими VPN. Работодатель не очень любит, когда на встречах на вопрос о прогрессе, я неделю отвечаю, что у меня не работает VPN! Своими действиями, мой провайдер сам меня подтолкнул к поиску обходных путей.

Сразу скажу, обходной путь придумал не сам, мне его подсказал автор проекта zapret, а точнее его комментарий, более того, я использую его проект, чтоб смотреть нормально YouTube. Спасибо огромное!

Добавлю, я использую nftables и nfqws, если этот вариант работает у меня — это не значит, что оно заработает и у вас! Возможно, вам придётся изменить некоторые параметры.