Недавно я создала небольшой инструмент под названием dnspeep, который позволяет понять, какие DNS-запросы отправляет ваш компьютер и какие ответы он получает. Всего мой код занял 250 строк на Rust. В этой статье я расскажу о коде, объясню, для чего он нужен, почему в нём возникла необходимость, а также расскажу о некоторых проблемах, с которыми я столкнулась при его написании. И, конечно, вы сами сможете попробовать код в действии.
В этой публикации речь пойдет о синтетических модулях и символах отладочного движка Windows (debugger engine). То есть о сущностях, которые можно искусственно добавить в отладчик для раскраски адресов памяти.
testnet=1
addnode 188.166.12.157 add
Многие из вас, возможно, видели всякие загадочные знаки на полях. Нет, не те что на картинке слева :). Я имею в виду значки на полях редактора кода в Visual Studio. Наиболее известными являются иконки точки останова (Breakpoint) 
и закладки (Bookmark) 
. Но есть и другие. Я предлагаю небольшой конкурс: вот 8 значков, которые могут появиться на полях редактора кода в Visual Studio 2010 (без всяких плагинов). Первый, кто верно объяснит их все, получит от меня инвайт на Хабр. 
Пишите ответы комментариями к этому топику, а у кого нету аккаунта на Хабре — пишите куда угодно и бросайте ссылку в твиттер с хештегом #VsMisterySigns — обещаю всё прочитать. Ответы удобно нумеровать в соответствии именам интовских переменных в коде. Срок приёма ответов — сутки с момента публикации. Объявление победителя — в течение суток по окончанию приёма ответов, развёрнутой статьей в этих же хабах.
В комментариях к статье в очередной раз услышал мнение, что поскольку невозможно в принципе гарантировать отсутствие циклических ссылок при статическом анализе кода, то в языке Rust такие утечки памяти считаются безопасными, так как это, не влияет на безопасное управление памятью.
При работе с памятью существует много типов ошибок, но единственные ошибки, которые до сих пор не имеют нормального способа решения, это утечки памяти из-за циклических ссылок, когда два или более объектов напрямую или косвенно ссылаются друг на друга, в результате чего доступная приложению оперативная память постепенно уменьшается, так как ее невозможно освободить автоматически.
Утечки памяти из-за циклических ссылок являются наиболее сложными для анализа. В то время как для всех остальных типов ошибок при работе с памятью уже найдены и используются различные решения, например на уровне языка программирования, с помощью сборщиков мусора, проверки заимствований или шаблонов библиотек, то проблема утечек памяти из-за циклических ссылок остается нерешенной и по сей день.
Но мне кажется, что есть очень простой способ устранить циклические ссылки в программе, который можно реализовать практически в любом типизированном языке программирования, конечно, если при этом не использовать все разрешающее ключевое слово unsafe для Rust или оператор reinterpret_cast в случае С++.
В этой статье мы рассмотрим различные подходы для работы с небезопасными операциями в языке программирования Swift. Swift предоставляет несколько способов для работы с указателями и низкоуровневой памятью.
Поиск ошибок в программах дело творческое и интересное. Чаще всего мы ищем ошибки в своём коде, чтобы его починить. Кто-то может искать ошибки в чужом коде, чтобы его сломать или поучастовать в баунти-программе.
А вот где именно искать ошибки? Какие функции тестировать? Хорошо, если программа полностью ваша. Но что если вы занимаетесь тестированием, а эти программисты постоянно придумывают что-то новое? Никаких рук не напасёшься.
Некоторые ошибки трудно воспроизвести на вашем персональном компьютере, но их легко воспроизвести на производственных или тестовых машинах. Это обычная ситуация, с которой часто сталкиваются профессиональные Java-разработчики. Для отладки таких проблем OpenJDK предоставляет два инструмента: remote debugging и jdb. Эта статья посвящена jdb.
Для приложений Java типичными производственными и тестовыми машинами являются серверы Linux без графического интерфейса, поэтому доступны только инструменты командной строки. И мы не можем использовать профессиональные IDE, такие как IntelliJ IDEA, Eclipse или Apache NetBeans IDE.
В таких сценариях мы можем использовать jdb. jdb - это отладчик командной строки, входящий в состав OpenJDK.
Это перевод руководства для начинающих. Очевидно эксперты все это знают и им не стоит тратит время на его чтение...
Вместе с моим коллегой Евгением мы потратили много времени. Приложение обрабатывает тысячи запросов в асинхронном конвейере, полном async/await. Во время нашего исследования мы получили странные вызовы, они выглядели как бы “перевернутыми”. Специально к старту нового потока курса по разработке на C#, рассказываем, почему вызовы могут оказаться перевёрнутыми даже в Visual Studio.
