Техника отладки программ средствами MIDletPascal.
Java отладка - несколько иная процедура, чем отладка компьютерных программ, т.к. среда не предоставляет средств для трассировки по одной команде, но производители эмуляторов восполняют этот пробел всевозможными мониторами. Например эмулятор из комплекта WTK позволяет отслеживать вызовы сборщика мусора, загрузки классов, исключения, вызовы методов, профилировщик, память, сетевой монитор, и д.р. (после создания проекта зайти в главное меню - Edit - Preferences - вкладка Monitor); Эмулятор KEmulator Lite отображает номер процесса и отслеживает вызовы методов, операции создания объектов, память и д.р. (главное меню - view - options - вкладка system). Информация из эмулятора поступает в стандартный вывод консоли. Консоль также доступна для произвольных сообщений из приложений j2me, для этого присутствует метод System.out.println().
В MIDletPascal имеется две системных функции отладки, работающие через System.out.println():
procedure Assert(cond: boolean) - если cond=false то появляется сообщение "Assertion failed at: Tetris.mpsrc:162", где "Tetris.mpsrc" - имя файла, "162" - номер строки, где стоит вызов Assert.
procedure Debug(s: string) - выводит строку s в консоль
Так консольный вывод, помимо сообщений java-машины, удобно применить для диагностических сообщений при работе с эмулятором, на реальном устройстве консольный вывод обычно игнорируют, однако некоторые телефоны имеют опции для перенаправления консольного вывода на какие-либо устройства.
Например меню в "Motorola V3i - Settings - Java Settings - Switching to Debug:" состоит из "Off", "USB", "Modem", "Bluetooth", "File". При выборе пункта "File" создается файл "/a/mobile/kjava/j2me.log" в него дописываются логи консоли, который нужно очищать если размер превысит 1MB иначе java начнет тормозить.
Пример получения лога консоли в Motorola V3i:
Тестовая программка
program dbgtest;
begin
assert(false);
debug('demo debug from MIDletPascal');
drawText('Hello world!', 0, 0);
repaint;
delay(2000);
end.
Сокращенный лог
############### 06/30/2010 11:59:17 ###############
ams_start_filelog - ok
AMS_JsaDialogCreate: 2048
.............
heapAddr:0x14569e60
heapSize:806940
EventHandler:1027814d
.............
FW@d590dbc 100
----- APP JK_VMEVENT_APPSTARTED callback begin.
AMS: VM_APPLICATION_STATE_CHANGED, 20
----- APP JK_VMEVENT_APPSTARTED callback end.
Assertion failed at: dbgtest.mpsrc:3
demo debug from MIDletPascal
----- APP JK_VMEVENT_APPDESTROYED callback begin.
AMS: VM_APPLICATION_STATE_CHANGED, 23
----- APP JK_VMEVENT_APPDESTROYED callback end.
kvm_main return code = 0
.............
==>>KDWP_SetKdwpOption(): DL_FsDeleteFile error (0x0)
ams_stop_filelog
############### 06/30/2010 12:01:31 ###############
Рассмотрим наиболее распространенный случай отладки программ MIDletPascal, в котором необходимо выявить причину зависания мидлета.
Техника применения:
1. В начале каждой подпрограммы установить вызов assert(false);
2. Запускаем программу в эмуляторе и после зависания открываем лог-файл консоли.
3. Ищем последнюю строку вида "Assertion failed at: dbgtest.mpsrc:3", где узнаем номер строки, а следовательно и название подпрограммы.
4. Ищем везде в исходниках проекта где встречается вызов этой подпрограммы, и добавляем до нее и после нее вызовы assert(false);
5. Запускаем еще раз, опять находим последнюю строку вида "Assertion failed at: dbgtest.mpsrc:3" так становится известен диапазон в исходнике.
6. Теперь добавляем вызовы assert(false) между командами для наиболее точного местоположения ошибки.
7. Для удобства можно добавлять информационные сообщения через debug('...');
arT(c)
[email protected]