что такое баг бери
ДИСКЛЕЙМЕР
ИСПОЛЬЗОВАНИЕ В РЕАЛЬНОМ КОДЕ ЗАПРЕЩЕНО!
АВТОР НЕ НЕСЁТ НИКАКОЙ ОТВЕТСТВЕННОСТИ И ВООБЩЕ БАКА!
Сколько же всего сложного и таинственного нас окружает.
Черные дыры и сновидения. Темная материя и подсознание. Корпускулярно-волновой дуализм и 1С.
И ведь думаешь, что знаешь эту «1Ску» как свои пять пальцев, но стоит случайно копнуть глубже. И очередная багофича. Да ешё и какая!
В этой статье рассмотрим секретный оператор ?
О нём мало кто знает, хоть он и существует как минимум с версии 8.0.
В последнее время я публикую на своём телеграм-канале разные хитрые задачки с подвохом для программистов 1С. Какие-то беру «по памяти», а какие-то «рождаю» в результате экспериментов. Об этом скоро выйдет отдельная статья. И вот в очередном тесте адекватности платформы случайно натыкаюсь на такую конструкцию:
Синтаксис-проверка прошла успешно. Никаких ошибок не высветилось. И, казалось бы, ошибка тогда должна произойти в момент выполнения.
Код успешно выполнился. Удивительно, но сработало! И тут меня понесло.
Как оказалось, знак ? ведёт себя крайне странно. Давайте посмотрим ещё раз прошлый пример.
Но что же тогда это:
В данном коде сначала идёт объявление переменной «А». И в А установлено числовое значение «1». А далее идёт наше сравнение с ?. Если бы под знаком вопроса скрывалось Неопределено, то мы бы не попали внутрь условия. А по скрину видно, что попали.
Ну ладно, значит «?» есть что-то другое. Попробуем вывести его в сообщение:
Очень странная ошибка. «Переменная не определена (Сообщить)». Ну допустим. Добавим тогда такую переменную:
Данный код компилируется без ошибок. И при выполнении в 1С сообщает «ТЕСТ». То есть значение переменной Сообщить
Выходит, что символ ? указывает на предыдущее слово в коде. В данном случае, перед ? было слово Сообщить. И поэтому 1С изначально поругалась, что такая переменная не определена. А когда мы добавили переменную Сообщить, то всё стало на свои места.
То есть наш код для 1С выглядит так:
А теперь вернемся к нашим предыдущим примерам и разберём что и как сработало.
Скорректируем же этот код так, как его видит 1С:
Теперь всё логично. А = А и поэтому условие выполняется.
А что с нашим самым первым примером?
На самом деле всё так же. Просто заменяем знак вопроса на предыдущее слово.
Использовать это в реальном коде нельзя!
Ведь мало ли когда это исправят. И неизвестно где это может аукнуться. Но раз уж мы эту багофичу нашли, то давайте уже и придумаем как её применить 😁🎉 Возможно, вы уже догадались.
Представляю вам инкремент на 1С!
Да, мы так долго ждали и вот он😅
На самом деле такой код можно ещё упросить:
Но такой вариант становится менее надежным. Ведь всё работает до тех пор, пока перед ? находится МояПеременная. Если же вставить после этого какое-то другое «слово», то всё порушится.
Поэтому 1С в таком коде вместо знака вопроса вставит «А»
Выходит, инкремент хоть и есть, но с особенностями 😁
Но зато появляется новая возможность применения:
В данном коде мы создали структуру и наполнили её объявленными ранее переменными. Тоже бывает удобно, когда нужно передать какой-то набор переменных метода в другой метод через структуру.
А вот ещё пример. Можно передать в какой-то метод или конструктор одно значение несколько раз:
А этот приводит отрицательные числа к положительным:
Подобным образом можно присваивать дефолтные значения необязательным параметрам:
Главное помнить, что знак ? берет именно предыдущее слово, поэтому вот так работать НЕ будет:
1С поругается, что Переменная не определена (Структура). Ведь перед последним знаком ? слово Структура
Но что если использовать символ ? в параметрах?
Сделаем процедуру с параметром ? :
Такую процедуру действительно возможно создать. И можно вызывать. Причем 1С понимает, что параметр обязательный и его необходимо передать.
Но мы можем сделать его необязательным:
И параметр не обязан быть единственным. Можно делать разными способами:
А можно использовать Знач
В стеке вызовов он отображается:
А попробуем добавить второй параметр ?
Формальный параметр с указанным именем уже определен (?)
Опираясь на текст ошибки, мы можем предположить, что 1С объявляет параметр с именем «?»
И когда мы пытаемся добавить ещё один такой параметр, то платформа ругается.
Но ещё раз взглянем на ошибку
Формальный параметр с указанным именем уже определен (?)
А вы встречали такое описание ошибки в 1С?
Но, возможно, это всё те вопросы, которые нам ещё предстоит разгадать. Секреты и загадки этой таинственной платформы под кодовым названием 1С.
Понравилась статья?
Поставьте лайк плюс. Пишите свои идеи и комментарии по теме. Статья будет дополняться.
И переходите к другим публикациям от автора:
Что такое баги, ворнинги и исключения в программировании
Разбираемся, какие бывают типы ошибок в программировании и как с ними справляться.
Многим известно слово баг (англ. bug — жук), которым называют ошибки в программах. Однако баг — это не совсем ошибка, а скорее неожиданный результат работы. Также есть и другие термины: ворнинг, исключение, утечка.
В этой статье мы на примере C++ разберём, что же значат все эти слова и как эти проблемы влияют на эффективность программы.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Ошибки в программировании
Словом «ошибка» (англ. error) можно описать любую проблему, но чаще всего под ним подразумевают синтаксическую ошибку — некорректно написанный код, который даже не скомпилируется:
Компилятор тут же скажет, что в коде ошибка и скорее всего не хватает запятой или точки с запятой.
Также существуют ворнинги (англ. warning — предупреждение). Они не являются ошибками, поэтому программа всё равно будет собрана. Вот пример:
Предупреждения не являются чем-то критичным, но могут иметь негативные последствия. Например, ваша программа будет использовать больше памяти, чем должна. Так как C++ нужен в том числе и для разработки высоконагруженных систем, этого допускать нельзя.
После восклицательного знака в треугольнике — количество предупреждений
Третий вид ошибок — ошибки сегментации (англ. segmentation fault, сокр. segfault, жарг. сегфолт). Они возникают, если программа пытается записать что-то в ячейку, недоступную для записи. Например:
Вот результат работы такого кода:
Баги в программах
Мы выяснили, что баг — это не совсем ошибка, а скорее неожиданное поведение программы или результат такого поведения. Баги могут быть чем-то забавным или неприятным. Например, как в играх:
Но они могут привести и к более серьёзным последствиям. Если неправильно спроектировать работу многопоточного приложения, то потоки будут постоянно опережать друг друга. Например, сообщение об ошибке из одного потока может опоздать на миллисекунду, из-за чего второй поток подумает, что никакой ошибки не было, и продолжит работу.
Если ваш код приводит в действие какое-нибудь потенциально опасное устройство, то ценой такой ошибки может быть чья-нибудь жизнь. Такое случилось с кодом для аппарата лучевой терапии Therac-25 — как минимум два человека умерло и ещё больше пострадали из-за превышения дозы радиации.
Исключения в программах
Также во время работы программы могут возникать ситуации, которые мешают корректной работе программы. Например, если вы просите пользователя ввести число, а он вводит строку.
Конвертировать введённое значение не всегда возможно, поэтому функция, которая занимается преобразованием, «выбрасывает» исключение (англ. exception). Это специальное сообщение говорит о том, что что-то идёт не так.
Если разработчик не описывает логику работы программы при вы выбрасывании исключения, то программа аварийно закрывается. Подробнее мы рассказали об этом в статье про ввод и конвертацию в C++.
Одно из самых известных исключений — переполнение стека (англ. stack overflow). В честь него даже назвали сайт, на котором программисты ищут помощь в решении своих проблем.
Компилятор C++ при этом может выдать ошибку сегментации, а не сообщение о переполнении стека:
Вот аналогичный код на языке C#:
Однако сообщение в этот раз более конкретное:
В обоих случаях программа завершается, потому что не может дальше корректно работать.
Похожая ситуация — переполнение буфера (англ. buffer overflow). Она происходит, когда записываемое значение больше выделенной области в памяти.
Обратите внимание, что мы получили предупреждение об арифметическом переполнении (англ. integer overflow):
Тем не менее программа скомпилировалась. Если же такая ситуация возникнет во время вычислений, то мы можем не получить предупреждения.
Арифметическое переполнение стало причиной одной из самых дорогих аварий, произошедших из-за ошибки в коде. В 1996 году ракета-носитель «Ариан-5» взорвалась на 40-й секунде полёта — потери оценивают в 360–500 миллионов долларов.
Как избежать всех этих ошибок
К сожалению, вручную всё это заметить и исправить не получится. Однако существуют различные инструменты и технологии, которые могут помочь.
Один из таких инструментов — отладчик. Он помогает контролировать ход работы программы, чтобы отслеживать разные показатели.
Второй, более эффективный метод — unit-тесты. Они представляют из себя набор описанных ситуаций для каждого компонента программы с указанием ожидаемого поведения.
Например, у вас есть функция sum (int a, int b), которая возвращает сумму двух чисел. Вы можете написать unit-тесты, чтобы проверять следующие ситуации:
Если какой-то из этих тестов не пройден, вы узнаете об этом и сможете всё исправить. Это намного быстрее, чем проверять всё вручную.
Заключение
Ошибок существует слишком много. При этом самые опасные тяжелее обнаружить, что только усугубляет ситуацию.
Если вы хотите научиться писать качественный код и находить в нём ошибки, вы можете записаться на наш курс по разработке на C++.
Смартфоны BlackBerry
По возрастанию цены
Недавно просмотренные
Доставка со страховкой
Посылки застрахованы от несчастных случаев
Поставка оригинального товара с 2007 года
Наши специалисты помогут в сложных вопросах
Авторизованный сервисный центр и полноценная гарантия
BlackBerry Russia – надежный поставщик товаров и услуг для бизнеса с 2007 года.
©2007 – 2021 BLACKBERRY RUSSIA
Работает в ОБЛАКЕ
Подпишитесь на нас
©2007 – 2021 BLACKBERRY RUSSIA
Работает в ОБЛАКЕ
Баги и ошибки — как искусство
Введение
Баг или же ошибка, связанная с нарушениями в целостности программы или программного кода, в этом кратком пособии я хочу рассказать об этих странных, забавных и порой неизвестных вещах, надеюсь, что это пособие поможет вам понять, как я смотрю на этот чудесный мир ошибок и недоработок, многие воспринимают их как что-то бесящее и крайне надоедливое, с определённой стороны они все правы.
Что такое “БАГ”
В программировании баг (англ. bug — жук)— жаргонное слово, обычно обозначающее ошибку в программе или системе, которая выдает неожиданный или неправильный результат. Большинство багов возникают из-за ошибок, сделанных разработчиками программы в её исходном коде, либо в её дизайне. Также некоторые баги возникают из-за некорректной работы компилятора, вырабатывающего некорректный код. Программу, которая содержит большое число багов и/или баги, серьёзно ограничивающие её работоспособность, называют нестабильной или, на жаргонном языке, “глючной”, “глюкнутой”, “забагованной”, “бажной”, “баг (а) нутой” (англ. unstable, buggy). Термин «баг» обычно употребляется в отношении ошибок, проявляющих себя на стадии работы программы, в отличие, например, от ошибок проектирования или синтаксических ошибок. Отчет, содержащий информацию о баге, также называют отчетом об ошибке или отчетом о проблеме (англ. bug report). Отчет о критической проблеме (англ. crash), вызывающей аварийное завершение программы, называют крэш репортом (англ. crash report). «Баги» локализуются и устраняются в процессе тестирования и отладки программы. Возможны ситуации, при которых ошибки остаются во внутреннем коде или программе они могут остаться не замеченными и обнаруженными уже при тестировании или выпуске программы или игры. Такие ситуации исправляются так называемыми “патчами” (англ. patch), выпускаются они как можно скорее стараясь залатать все дыры и проблемы, когда патч готов разработчик или программист выпускает “патч ноут” (англ. Patch note) список изменений и исправлений. На этом с терминологией всё, приступим к практике.
Как выглядит баг
И как его исправить
Чаще всего их можно обнаружить на ранних стадиях разработки, например когда игра компилируется выскакивают ошибки или сообщения о неполадках, но бывает так что их можно и не заметить особенно когда было проделано много работы и ошибка не проявилась, для такого существуют тестировщики, люди которые 24 часа в сутки проверяют каждый угол на предмет ошибок, что бы при игре в условный Fallout 76 ваша игра окончательно не сломалась. Правда в конце концов люди не могут увидеть всё и для этого требуется ещё больше времени работы и труда, но даже при этом некоторые ошибки невозможно исправить, такие ошибки не критичны и ведь зачем их исправлять если это не приносит убытков, поэтому огромное количество багов не исправляются разработчиками, их исправляют игроки и просто не равнодушные люди. Эти вещи называются фиксами. Перейдём к виновнику этой книги. Самое простое это пропавшая текстура, это может быть прозрачная область или разноцветные пиксели, происходит если текстура пропала из игры. Более критичными являются ошибки в коде, прыгнул куда-то не туда и вот игра уже зависает, выдаёт ошибку и ломается, тут всё дело в том, что где-то есть сломанная частица кода, которая при активации выдаёт ошибку. Есть ошибки в тексте и звуке, к примеру вместо звука меча проигрывается звук курицы, а в субтитрах написано, что это была машина, тут играет человеческий фактор, ещё можно застрять в текстуре или сломать цепочку событий в игре. Всё исправить невозможно в силу того, что на таком уровне заметить их трудно, бывает они возникают из неоткуда, но всегда весело их находить если они не критичны.
Место без текстур в Fallout76 – источник
Творческие решения
Но у ошибок нашли хорошую соревновательную сторону, спидраны — забеги по играм на скорость, проходить игру просто это так скучно, а вот с ошибками это совсем другое дело, сократить игру в 3 раза прыгая за текстуры, профессионалам на это дело расплюснуть, разбирать спидраны я не буду всё это уже сделали за меня, хочу лишь сказать что это удивительно как люди используют ошибки и недоработки, рассчитывают всё до пикселя и всё это основано на ошибках, багах и глитчах.
Критические ситуации
За примером далеко ходить не надо, можно вспомнить лица из Assassin’s Creed Unity, проблема была вызвана несовместимостью с некоторыми видеокартами, это ошибка была исправлена в патче первого дня но оставила свой отпечаток на и так большом пласте ненависти ввиду отсутствия оптимизации и багов, вот что об этом говорит главный творческий руководитель Ubisoft Жан Жесдон:
Если вы поиграете сейчас, со всеми исправлениями, — это будет очень красивая и хорошая игра. Иными словами, вероятно, мы подлетели слишком близко к Солнцу и утратили самоконтроль.
Именно поэтому Syndicate концентрировалась на качестве, с чем команда отлично справилась. Жан Жесдон
В заключении хотел бы сказать что баги и ошибки порадили целые сегменты в разных культурах и стали большой частью игр и игровой индустрии. _DeVloPPeR_
Bug Bounty: заработай на чужих ошибках
В этой статье я расскажу о Bug Bounty программах, их плюсах и минусах, а также как на этом зарабатывают.
В первую очередь давайте определим что такое Bug Bounty: программа выплата награды за обнаружение проблем в безопасности сервисов и приложений компании. На русский язык уместнее всего это переводится как «Охота за ошибками».
Т.е. это некий свод правил «взаимодействия» с информационными ресурсами компании. Обычно в него входит регламент проведения программы, перечень ресурсов, описание принимаемых уязвимостей, размеры вознаграждения. В классическом исполнении это описание того, что можно «ломать» и сколько багхантер получит за ту или иную уязвимость.
Так выглядит Bug Bounty снаружи. Что это дает компании? В первую очередь непрерывный процесс «проверки на прочность»: специалисты с различным уровнем знаний, инструментарием и часовыми поясами в режиме нон-стоп атакуют ресурсы компании. Со стороны компании задействованы ресурсы на:
Bug Bounty плюсы и минусы
Теперь остановимся на плюсах и минусах Bug Bounty программ.
Очевидными плюсами будет:
Очевидными минусами будет:
Зачастую многие багхантеры, участвующие в программах Bug Bounty ограничиваются своими «коронными» фишками, и не исследуют что-то другое, либо наоборот, ставят под сканеры все подряд в надежде уловить хоть что-то. Это дает разноплановый, но не полный подход к тестированию. Также, огромное количество фолс срабатываний сканеров может завалить команду разработчиков ненужной работой (это и дополнительные проверки и отклики по каждому репорту — которых может быть очень много).
Открытые программы
Большинство компаний представлено на площадках — агрегаторах, таких как HackerOne или BugCrowd.
Многие российские компании открыли как собственные программы, так и профили на HackerOne. Среди них такие компании, как: Яндекс, Майл.ру, QiWi, Вконтакте и многие другие. Да что говорить, если даже у Пентагона есть своя программа Bug Bounty. (Взломать Пентагон, получить деньги и остаться на свободе — похоже на мечту хакера, но уже суровая реальность).
Вот, например, оценка стоимости обнаруженных уязвимостей в программе «Охота за ошибками» — Яндекс:
Наиболее «дорогие ошибки»
Выявление известной уязвимости:
Россиянин обнаружил в программном обеспечении соцсети ошибку, которая с помощью специальной картинки позволяла запускать на ее серверах произвольный код. Для этого необходимо было воспользоваться уязвимостью в сервисе ImageMagick, предназначенном для быстрого масштабирования и конвертации изображений в новостной ленте Facebook, сообщает Лента.ру. Леонов случайно наткнулся на ошибку во время тестирования стороннего сервиса, изучил ее и представил всю необходимую информацию техническим службам Facebook, которые устранили уязвимость в ноябре 2016 года. В итоге соцсеть выплатила хакеру вознаграждение в 40 тысяч долларов. В 2014 году рекордную сумму в 33,5 тысяч долларов получил от Facebook специалист по кибербезопасности Реджинальдо Сильва.
Хочу участвовать, что надо делать?
Для тех, кто решил попробовать свои силы и возможности в поиске ошибок могу посоветовать несколько основных этапов, которые приведут к победе:
Следите за новостями. Обновился скоп программы — бегом проверять новые сервисы. Производитель добавил новый функционал, расширил старый или интегрировал сторонний сервис? — большая возможность, особенно в сложной инфраструктуре допустить ошибку.
Упорство. Скрупулезное исследование, не упускать никаких деталей. Хорошая практика будет периодически сравнивать результаты прошлых проверок с текущем состоянием системы.
Поиск. Ищите и обрящете. Большинство крупных багов находят на «не публичных» поддоменах и директориях. Здесь вам пригодятся инструменты по выявлению поддоменов и хорошие листы словарей для брута директорий и поддоменов.
Исследование. Отложите автоматические сканеры, просеивайте веб-приложение (а большинство Bug Bounty связано именно с вебом) как песок сквозь сито для поиска крупинок золота. Здесь я рекомендую использовать Burp Suite или Owasp Zap — лучше инструментов нет. Почти все крупные победы в баутни — результат работы с этими инструментами (практически на любом публичном репорте можно это увидеть).
Исследуйте. Скачайте приложение для локального исследования, если это возможно. Читайте отчеты других участников — это может дать пищу для ума. Тот же взлом фейсбука — многие российские багхантеры видели этот поддомен, даже пытались с ним что-то делать — но «не докрутили». Хорошим подспорьем для этого будет ресурс: The unofficial HackerOne disclosure Timeline