TIL: how to debug randomly hanging Python applications

Usually, if a Python-based application hangs, you either read logs or grab one of the PBD-based solutions, attaching to the application, and uses the Python console for investigation. The approach is straightforward; for example, you installed pdb-attach, and add a few lines to your application:

import pdb_attach
pdb_attach.listen(50000)

and expect that “magic” will just works:

> python -m pdb_attach <PID> 50000
(Pdb) YOU HAVE PDB SESSION HERE

But sometimes, magic is broken, and my theory is (I didn’t search for proof) that this is due to GIL. So, sometimes, no PDB prompt after you have attached to the application with PDB. In my case, the application hang in the multiprocessing.Process call where I used a gRPC server. The gRPC server didn’t react to the termination request, the process cannot stop, and like aggravating circumstances, all these are a part of PyTest that hang 1 of 20 executions.

This is a general PDB-based debuggers issue, which means all other tools like pyrasite-shell and PyTest PBD integration also don’t work. The only option here is GDB for Python, which is surprisingly amazing! First of all, you need to install Python extension for GDB.

sudo apt-get install python3.9-dbg

Then you can connect to your Python application which is a regular Python process with GDB, and explore the call-stack!

> gdb

(GDB) attach <PID>
(GDB) py-bt

If you use not APT-based Linux, search for proper instruction here.

Чего ожидать от работы в Self Driving?

Когда я только шел в AV два года назад, я думал, “а как оно там?”. Было ощущение, что AV это почти полностью про компьютерное зрение и прочее AI, т.е. ну совсем не моё и что лично мне там делать был большой вопрос. Но на деле оказалось, что это сильно не так, около 90% работы в данном домене вообще никак не связанны с AI задачами. На сегодня есть ощущение что у меня сложилась относительно полная картина о том, что же может ждать разработчика в автономных каретах. Тут я не планирую вдаваться ни в какие технические решения, а просто приведу общий обзор потенциальных направлений работы для IT-специалистов в данном домене.

Направления работ

Основных направлений работа несколько: автономный стек, инфраструктура, железо, безопасность, облака и аналитика. Само собой есть еще множество более мелких направлений, я выдели самые крупные. Наверное самыми неожиданными в списке будут два последних пункта, но без них реально никуда.

Автономный стек

В автономный стек как раз и входит всё то, что приходит на ум когда ты слышишь “работа в AV”. В то же время для меня это наименее знакомая и интересная часть. Извините
Continue reading →

Возвращение к C++

Последние лет 6 я всё меньше и меньше занимался разработкой на C++, количество использования фактически шло по убывающей до нулевого значения год назад. Чего только не было в качестве основного языка, и Go, и Elixir и даже небольшие отрезки времени чистый Python. Но так случилось, что с переходом на новое место работы C++ вновь стал моим основным рабочим инструментом. Появилась насущная необходимость шустро освежить знания в голове и, в идеале, совместить это с чем-то полезные. В итоге я решил решил порешать задачки на тему криптографии от cryptopals дабы как-то скрасить ожидание открытия заинтересовавшего меня курса по криптографии на Коурсере.  Ну а так как теперь мне действительно есть с чем сравнивать C++, ощущения от языка получаются более цельные, как мне кажется. Continue reading →

Elixir, backend и стартапы

Несмотря на то, что компания TSC просто замечательная, задержаться в ней надолго по ряду причин не вышло. Это был один из тех редчайших случаев когда действительно вся команда высоко квалифицирована, не менее высоко мотивирована и ответственна. За прошедшие 7 месяцев мне удалось посмотреть и потрогать руками практически новый для меня мир экзотических языков в prod-е, немного иначе посмотреть на то, какой бывает разработка backend-ов и попробовать на практике что такое стартап.

Elixir

Начнем с самого главного, а именно с Elixir, который до моего прихода был фактически единственным языком используемым в компании для разработки backend-а. На первый взгляд, это был разумный и продуманный выбор – простой и выразительный язык с кучей возможностей, дружелюбное сообщество и BEAM под капотом. Благодаря наличию Ecto и Phoenix разработка backend проходит относительно гладко и быстро, а новичок который до этого ни разу не писал на Elixir ничего сложнее HelloWorld, т.е. я, начинает приносить пользу буквально через неделю, что по моему опыту очень хороший результат. Continue reading →

Windows, Linux и шифрованные диски

Я очень долго использовал устройства Apple в качестве основных рабочих систем и дома и на работе, лет 10, наверное. В целом, это удобно, так как доступны как все приложения которые нужны как для хобби (Capture One & Photoshop), так и рабочие инструменты. Ко времени очередного обновления железа я успел не только заинтересоваться машинным обучением и внимательно посмотреть на современный рынок железа, но и упереться в то, что Apple и GPGPU не совместимы в принципе. После всех метаний и попыток запустить то что мне хочется на устройствах от Apple у меня состоялся большой исход к их конкурентам, ведь зачем платить больше и не иметь доступа к GPGPU, если можно его получить за меньшие деньги?

