Вот несколько забавных примеров исследования программ на прочность. Иногда весь секрет нахождения ошибки в программе заключается в том, чтобы сделать что-то не совсем обычное, такое, что выходит за рамки того, чего ожидали разработчики, или того, на устойчивость к чему они тестировали программу.
Ошибка Шрёдингера
В 2013 году вышел дистрибутив Fedora 19. Кодовым именем этого релиза было Schrdingers Cat. Использование этого имени привело к обнаружению ошибки в системе сообщений об ошибках, используемой командой Fedora. Теперь это исправлено, но тогда это была досадная, хотя и забавная ошибка.
Если рассказать об этом в двух словах, то дело было в том, что кодовое имя содержало особые символы ' и (прошу прощения у тех, кто пользуется такими символами постоянно).
Отсюда и началось моё увлечение поиском слабых мест программного обеспечения.
Launchpad
Команда Fedora использовала для отслеживания ошибок платформу BugZilla, а команда Ubuntu платформу Launchpad. В то время, когда в сообществе Fedora произошла вышеописанная проблема, кто-то из команды Launchpad с уверенностью заявил, что подобная проблема не возникла бы на его платформе. Мне это утверждение показалось слишком смелым, мне не верилось в то, что платформа Launchpad протестирована настолько хорошо, что надёжно защищена от любых ошибок.
Тогда я взял и поменял моё имя в профиле Launchpad, добавив туда эмотиконов.
Эмотиконы в профиле
Thunder
В Launchpad имеется система отслеживания ошибок, рассылающая электронные письма. Я проявлял активность в деле поиска ошибок, а это значит, что другие разработчики получали письма от меня через Launchpad. Те разработчики, которые пользовались Thunderbird, столкнулись с неожиданностью, показанной ниже.
Странное поведение почтового клиента
Я не смог найти скриншот почтового клиента с моим письмом, который кто-то мне прислал, поэтому я взял вышеприведённую иллюстрацию из сообщения об ошибке 1779569.
В Thunderbird обнаружилась ошибка, которую уже исправили. Мне показалось интересным то, что простое добавление симпатичных значков в профиль на Launchpad оказало непреднамеренное воздействие на программу, которая, судя по всему, никак с Launchpad не связана. Что ж. Это большой успех.
История о повторениях
Было время, когда мне интересно было зажимать какие-нибудь кнопки и наблюдать за тем, что произойдёт. Я, делая это, размышлял о том, что случится, если на некую кнопку, скажем, усядется кошка. Опыт прошлых лет подтверждает то, что кошки вполне способны отыскивать разного рода проблемы.
Mute Mute Mute Mute
На моей клавиатуре ThinkPad, в верхнем ряду клавиш, есть кнопка для включения и выключения микрофона. В этой кнопке имеется светодиод, что позволяет пользователю знать о состоянии микрофона. Если светодиод включён микрофон выключен.
Кнопка для включения и выключения микрофона в верхнем ряду клавиш
Я обнаружил, что если удерживать эту кнопку, она переходит в режим автоповтора. Это вполне понятно, но в правом верхнем углу экрана имеется индикатор, указывающий на состояние микрофона. К сожалению, если зажать кнопку на секунду-другую, светодиод и индикатор, в итоге, теряют синхронизацию друг с другом. Светодиод указывает на то, что микрофон отключён, а индикатор сообщает об обратном. И чему, скажите на милость, мне верить?
PrtScScScScSc
Если, работая в большинстве операционных систем (но не в MacOS), нажать на кнопку PrtSc (Print Screen), это приведёт к выполнению некоего действия по созданию копии того, что отображается на экране. В Ubuntu это действие сопровождается чем-то вроде щелчка затвора фотоаппарата: экран мигает, уходит в чёрное, воспроизводится соответствующий звук. Всё это подтверждает создание копии экрана. Создание копии экрана занимает некоторое время, графический эффект выводится между нажатием на клавишу и возвращением рабочего стола в обычное состояние.
Я обнаружил, что, если зажать клавишу PrtSc, она тоже переходит в режим автоповтора. Эта проблема выглядела несколько серьёзнее, чем вышеописанная, так как после того, как начинается автоповтор, повторяющиеся графические эффекты, сопровождающие снятие копии экрана, перегружают процессор, в результате чего скриншоты делаются всё медленнее и медленнее. При этом кажется, что с компьютером случилось что-то нехорошее: экран чёрный, а процессор чем-то очень сильно занят, что приводит к раскручиванию вентилятора системы охлаждения.
Я обсудил это в IRC с Себом и Уиллом из команды Ubuntu, отвечающей за рабочий стол. Возможно, мне, прежде чем задавать вопрос, стоило предупредить Уилла о том, к чему приводит длительное нажатие на PrtSc. Вот драматизированная реконструкция той знаменательной беседы:
<popey> Есть тут кто, с кем можно поговорить о последнем релизе? Если вы зажмёте клавишу PrtSc уйдёт ли она в режим автоповтора?<seb12> А зачем вообще это делать?<willcooke> Погоди, дай проверю<willcooke> ** Отключён<popey> Ох! Мне стоило сказать Уиллу о том, что он увидит чёрный экран.
Позже эту проблему тоже исправили.
Где-то год назад я делал короткий доклад в компании Sprint, на котором я хотел представить минимальный snap-пакет. Я готовился к этому докладу минут 30 и толком всё не протестировал до тех пор, пока не оказался на сцене, перед половиной сотрудников компании.
Я, чтобы было интереснее, решил создать вместе со зрителями snap-пакет, названный null, стремясь сделать его, на что указывает его имя, почти совсем пустым. Я, заполняя метаданные пакета, вроде имени и описания, везде вставил null. Локально пакет отлично собирался и устанавливался. Тогда я, чтобы стало ещё интереснее, зарегистрировал имя null в на площадке Snap Store и попытался опубликовать там моё творение. Так все желающие могли бы с ним ознакомиться.
В ходе публикации пакета был, как и предполагалось, показан индикатор загрузки, но крутился он дольше, чем можно было бы ожидать при публикации, в общем-то, пустого пакета. Я, пребывая на сцене, несколько растерялся, длилось это моё состояние до тех пор, пока кто-то из команды, занимающейся Snap Store, сидящий в зале, не взял микрофон и не заговорил. Звали этого человека Дэниел, а сказал он вот что: Это никогда не закончится вы повалили бэкенд. Ничего ж себе!
Когда snap-пакеты загружаются в Snap Store, проводятся их проверки, вроде проверок безопасности. То, что я воспользовался ключевым словом null (возможно зарезервированным), похоже, запутало серверный скрипт, занимающийся проверками пакетов. И это всё произошло, так сказать, в прямом эфире, на сцене, перед целой толпой зрителей. Отличный получился финал для доклада.
Дэниел сообщил об ошибке бэкенда, она была исправлена очень быстро. Мой snap-пакет null теперь успешно опубликован, а пользуется им 100 человек число это, учитывая то, что это за пакет, недоступно пониманию.
Пользователи пакета null
Эксперименты с далеко идущими последствиями
Эмотиконы в имени пользователя, необычные имена для программных пакетов у всего этого есть одна интересная особенность. Заключается она в том, что подобные эксперименты не вызывают, лишь однажды, какую-то одну проблему. Они вызывают целый каскад проблем.
Null по почте
Люди, публикующие snap-пакеты, ежемесячно получают электронное письмо со сводной информацией по активным пользователям их пакетов.
Сведения о пакетах
Я недавно получил подобное письмо, которое было обрезано как раз там, где в нём было слово null. Это случилось через 18 месяцев после моего доклада и после публикации snap-пакета. В общем, подобные эксперименты это бесконечный источник интересных находок.
Я сообщил об этой ошибке тем, кто отвечает за письма, и теперь всё исправлено.
Шествие null продолжается
У Snap Store имеется очаровательный опенсорсный веб-фронтенд, исходный код которого опубликован на GitHub. Я обратил внимание на то, что некоторые части пользовательского интерфейса не работают в тот момент, когда я просматриваю сведения по моему (теперь уже опубликованному) snap-пакету null. Это оказалась ещё одна ошибка, которая теперь тоже исправлена.
Мне понравился один комментарий по этому поводу: То, что связано с вашим snap-пакетом null, теперь должно работать нормально (до следующей null-ошибки).
Замечательно.
Двигайся быстро и ломай всё вокруг
Всё то, о чём я рассказал, кажется мне лишь небольшими приятными достижениями. Я понимаю, что кто-то разведёт руками и со вздохом скажет, что системы, в которых я обнаружил ошибки, не были нормально протестированы перед релизом. Вероятно, для проверки систем на подобные ошибки были предусмотрены какие-то тесты. Но я полагаю, что невозможно предусмотреть абсолютно всё то, часто очень необычное, что пользователи могут делать с программами.
Что касается меня, то я планирую продолжать зажимать кнопки, щёлкать по тому, по чему щёлкать, вроде, и не надо, и подбирать необычные имена для того, что создаю. А это значит, что тот, кто придёт в некую систему после меня, не столкнётся с теми ошибками, которые удалось найти мне.
Сталкивались ли вы с ошибками, появляющимися при необычном использовании неких программ или устройств?
