Иногда возникают ситуации, когда стандартных средств отладки недостаточно.
Например, в iOS 4.1 была возможность использовать valgrind в симуляторе. А в Lion x86_64 и iOS 5 valgrind работать уже перестал.
Это связано с 64-битной архитектурой и изменениями в симуляторе (в valgrind есть ряд
недоработок).
С переходом на ARC метод отладки retain исчез:
- (id) retain
{
// Break here to see who is retaining me.
return [super retain];
}
В связи с испорченным местными властями отпуском приходится занимать свое время чем-нибудь интересным. Например, подлечить старую игрушку, косяки которой не позволяют нормально поиграть на современных ОС, либо поменять несколько байтов для получения разных extra-возможностей just for fun. Подопытным будет игра из далекого 2000 года под названием Hogs of War. Если кто не знает, то это turn-based стратегия, где вам дается команда хрюшек, с помощью которых вы должны ни много ни мало, завоевать мир. В процессе игры в зависимости от результатов можно модифицировать каждую хрюшку, например повысив её в звании. В 2009 Atari объявила о продолжении игры в виде разработки HOW2, но по последним данным проект свернули из-за недостатка финансирования. Ничего приятного.
Цель этой части: исправление бага, при котором блокируется весь рабочий стол, если произошел appcrash по какой-либо причине и подготовка приложения для работы в экранном режиме для упрощения отладки.
Читать полностью »
В данной статье я опишу основные возможности Perl отладчика, которые позволят вам ускорить поиск ошибок в ваших программах.
Прежде чем я начну описывать работу с отладчиком, приведу несколько советов, которые помогут выявить некоторые типичные ошибки, еще до запуска debugger:
Теперь непосредственно перейдем к возможностям, которые предоставляет Perl Debugger.
Читать полностью »
Доброго времени суток!
Однажды передо мною встала задача отловить непонятное падение в моем приложении. Насколько я знал тогда, Android NDK предоставлял возможность отлаживать C++ код, однако я смутно представлял себе, как это сделать. К сожалению, толковой информации по отладке нативного кода было очень мало. Потратив на это дело несколько вечеров, я все-таки разобрался и наладил отладку. Сейчас я расскажу о том, как это можно сделать и расскажу о том, какие грабли могут ожидать вас, если вы задумаете повторить мой путь.
Отладка — неизбежный и зачастую очень длительный этап разработки любого приложения. Клиентская веб-разработка в этом смысле не исключение, более того, здесь этот вопрос стоит особенно остро. Если при отладке backend’а область действий программиста ограничена инструментом разработки, то в frontend’е задачу отладки осложняют многочисленные внешние факторы — браузеры. С их многообразием и различиями приходится волей-неволей считаться любому веб-разработчику. Об этом и пойдет речь далее.
Данная статья не претендует на оригинальность. Вполне возможно, что что-то подобное уже было написано ранее кем-то другим. Единственной целью при ее написании было желание автора поделиться своим опытом в отладке JavaScript. Автор уважает мнения других хабрапользователей и никому не навязывает свою точку зрения.
Проблема кроссбраузерности в отладке уже неоднократно рассматривалась на Хабре (1, 2, 3 и др.). Но к сожалению, во всех статьях, ранее освещавших этот вопрос, применялся один и тот же подход к его решению: использование инструментов отладки, специфичных для каждого браузера. Конечно, никто еще не отменял console.log — простой, и в некотором смысле кроссбраузерный, инструмент, хорошо помогающий в отладке. Но его применение опять-таки ограничено наличием в браузере средств отладки. Особенно это касается мобильных устройств, в которых получить доступ к средствам отладки не так просто, а иногда и вовсе невозможно.Читать полностью »
Некоторое время назад Министерство Юстиции обновило свой сайт, выложив в сеть новую версию своего интернет-представительства, построенную на Drupal:
Теперь официальный сайт Министерства юстиции Российской федерации работает полностью на базе свободного программного обеспечения.
Цитата с сайта
Взаимодействие с браузерами никогда не было работой для слабонервных: около полудюжины различных API, различные механизмы IPC, и разные возможности у разных поставщиков. Такие проекты, как WebDriver, пытаются абстрагироваться от этой сложности, к тому же в Сети можно найти десятки других «безголовых» драйверов, использующих WebKit или иные движки. В настоящее время в работе даже находится спецификация W3C на WebDriver.
Тем не менее, в то время, как создание общего решения является сложной задачей, оказалось, что инструментирование Chrome очень просто, — как я недавно обнаружил при исследовании некоторых вопросов, связанных с сетевыми задержками. Начиная с 18 версии, Chrome теперь поддерживает протокол удалённой отладки v1.0, который предоставляет все возможности браузера с помощью обычного WebSocket!
/Applications/Path To/Google Chrome --remote-debugging-port=9222 # OSX
$> curl localhost:9222/json
[ {
"devtoolsFrontendUrl": "/devtools/devtools.html?host=localhost:9222&page=1",
"faviconUrl": "",
"thumbnailUrl": "/thumb/chrome://newtab/",
"title": "New Tab",
"url": "chrome://newtab/",
"webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/1"
} ]
В нашей повседневной работе, как и всем, требуется много пользоваться отладчиком. В силу специфики работы: (разработка ОС, использование технологий виртуализации наподобие Intel-VT, ит.д.) нам часто требуется использовать отладчик для работы со специфическими случаями: отладка кода загрузчика ядра, отладка загрузчиков виртуальных машин, а так же в принципе обеспечение возможности отлаживать ОС собственной разработки. Именно эти особые случаи так пафосно названы в заголовке ”по максимуму”.
Для решения всех этих задач (и конечно, многих других) мы используем gdb. Возможно использование и таких оболочек как DDD, но лично я предпочитаю использовать cgdb как оптимальный выбор, особенно для случая работы с отладчиком по ssh.
В этой статье мы расскажем о том, как можно использовать gdb для отладки кода загрузочных секторов и загрузчиков.Читать полностью »
Итак, время для верного ответа на ранее опубликованную задачку. Спасибо всем поучаствовавшим. Первым же комментарием к посту была вывешена вот эта ссылка. Я, признаться, верил, что она появится не сразу и позволит чуть-чуть продлить интригу. Но Хабр есть Хабр и на каждую хитрую гайку тут найдется свой болт с левой резьбой — и это прекрасно, за то его и любим.
Однако не так был прост конкурс, чтобы его можно было выиграть одной лишь ссылкой на MSDN — там объясняются лишь знаки 1, 2, 3, 7 и 8. А вот что означают и чем друг от друга отличаются 4, 5 и 6 — в этом и была сама задача. К сожалению, многие посчитали первый комментарий верным ответом и отказались от дальнейшего участия. А зря. Прошу под кат.
Читать полностью »
На Хабре уже упоминалась данная тулза, но как-то в контексте других тем.
What is Fiddler?
Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect traffic, set breakpoints, and «fiddle» with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.Fiddler is freeware and can debug traffic from virtually any application that supports a proxy, including Internet Explorer, Google Chrome, Apple Safari, Mozilla Firefox, Opera, and thousands more. You can also debug traffic from popular devices like Windows Phone, iPod/iPad, and others.
To debug applications you've written in Java, .NET, or using WinHTTP, see this page.
Итак Fiddler — прокси, который работает с трафиком между вашим компьютером и удаленным сервером, и позволяет просматривать и менять его.