Перебравшись на Windows дома я довольно долго пытался убедить себя в том, что к всему этому ужасу можно привыкнуть и я просто забыл как классно работать в Windows разработчику… но все же нет. Привыкнуть к PowerShell и его окружению вместо Bash и стандартного набора команд POSIX, а так же отсутствию не глючного терминала просто не возможно. И WSL тут никак не спасает, так как подсистема не только ощутимо тормозит на любом I/O, но и довольно глючная, а кривые терминалы еще сильнее сужают возможности её использования в разработке.

Continue reading →

Это был интересный период в моей карьере

На сегодня Автодеск – это компания в которой я проработал дольше всего, без месяца 5 лет! Компания по многим параметрам замечательная, иначе что бы я тут так долго работал? Но всё хорошее рано или поздно заканчивается и в данном случае я даже несколько поздновато принял решение уйти, но об этом ниже.

Наверное самым интересным и полезным за это время были многонациональные команды в которых пересекались люди из разных стран: Китая, Ирландии, Вьетнама, Индии, Мьянмы, Украины, США, Сингапура. Научиться доносить свои мысли и продвигать идеи так что бы, с одной стороны, все всё поняли и в идеале согласились, а, с другой стороны, что бы никто не остался обиженным или недовольным в таком коллективе задача не из простых хотя и решаемая. Так как Автодеск компания большая и обладает очень (я бы даже сказал через-чур) разлапистой иерархией, удалось хорошо поупражняться в таких социальных активностях как корпоративные игры, интриги и войны.

Continue reading →

C++ идет в облака

Попасть на CppCon в этом году по ряду причин не вышло, поэтому я смотрю видео на YouTube. В процессе просмотра списка докладов глаз моментально зацепился за The Design of the C++ Runtime for AWS Lambda и я не разочаровался. Доклад в чем-то знаковый, так как он показывает применимость языка в области о которой C++ разработчики не думают и, обычно, ничего не знают.

Ключевые моменты из доклада:

  • AWS SDK for C++ позволяет оперировать всеми сервисами AWS, SDK доступен на GitHub. Там же можно найти огромное количество примеров использования.
  • SDK использует libCURL и разработчик должен сам разобраться с инициализацией хранилища сертификатов, расположение которого, конечно же, может зависеть от версии Linux.
  • Много воевали с libC, который довольно объемный с точки зрения набора библиотек и дистрибутиво-зависимый. Остановились на решении паковать все файлы проекта (включая libC) в один архив и запускать через ld-linux.so.
  • Если хочется уменьшить количество файлов привносимых libC, хотя целесообразность этого действия под вопросом так как еще есть libC++/libStdC++, то можно воспользоваться musl.
  • AWS гарантирует минимальный уровень процессора SkyLake, так что если вам нужен SIMD, то вполне можно включать процессоро-специфические оптимизации.

При том, что один из основных сценариев использования лямбды это – по-быстрому что-то посчитать, причем “по-быстрому” тут ключевое ведь оплата за время, то потенциал использования C++ (еще и с включенными SIMD-оптимизациями) на этом поприще выглядит очень заманчивым.

9-9-6 к нам мчится

На прошлой неделе я, как обычно, был на Go-митапе, который на этот раз проводился в Shopee. Компания расстаралась: закупили кучу пиццы, раздали всем на входу брошюрки с рекламой самих себя и предложением пойти к ним работать. В целом разумно, если уж ты принимаешь у себя какой-то митап, тратишься на это, хорошо бы и выхлоп получить в виде потока резюме. Открывал митап их HR, который с задором рассказал, что они уже успели разрастись до 8К человек (что они делают такой толпой?! они же просто онлайн платформа для торговли!) и это не предел, в их планах расти и дальше. Тут все, конечно, понятно, чем больший рост ты покажешь, тем больше инвесторы тебе бабла отвалят. Стружка должна лететь!

Continue reading →

Rust и не звездные команды

Сегодня мне удалось немного с другой стороны посмотреть на Rust, что дало интересную пищу для размышлений. В общем случае я склонялся к мнению, что Rust – это, конечно, прекрасно, но по уровню сложности он мало чем уступает C++, а при таком раскладе зачем нужно разбираться с еще одним монстром? Но, похоже что, эта позиция может быть довольно большим заблуждением.

Continue reading →

Методологии разработки ПО, лучшие книги

Да, довольно странная для меня тематика, обычно я технические вещи про саму разработку пишу. При этом, тема управления проектами и людьми мне достаточно близка, просто как-то не пишется в этом направлении. Недавно мне подумалось, что я мог и упустить что-то стоящее из области фундаментальных знаний о методологии разработки ПО. После некоторых раздумий я пришел к выводу, что так и есть, это “Путь камикадзе” за авторством Эдварда Йордона. Перевод на русский довольно посредственный, но читать на английском, почему-то в этот раз не захотелось.

Несмотря на почтенный по меркам IT индустрии возраст (больше 20 лет), книга отнюдь не утратила своей актуальности, ну может за исключением пары страниц, где говорится про технологические решения, типа Lotus Notes и им подобные. Книга легко читается и полезна как рядовым программистам (что бы понять что вообще вокруг происходит) так и тимлидам, архитекторам, менеджерам и всем остальным причастным к разработке. В итоге, книгу я прочел в один присест и всем рекомендую (если, конечно, найдется еще много тех, кто не прочел сей фундаментальный труд). Continue reading →