Мне очень нравится ломать что-то, связанное с компьютерами. Хотя я и не QA-специалист, и не профессионал, работающий в сфере безопасности, я развил в себе способность делать «глупости», которые заставляют программы давать сбои. Некоторые мои друзья-разработчики жалели о том, что не показывали мне свои программы до их выпуска. Дело в том, что иногда я нахожу досадные ошибки в программах сразу после их выхода в свет.
Вот несколько забавных примеров исследования программ на прочность. Иногда весь секрет нахождения ошибки в программе заключается в том, чтобы сделать что-то не совсем обычное, такое, что выходит за рамки того, чего ожидали разработчики, или того, на устойчивость к чему они тестировали программу.
В 2013 году вышел дистрибутив Fedora 19. Кодовым именем этого релиза было «Schrödinger’s Cat». Использование этого имени привело к обнаружению ошибки в системе сообщений об ошибках, используемой командой Fedora. Теперь это исправлено, но тогда это была досадная, хотя и забавная ошибка.
Если рассказать об этом в двух словах, то дело было в том, что кодовое имя содержало «особые» символы «'» и «ö» (прошу прощения у тех, кто пользуется такими символами постоянно).
Отсюда и началось моё увлечение поиском слабых мест программного обеспечения.
Команда Fedora использовала для отслеживания ошибок платформу BugZilla, а команда Ubuntu — платформу Launchpad. В то время, когда в сообществе Fedora произошла вышеописанная проблема, кто-то из команды Launchpad с уверенностью заявил, что подобная проблема не возникла бы на его платформе. Мне это утверждение показалось слишком смелым, мне не верилось в то, что платформа Launchpad протестирована настолько хорошо, что надёжно защищена от любых ошибок.
Тогда я взял и поменял моё имя в профиле Launchpad, добавив туда эмотиконов.
Эмотиконы в профиле
В Launchpad имеется система отслеживания ошибок, рассылающая электронные письма. Я проявлял активность в деле поиска ошибок, а это значит, что другие разработчики получали письма от меня через Launchpad. Те разработчики, которые пользовались Thunderbird, столкнулись с неожиданностью, показанной ниже.
Странное поведение почтового клиента
Я не смог найти скриншот почтового клиента с моим письмом, который кто-то мне прислал, поэтому я взял вышеприведённую иллюстрацию из сообщения об ошибке 1779569.
В Thunderbird обнаружилась ошибка, которую уже исправили. Мне показалось интересным то, что простое добавление симпатичных значков в профиль на Launchpad оказало непреднамеренное воздействие на программу, которая, судя по всему, никак с Launchpad не связана. Что ж. Это — большой успех.
Было время, когда мне интересно было зажимать какие-нибудь кнопки и наблюдать за тем, что произойдёт. Я, делая это, размышлял о том, что случится, если на некую кнопку, скажем, усядется кошка. Опыт прошлых лет подтверждает то, что кошки вполне способны отыскивать разного рода проблемы.
На моей клавиатуре ThinkPad, в верхнем ряду клавиш, есть кнопка для включения и выключения микрофона. В этой кнопке имеется светодиод, что позволяет пользователю знать о состоянии микрофона. Если светодиод включён — микрофон выключен.
Кнопка для включения и выключения микрофона в верхнем ряду клавиш
Я обнаружил, что если удерживать эту кнопку, она переходит в режим автоповтора. Это вполне понятно, но в правом верхнем углу экрана имеется индикатор, указывающий на состояние микрофона. К сожалению, если зажать кнопку на секунду-другую, светодиод и индикатор, в итоге, теряют синхронизацию друг с другом. Светодиод указывает на то, что микрофон отключён, а индикатор сообщает об обратном. И чему, скажите на милость, мне верить?
Если, работая в большинстве операционных систем (но не в MacOS), нажать на кнопку PrtSc (Print Screen), это приведёт к выполнению некоего действия по созданию копии того, что отображается на экране. В Ubuntu это действие сопровождается чем-то вроде «щелчка затвора фотоаппарата»: экран мигает, уходит в чёрное, воспроизводится соответствующий звук. Всё это подтверждает создание копии экрана. Создание копии экрана занимает некоторое время, графический эффект выводится между нажатием на клавишу и возвращением рабочего стола в обычное состояние.
Я обнаружил, что, если зажать клавишу PrtSc, она тоже переходит в режим автоповтора. Эта проблема выглядела несколько серьёзнее, чем вышеописанная, так как после того, как начинается автоповтор, повторяющиеся графические эффекты, сопровождающие снятие копии экрана, перегружают процессор, в результате чего скриншоты делаются всё медленнее и медленнее. При этом кажется, что с компьютером случилось что-то нехорошее: экран чёрный, а процессор чем-то очень сильно занят, что приводит к раскручиванию вентилятора системы охлаждения.
Я обсудил это в IRC с Себом и Уиллом из команды Ubuntu, отвечающей за рабочий стол. Возможно, мне, прежде чем задавать вопрос, стоило предупредить Уилла о том, к чему приводит длительное нажатие на PrtSc. Вот драматизированная реконструкция той знаменательной беседы:
Позже эту проблему тоже исправили.
Где-то год назад я делал короткий доклад в компании Sprint, на котором я хотел представить минимальный snap-пакет. Я «готовился» к этому докладу минут 30 и толком всё не протестировал до тех пор, пока не оказался на сцене, перед половиной сотрудников компании.
Я, чтобы было интереснее, решил создать вместе со зрителями snap-пакет, названный null, стремясь сделать его, на что указывает его имя, почти совсем пустым. Я, заполняя метаданные пакета, вроде имени и описания, везде вставил null. Локально пакет отлично собирался и устанавливался. Тогда я, чтобы стало ещё интереснее, зарегистрировал имя null на площадке Snap Store и попытался опубликовать там моё творение. Так все желающие могли бы с ним ознакомиться.
В ходе публикации пакета был, как и предполагалось, показан индикатор загрузки, но крутился он дольше, чем можно было бы ожидать при публикации, в общем-то, пустого пакета. Я, пребывая на сцене, несколько растерялся, длилось это моё состояние до тех пор, пока кто-то из команды, занимающейся Snap Store, сидящий в зале, не взял микрофон и не заговорил. Звали этого человека Дэниел, а сказал он вот что: «Это никогда не закончится — вы повалили бэкенд». Ничего ж себе!
Когда snap-пакеты загружаются в Snap Store, проводятся их проверки, вроде проверок безопасности. То, что я воспользовался ключевым словом null (возможно — зарезервированным), похоже, запутало серверный скрипт, занимающийся проверками пакетов. И это всё произошло, так сказать, «в прямом эфире», на сцене, перед целой толпой зрителей. Отличный получился финал для доклада.
Дэниел сообщил об ошибке бэкенда, она была исправлена очень быстро. Мой snap-пакет null теперь успешно опубликован, а пользуется им 100 человек — число это, учитывая то, что это за пакет, недоступно пониманию.
Пользователи пакета null
Эмотиконы в имени пользователя, необычные имена для программных пакетов — у всего этого есть одна интересная особенность. Заключается она в том, что подобные эксперименты не вызывают, лишь однажды, какую-то одну проблему. Они вызывают целый каскад проблем.
Люди, публикующие snap-пакеты, ежемесячно получают электронное письмо со сводной информацией по активным пользователям их пакетов.
Сведения о пакетах
Я недавно получил подобное письмо, которое было обрезано как раз там, где в нём было слово null. Это случилось через 18 месяцев после моего доклада и после публикации snap-пакета. В общем, подобные эксперименты — это бесконечный источник интересных находок.
Я сообщил об этой ошибке тем, кто отвечает за письма, и теперь всё исправлено.
У Snap Store имеется очаровательный опенсорсный веб-фронтенд, исходный код которого опубликован на GitHub. Я обратил внимание на то, что некоторые части пользовательского интерфейса не работают в тот момент, когда я просматриваю сведения по моему (теперь уже опубликованному) snap-пакету null. Это оказалась ещё одна ошибка, которая теперь тоже исправлена.
Мне понравился один комментарий по этому поводу: «То, что связано с вашим snap-пакетом null, теперь должно работать нормально (до следующей null-ошибки)».
Замечательно.
Всё то, о чём я рассказал, кажется мне лишь небольшими приятными достижениями. Я понимаю, что кто-то разведёт руками и со вздохом скажет, что системы, в которых я обнаружил ошибки, не были нормально протестированы перед релизом. Вероятно, для проверки систем на подобные ошибки были предусмотрены какие-то тесты. Но я полагаю, что невозможно предусмотреть абсолютно всё то, часто — очень необычное, что пользователи могут делать с программами.
Что касается меня, то я планирую продолжать зажимать кнопки, щёлкать по тому, по чему щёлкать, вроде, и не надо, и подбирать необычные имена для того, что создаю. А это значит, что тот, кто придёт в некую систему после меня, не столкнётся с теми ошибками, которые удалось найти мне.
Сталкивались ли вы с ошибками, появляющимися при необычном использовании неких программ или устройств?
Вот несколько забавных примеров исследования программ на прочность. Иногда весь секрет нахождения ошибки в программе заключается в том, чтобы сделать что-то не совсем обычное, такое, что выходит за рамки того, чего ожидали разработчики, или того, на устойчивость к чему они тестировали программу.
Ошибка Шрёдингера
В 2013 году вышел дистрибутив Fedora 19. Кодовым именем этого релиза было «Schrödinger’s 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-ошибки)».
Замечательно.
Двигайся быстро и ломай всё вокруг
Всё то, о чём я рассказал, кажется мне лишь небольшими приятными достижениями. Я понимаю, что кто-то разведёт руками и со вздохом скажет, что системы, в которых я обнаружил ошибки, не были нормально протестированы перед релизом. Вероятно, для проверки систем на подобные ошибки были предусмотрены какие-то тесты. Но я полагаю, что невозможно предусмотреть абсолютно всё то, часто — очень необычное, что пользователи могут делать с программами.
Что касается меня, то я планирую продолжать зажимать кнопки, щёлкать по тому, по чему щёлкать, вроде, и не надо, и подбирать необычные имена для того, что создаю. А это значит, что тот, кто придёт в некую систему после меня, не столкнётся с теми ошибками, которые удалось найти мне.
Сталкивались ли вы с ошибками, появляющимися при необычном использовании неких программ или устройств?
