Сегодня ровно 5 лет, как мы присоединились к корпорации Huawei. What a run, huh?

Тут, наверное, нужно сделать какие-то выводы, подвести (промежуточные) итоги, все такое. Это все обязательно будет, но потом. Может на пенсии, когда решу писать мемуары (ха, какая пенсия, дружище? ты умрешь, стоя за станком).

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

Посмотрим, что будет дальше!

И кажется, что второе мое научное руководство было успешнее первого.

Главный урок, который я для себя усвоил: не нужно руководить дипломом, тема которого тебе самому не очень близка (иначе зачем ты, как научный руководитель, нужен?). Очевидно? Конечно! Но дипломы у нас не из воздуха берутся, бизнес дикутет свои требования даже для рисерча. Вот и в этот раз изначально обсуждалась совсем другая тема, но я уперся рогом и согласился руководить только той работой, которая будет интересна лично мне и в которую я сам полностью верил. И получилось хорошо.

Наверное, так стоит делать и вообще по жизни, а не только в научном руководстве.

--

Anyway, поздравляю наших новоиспеченных магистров! Вы большие молодцы. Остерегайтесь темной стороны.

#the_real_science

Так.

Сегодня ныл на обеде, что неохота писать одну там спеку по работе. На что мне сразу резонно заметили: «конечно, то ли дело здоровенный пост в телеге, да?»

Вот так и думал, что нужно было писать под псевдонимом. «Углян Иванский», например.

P.S. вообще, надо просто написать на схожую тему пост сюда, тогда и спека бодрее пойдет.

Классный, веселый и легкий (в хорошем смысле) доклад от Севы про сложности добавления новых API в стандартную библиотеку.

Когда речь зашла про баг с локалями, я сразу подумал про турок с их İ и I, т.к. у нас точно такой же баг был в свое время :)

P.S. кстати, смотрите, какой у Севы еще был когда-то доклад про устройство котлиновских корутин, где в том числе рассказывалась пара прекрасных детективных историй про их отладку.

Что я делал сегодня:

- Отлаживал зависание, которое оказалось просто ооооочень медленной работой приложения (сходил за кофе, вернулся, а оно возьми и заработай);

- Профилировал профилировщик (было круто!);

- Наблюдал, как рандомизированность структуры данных (skip list-а) вызывает спорадичную проблему.

---

Что я не делал сегодня:

- Не писал спеку.

Половину дня сегодня просидел в ГЭКе. И знаете, как же все-таки много можно сказать о человеке по его последнему слову на защите!

О чем он говорит: о себе или о других? Кого благодарит? Университет? Научрука? Рецензента за то, что тот дал ему шанс исправить критические недочеты? Родителей и семью за то, что верили в него? Свою девушку/парня за то, что терпели его этот последний год? Друга, который на первом курсе поделился шпорами по матану? Гёделя за его теорему о неполноте?

Вы удивитесь, как много бывает вариантов, и с какой разной интонацией люди высказывают эти свои финальные эмоции по поводу их обучения в университете. Вспоминается речь Эминема на церемонии принятия его в Rock & Roll Hall of Fame, где он тупо 5 минут подряд перечисляет всех корешей, которые помогали ему подняться. Нужно кому-то на защите сделать так же.

—

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

Чтобы таки написать многострадальную спеку, понадобилось простое советское "закрыться в переговорке одному на 4 часа с 21-00 до 1-00".

Все так, офис - топ.

Во время ковида продержался дома ровно неделю, потом вернулся в офис. Куда раньше, чем большинство коллег. Вообще, по факту с @conwor вдвоем сидели там, в окружении пустых коробок из под пиццы (уборщики то тоже на самоизоляции). Неплохое было время между прочим!

#деградировать_пришел

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

—

Это очень неприятно, но возможно скоро и мне придется отчислять студента за неуспеваемость. Что ж, one-to-one на сиспро уже были, теперь будет увольнение и exit interview.

Про Python и C очень смешно! Про ассемблер немножко больно.

Развлекайтесь: https://glif.app/@fab1an/glifs/clxtc53mi0000ghv10g6irjqj

StrStrFast (часть 1)

Вечер пятницы – самое время, чтобы рассказать очередную байку про отладку!

Недавно отлаживал прекрасную проблему – злостный и непонятный развал виртуальный машины вдрабадан. Доступа к среде, где все хоть иногда воспроизводится проблема у меня не было, так что это была отладка по переписке: скажи коллеге в другой части мира, какой следующий эксперимент провести => через пару дней получи новый крэшлог => внимательно вглядывайся в него => повторяй все сначала.

Через какое-то (угадайте, какое!) количество попыток (и экстренных собраний, на которых мне объясняли, что отладить нужно как можно быстрее, ведь это именно так работает, да), я нарыл следующий набор фактов:

1. Развал происходит в каком-то стороннем нативе, а не в коде виртуальной машины (уже победа, но вдруг все-таки мы виноваты? позвали его, например, не коряво);
2. Более конкретно, это всегда было связано с сишным методом с интригующим названием StrStrFast;
3. Если развал случался, то обязательно в некотором цикле, при том именно на 93837 итерации. Именно на ней!
4. Известна даже инструкция, где что-то идет не так – это vpcmpeqb ymm2, ymm0, YMMWORD PTR [r13+rax*1+0x0].

Инструкция не совсем обычная, из AVX, работает с 256-битными ymm регистрами, но в целом пока ничего криминального.
И в вообще казалось бы, ну и все: смотри, кто передал мусор в StrStrFast, доказывай, что проблема не на нашей стороне и ура. Но не тут то было, ведь есть еще пара фактов:

5. Все входные данные в StrStrFast корректны. Там реально две хорошие, понятные строчки, память не битая. Вторая строка, кстати, довольно короткая – всего 8 байт;
6. Когда происходит развал, значение выражения r13+rax*1+0x0, конечно, всегда разное, но, например, может быть таким: 0x7ffc0a803fe8;
7. При этом память по адресу из r13+rax*1+0x0 всегда доступна для чтения и записи.

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

—

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

Предлагаю вам сейчас остановиться, еще раз прочитать все вводные и предложить свою версию происходящего)

А я во второй части поста расскажу, как все было на самом деле ↓

#дух_машины

StrStrFast (часть 2, разгадка)

Разгадка на самом деле довольно простая, а ключ к ней – тот самый адрес 0x7ffc0a803fe8.

Что вам приходит на ум, когда вы на него смотрите? Правильно: он всего на 24 байта отстает от 7ffc0a804000. Который в свою очередь выровнен на 4К или 0x1000, а это уже прямое указание на то, что мы подошли максимально близко к концу страницы памяти, размер которых на этой системе как раз и равен 4К (соответственно их граница проходит по выровненным на это число адресам).

Если чуть покопать, то действительно увидим, что та самая короткая строчка на 8 байт была саллоцирована очень близко к концу страницы памяти. Она как раз влезала в эти оставшиеся 24 байта, вот аллокатор ее туда и определил.

—

А теперь еще раз смотрим на нашу инструкцию: vpcmpeqb ymm2, ymm0, YMMWORD PTR [r13+rax*1+0x0]. Она работает с 256-битными (т.е. с 32-байтовыми) размерами, но при этом ей вот дают адрес, на 24 байта отстающий от границы страницы.

В целом то все корректно, но вот что будет... если следующая за нашей страница еще не подключена? К ней никогда не обращались, никто туда ничего не писал и не протыкивал ее (зачем? наша строчка то помещалась в предыдущую!). А я вам скажу, что будет: исполнение vpcmpeqb вызовет UB, которое превращается в развал с завидным постоянством.

Занавес.

—

Из найденных мной хлебных крошек не пригодилась только информация о номере итерации, почему именно 93837? Это просто: на каждой итерации цикла выделялась память под новую строчку, а размеры так подобрались, что угодить именно в конец страницы мы могли как раз после такого количества итераций.

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

—

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

Нам же в свою очередь пришлось отучить аллокатор складывать объекты совсем уж впритык к концу страницы, чтобы больше не напарываться на такие вот проблемы. Забавно, что, как я постфактум узнал, с этим уже сталкивались в древние времена, но только не с ymm регистрами, а c xmm, из-за чего раньше уже был паддинг в конце страницы на 16 байт. Вот теперь увеличили его кратно, чтобы заодно покрыть и zmm-ы (на будущее).

—

Всем хороших выходных, будьте осторожны с ассемблерными вставками!

#дух_машины

Смотрите, какой классный паззлер от Андрея Паньгина в твиттере!

В обед прочитал твит, и прям в ресторане решил проверить пришедшее в голову решение (семья, конечно, была немного в шоке: взял отодвинул тарелку с пастой, достал ноут, что-то там пишет, бурчит, ни на что не реагирует).

Но тогда догадка не подтвердилась, даже после нескольких ее вариаций никакого NPE я не получил... все потому, что я неправильно оценил, насколько спорадичный эффект.

Вечером вернулся к этому и таки подтвердил свое решение, просто нужно было чуть больше везения :)

---

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

P.S. знание Java как языка здесь особо не нужно.

---

ха-ха, выходной прошел не зря))