Difference between revisions of "GDB Debugger Tips/ru"
Line 367: | Line 367: | ||
Это сообщение появляется, когда отлаженное приложение закрыто. Если это произойдет, никакие точки останова в приложении не будут запущены, и приложение будет работать так, как если бы не было отладчика. | Это сообщение появляется, когда отлаженное приложение закрыто. Если это произойдет, никакие точки останова в приложении не будут запущены, и приложение будет работать так, как если бы не было отладчика. | ||
− | + | Эта ошибка может произойти по разным причинам. Есть как минимум 2 известных: | |
− | * | + | * не зависящий от позиции exe (PIE): GDB не может переместить определенные точки останова, которые Lazarus использует для запуска exe (это происходит до того, как будут установлены какие-либо точки останова пользователя) |
− | * | + | * определенные библиотеки dll/so, которые определяют те же символы, что и основной exe. |
− | + | Причин может быть еще больше. Второе происходит только при повторных запусках отладчика. | |
− | + | IDE пытается обойти это, но это не всегда удается. Вполне вероятно, что в тех случаях, когда в данный момент происходит сбой, это необходимо обойти с помощью пользовательского набора настроек (см. ниже). | |
Even if you can work around, please consider to send a logfile: [[#Log_info_for_debug_session]] | Even if you can work around, please consider to send a logfile: [[#Log_info_for_debug_session]] |
Revision as of 19:35, 15 June 2019
Вступление
Lazarus поставляется с GDB в качестве отладчика по умолчанию. Начиная с Lazarus 2.0, это значение по умолчанию изменилось на LLDB на MacO.
- Эта страница для Lazarus 1.0 и новее. Для более старых версий см. предыдущая версия этой страницы
- Примечание по GDB 7.5: GDB 7.5 не поддерживается выпущенной версией 1.0. Исправления для поддержки были сделаны в 1.1.
См.также
Установка (GDB и LLDB)
Чтобы получить наилучшие результаты, вы должны убедиться, что ваша IDE и Project правильно настроены.
См. раздел установка отладчика, чтобы настроить IDE и ваш проект для использования отладчика.
Другое
Debugging console applications
Основное
Тип отладочной информации (GDB и LLDB)
Примечание: Эти настройки применяются только к проекту или пакету, для которого они установлены. Если вы изменяете настройки в любом из параметров проекта или пакета, следует убедиться, что это сделано для всех пакетов и проекта.
В противном случае ваш проект будет иметь смешанную информацию отладки, что может привести к ухудшению процесса отладки.
Для 64-битных приложений FPC поддерживает только "Dwarf". (Старые FPC также поддерживают "Stabs", но это не рекомендуется)
Stabs (только GDB) |
-g или -gs Вы должны использовать только если ваша версия GDB не поддерживает [режим] dwarf. Есть очень мало других случаев, когда вам это нужно. Вам может понадобиться это [в случае использования] «var param» (param by ref): procedure foo(var a: integer); Однако IDE имеет дело с этим в 99% всех случаев. Отладчик на основе LLDB не поддерживает [режим] Stabs |
Dwarf (GDB и LLDB) |
Dwarf 2 (-gw)Это устанавливает формат в Dwarf2. Это самая основная настройка dwarf. Dwarf 2 с наборами (-gw -godwarfsets)Этот параметр добавляет возможность проверки наборов: "type TFoo=set of (a,b,c);". Это заимствовано из спецификаций Dwarf 3, но поддерживается большинством версий GDB (любой GDB начиная с версии 7 и выше должен это делать). Это рекомендуемая настройка. Dwarf 3 (-gw3)Dwarf 3 может кодировать дополнительную информацию для некоторых типов (таких как строки и массивы). Это также сохраняет регистр идентификаторов в отладочной информации. Однако все еще есть проблемы с произведенной отладочной информацией. Некоторая информация может быть неправильно закодирована, а другая не понята GDB. В некоторых случаях это может привести к падению gdb. Этот параметр можно использовать при использовании отладчика на основе FpDebug (добавить пакет для IDE)
|
Различия |
Этот список никоим образом не полон:
|
Проверка типов данных (Watch/Hint)
Строки |
GDB не знает тип данных строк Паскаля. Информация о типе, которую возвращает GDB, в настоящее время не позволяет IDE различать PChar (индекс равен 0) и строку (индекс равен 1). В результате "mystring[10]" может быть 10-ым символом в строке или 11-м в PChar Поскольку среда IDE не может быть уверена, какая из них применима, она покажет оба варианта. 2 результата будут иметь префикс String/PChar. |
Свойства |
В настоящее время отладчик не поддерживает выполнение каких-либо методов. Поэтому могут быть проверены только те свойства, которые относятся непосредственно к переменной. (Это работает только при использовании dwarf). TFoo = Class
private
FBar: Integer;
function GetValue: Integer;
public
property Bar: Integer read FBar; // Может быть проверено (если используется Dwarf)
property Value: Integer read GetValue; // *Не* может быть проверен
end; |
Вложенные процедуры / функции |
procedure SomeObject.Outer(NumText: string);
var
OuterVarInScope: Integer;
procedure Nested;
var
I: Integer;
begin
WriteLn(OuterVarInScope);
end;
var
OuterVarOutsideScope: Integer;
begin
Nested;
end; Если вы входите в «Nested», то IDE позволяет вам проверять переменные из обоих стековых фреймов. Это вы можете проверить: I, OuterVarInScope, NumText (без необходимости изменять текущий фрейм стека, в окне стека) Однако есть несколько оговорок: Вы также можете проверить: OuterVarOutsideScope. Это против правил определения границ Паскаля. Это имеет значение, только если у вас есть несколько вложенных уровней, и все они содержат переменную с тем же именем, но область видимости Паскаля скрыла бы переменную из среднего фрейма. Тогда вы увидите неправильное значение. Вы не можете оценить операторы по 2 фреймам: «OuterVarnScope-I» не работает. Предупреждение: Вы можете увидеть неправильное значение. Если в любом другом модуле есть глобальная (или иным образом видимая для правил области действия GDB) переменная с тем же именем, что и локальная переменная из внешнего фрейма, будет показана эта глобальная переменная. Там нет никакого предупреждения для этого. Безопасным способом является явный выбор внешнего стекового фрейма, в котором определен локальный var, и проверка значения.
|
Массивы |
array [x..y] of Integer; показывает как символы, а не int. Только GDB 7.2 или выше, кажется, справиться с этим правильно. Кроме того, могут возникнуть проблемы при использовании массивов (неназванных) записей. Динамические массивы будут показывать только ограниченный объем своих данных. Начиная с Lazarus 1.1, предел может быть указан. |
Указание GDB вида сборки
GDB позволяет указать вид сборки (стиль Intel или AT&T), который будет использоваться при отображении кода сборки. Если кто-то хочет перейти на конкретный вариант, это можно изменить в свойстве AssemblerStyle в параметрах отладчика Lazarus для GDB (функция доступна в Lazarus 2.0). Альтернативно (и единственный способ добиться этого внутри Lazarus в более старых версиях до Lazarus 2.0) можно указать эту опцию, передав команду set disassembly-flavor в Debugger_Startup_options. Можно использовать несколько вариантов синтаксиса (в зависимости от версии GDB), некоторые из которых показаны ниже:
-ex "set disassembly-flavor intel"
--eval-command="set disassembly-flavor intel"
-eval-command="set disassembly-flavor intel"
--eval-command "set disassembly-flavor intel"
Обратите внимание, что может потребоваться сбросить отладчик (Run | Reset Debugger) перед загрузкой GDB с новой настройкой.
Windows
Консольный вывод для GUI-приложений
В Windows в среде IDE нет окна «Отладчик - вывод на консоль». Это потому, что консольные приложения открывают свое собственное окно консоли. Приложения с графическим интерфейсом по умолчанию не имеют консоли. Чтобы иметь консоль для приложения с графическим интерфейсом, необходимо изменить настройки компилятора (Project options(Параметры проекта) / Compiler Options(Параметры компилятора) / Config and Target(Настройка и целевая платформа) / Win32 Gui Application(Графическое приложение Win32): -WC / -WG)
Отладка приложений с правами Администратора
В Windows Vista+ в разделе Project Options(Параметры проекта) при установке разрешений в файле манифеста для программы «от имени Администратора» программа будет запускаться с правами администратора. Если ваша IDE запущена не от имени Администратора, отладка будет запускаться нормально, программа будет отображаться в списке задач, но ее графический интерфейс не будет отображаться.
Поэтому имейте в виду, что вы должны сопоставить уровень привилегий между IDE (и gdb) и приложением, которое необходимо отладить.
Win 64 bit
- Требуется Lazarus 1.0+ (с FPC 2.6+)
- Рекомендуется использовать dwarf
Использование 32-битного Lazarus на 64-битной Windows
В качестве альтернативы можно отлаживать приложения как 32-разрядные приложения (используя 32-разрядную версию GDB). После успешной отладки:
- приложение может быть кросс-скомпилировано до 64 бит или
- можно использовать 2-ую установку Lazarus (используя другую конфигурационную опцию --primary-config-path из 32-битной Lazarus)
При установке 32-битного Lazarus убедитесь, что вы изменили конфигурацию, чтобы использовались правильные 32-битные FPC и GDB.
Больше проблем и решений Win 64 bit
См. также http://forum.lazarus.freepascal.org/index.php/topic,13188.0/topicseen.html
Win CE
Отладчик не находит никаких исходных файлов
Меню: "Tools"(Сервис) Страница: "Debugger"/"Generic" (Отладчик/Общее) Поле: "Additional search path" (Дополнительный путь поиска)
Введите в это поле букву вашего каталога проекта.
Linux
Известные проблемы
- При использовании старой версии GDB могут возникнуть проблемы, по крайней мере, на некоторых процессорах (например, SPARC, с GDB 6.4, поставляемой Debian "Etch"). В частности, фоновые потоки могут блокироваться, даже если программа работает нормально автономно.
- Если ваша программа блокируется при запуске, перейдите в Tools(Сервис) / Options(Настройки) / Debugger(Отладчик) / General(Общее) и установите DisableLoadSymbolsForLibraries=True
Mac OS X
Под OS X вы обычно устанавливаете GDB с инструментами разработчика Apple. Версия GDB, доступная на момент написания, - 6.3.50.
Этот раздел - первый подход к сбору информации об известных проблемах и обходных путях. Информация, представленная здесь, во многом зависит от отзывов пользователей OS X.
Начиная с Lazarus 2.0, в среде IDE имеется отладчик на основе LLDB. Отладчик на основе GDB также может использоваться, но требует много работы по сборке и подписи кода GDB.
Известные проблемы (GDB)
Отладка 32-битного приложения на 64-битной архитектуре
IЭто возможно, а иногда и необходимо отладить 32-битный exe-файл в 64-битной системе.
Это возможно только с Lazarus 0.9.29 rev 28640 и выше.
TimeOuts (только 64 бит)
Похоже, что некоторые команды некорректно (или не полностью) обрабатываются GDB 6.3.50. Обычно GDB заканчивает каждую команду запросом "<gdb>" для следующей команды. Но версия, предоставляемая Apple, иногда не может этого сделать. В этом случае IDE придется использовать тайм-аут, чтобы избежать бесконечного ожидания.
Это было замечено с:
- Определенными выражениями Watch (по крайней мере, если наблюдаемая переменная не была доступна в текущей выбранной функции)
- Обработкой исключений
- Вставленными точками останова (окончание последнего модуля / отсутствие кода)
Это не может быть гарантировано:
- что GDB не будет позже возвращать некоторые результаты от такой команды
- что внутреннее состояние GDB все еще действительно
Приглашение, отображаемое для тайм-аутов, может быть отключено в конфигурации отладчика:
- Warn On Timeout
- True/False. Автопродолжение, после тайм-аута не показывается предупреждение.
- TimeOutForEval
- Задайте [интервал] в миллисекундах, как долго не срабатывает обнаружение тайм-аута (само обнаружение может занять некоторое время).
Возможно, вам придется «СБРОСИТЬ» отладчик после внесения этих изменений.
Больше информации смотрите здесь:
Альтернативное решение, похоже, заключается в использовании более новой версии GDB (см. ниже).
Hardware exceptions under Mac OS X
When a hardware exception occurs under Mac OS X, such as an invalid pointer access (SIGSEGV) or an integer division-by-zero on Intel processors, the debugger will catch this exception at the Mach level. Normally, the system translates these Mach exceptions into Unix-style signals where the FPC run time library handles them. The debugger is however unable to propagate Mach exceptions in this way.
The practical upshot is that it is impossible under Mac OS X to continue a program in the debugger once a hardware exception has been triggered. This is not FPC-specific, and cannot be fixed by us.
Использование альтернативных отладчиков (GDB)
Вы можете установить GDB 7.1 (или более позднюю версию), используя MacPorts, fink или homebrew.
Было замечено следующее:
- GDB 7.1, похоже, имеет проблемы с отладочной информацией [режима] stabs из fpc.
- Убедитесь, что вы выбрали "generate dwarf debug information (-gw)"(генерировать отладочную информацию dwarf (-gw)) на прилагаемой вкладке project options(параметры проекта)
- Следите за предупреждениями компоновщика "unknown stabs"
- Если у вас все еще есть проблемы, убедитесь, что никакой код вообще не скомпилирован [в режиме] stabs. Ваш LCL может содержать [код, скомпилированный в режиме] stabs, и это закончится в вашем приложении, даже если вы скомпилируете приложение с -gw. Поэтому вам, возможно, придется перекомпилировать LCL с помощью -gw (или без какой-либо отладочной информации). То же самое для любого другого модуля, пакета, RTL, ...., которые могут иметь [код, скомпилированный в режиме] stabs.
Даже при соблюдении этих правил GDB не всегда работает с приложениями, скомпилированными в fpc.
Эти наблюдения могут быть неполными или неправильными, пожалуйста, обновите их, если у вас есть дополнительная информация.
- Lazarus версии от 1.0 до 1.0.12
В настройках отладчика сконфигурируйте
EncodeCurrentDirPath = gdfeNone
EncodeExeFilename = gdfeNone
И вы должны использовать "run param", чтобы указать фактический исполняемый файл внутри пакета приложения (project.app/Content/MacOS/project или аналогичный)
В Lazarus версии от 1.0.14 до 1.2 и выше эти шаги больше не требуются.
Xcode 5
Начиная с OS X Mavericks 10.9, Xcode 5 больше не устанавливает GDB по умолчанию и не [делает его] глобальным.
- Для 10.9 вы можете установить старый Xcode 4 параллельно. Это не поддерживается Apple, поэтому он может порвать с одной из следующих версий.
- Вы можете скомпилировать и установить GDB. См. GDB on OS X Mavericks and Xcode 5.
См., пожалуйста, issue 25157 on mantis
- http://forum.lazarus.freepascal.org/index.php/topic,22529.0.html - об установке Xcode 4.3
- http://forum.lazarus.freepascal.org/index.php/topic,22328.0.html - установка gdb
Тема "[Lazarus] Help: Проблемы OS X" на
- http://lists.lazarus.freepascal.org/pipermail/lazarus/2013-November/thread.html#84126
- http://lists.lazarus.freepascal.org/pipermail/lazarus/2013-October/thread.html#84095
Замороженный UI с GDB
Чтобы запустить программу из оболочки, вам нужно запустить «open <program1>.app», прямой доступ к ./program1 не даст вам доступа к пользовательскому интерфейсу. Чтобы заставить GDB работать изнутри вашей IDE, вы должны указать этот путь в качестве параметра run. Выберите в меню Run > Run parameter и введите полный путь к хост-приложению. Например, /User/<yourid>/sources/myproject/project1.app/Content/MacOS/project1
Ссылки
- Mac OS X поставляется с множеством полезных инструментов для отладки и профилирования. Просто запустите /Developer/Applications/Instruments.app и попробуйте их.
FreeBSD
GDB, предоставляемый системой, является древним (версия 6.1.1 во FreeBSD 9) и не очень хорошо работает с Lazarus.
Вы можете установить более новый GDB из дерева портов, например,
cd /usr/ports/devel/gdb
make -DBATCH install clean
Новый GDB находится в /usr/local/bin/gdb
Использование переведенного GDB (неанглийские сообщения от GDB)
- Это относится только к Lazarus *до* 1.2 или *до* 1.0.14.
В этом больше нет необходимости.
IDE ожидает ответов на английском языке. Если GDB переведен, это может повлиять на то, насколько хорошо IDE может его использовать.
Во многих случаях это все еще будет работать, но с ограничениями, такими как:
- Нет сообщений или класса для исключений
- Нет живого обновления потоков, пока приложение работает
- Сообщение об ошибке отладчика после остановки приложения (в конце отладки)
- другое ...
Пожалуйста, прочитайте всю ветку: [http://forum.lazarus.freepascal.org/index.php/topic,20756.msg120720]
Попробуйте запустить lazarus с
export LANG=en_US.UTF-8 lazarus
Известные проблемы/ошибки, о которых сообщает IDE
Сообщения | OС | Описание | |
---|---|---|---|
During startup program exited normally |
|||
Все |
В редких случаях в среде IDE появляется сообщение "During startup program exited normally"(Во время запуска программа завершается нормально). Это сообщение появляется, когда отлаженное приложение закрыто. Если это произойдет, никакие точки останова в приложении не будут запущены, и приложение будет работать так, как если бы не было отладчика. Эта ошибка может произойти по разным причинам. Есть как минимум 2 известных:
Причин может быть еще больше. Второе происходит только при повторных запусках отладчика. IDE пытается обойти это, но это не всегда удается. Вполне вероятно, что в тех случаях, когда в данный момент происходит сбой, это необходимо обойти с помощью пользовательского набора настроек (см. ниже). Even if you can work around, please consider to send a logfile: #Log_info_for_debug_session Ways to work around: (all on the options / debugger page)
This can only be used, if you do not debug within libraries (if you have not written your own lib)
It will add a very slight increase to the time it takes to start the debugger, as gdb must be reloaded each time.
Try any of the values available for "InternalStartBreak" (in the property grid of the options) | ||
SIGFPE |
|||
All |
SIGFPE is a floating point unit exception. Source: [forum thread] SIGFPE exceptions are raised on the next FPU instruction; therefore the error line you get from Lazarus may be off/incorrect. Delphi, and thus Freepascal, have a non standard FPEMask. A lot of C libraries don't use exceptions to check FPU problems but inspect the FPU status. Workaround: try changing the mask with SetExceptionMask as early as possible in your program: uses math;
...
SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide,
exOverflow, exUnderflow, exPrecision]) If you think there is something wrong in the FPC code, you can use the $SAFEFPUEXCEPTIONS directive. This will add a FWAIT after every store of a FPU value to memory. Most FPC float and double operations end with storing the result somewhere in memory so the outcome is that the debugger stops on the correct FPC line. FWAIT is a nop for the FPU but will cause an exception to be raised immediately instead of somewhere down your code. It is not done per default because it slows down floating point operations a lot. | ||
Error 193 (Error creating process / Exe not found) |
|||
Windows |
For details see here. This issue has been observed under Win XP and appears to be caused by Windows itself. The issue occurs if the path to your app has a space, and a 2nd path/file exists, with a name identical to the part of the path before the space, e.g.:
| ||
SigSegV - even with new, empty application |
|||
Windows |
The following applies only, if you get a SigSegv, even with a new empty application (empty form, and no modifications made to unit1). A SigSegV sometimes can be caused by an incompatibility between GDB and some other products. It is not known if this is a GDB issue or caused by the other product. There is no indication that any of the products listed is in any way at fault. The information provided may only apply to some versions of the named products:
| ||
SigSegV - and continue debugging |
|||
Windows, Mac |
http://sourceware.org/bugzilla/show_bug.cgi?id=10004 http://forum.lazarus.freepascal.org/index.php/topic,18121.msg101798.html#msg101798 | ||
On Windows Open/Save/File or System Dialog cause gdb to crashSee next entry "gdb.exe has stopped working" Or download the "alternative GDB" 7.7.1 (Win32) from the Lazarus SourceForge site.
"Step over" steps into function (Win 64) |
|||
Windows 64 |
Sometimes pressing F8 does not step over a function, but steps into it. It is possible to continue with F8, and sometimes GDB will step back into the calling function, after 1 or 2 further steps (stepping over the remainder of the function). In Lazarus 2.0 a workaround was added, but needs to be enabled. Go to Tools > Options > Debugger and enable (in the property grid) "FixIncorrectStepOver". | ||
gdb.exe has stopped working |
|||
Windows |
GDB itself has crashed. This will be due to a bug in gdb, and may not be fixable in Lazarus. Still it may be worth submitting info (see section "Reporting Bugs" below). Maybe Lazarus can avoid calling the failing function. There is one already known situation. GDB (6.6 to 7.4 (latest at the time of testing)) may crash while your app is being started, or right after your app stopped. This happen while the libraries (DLL) for your app are loaded (watch the "Debug output" window).
This can only be used, if you do not debug within libraries (if you have not written your own lib) | ||
internal-error: clear_dangling_display_expressions |
|||
Windows, maybe other |
At the end of the debug session, the debugger reports: internal-error: clear_dangling_display_expressions: Assertion `objfile->pspace == solib->pspace' failed. This is an error in gdb, and sometimes solved by
This can only be used, if you do not debug within libraries (if you have not written your own lib) | ||
"PC register is not available" ("SuspendThread failed. (winerr 5)") |
|||
Windows |
GDB may fail with this message. This is due to http://sourceware.org/bugzilla/show_bug.cgi?id=14018 If you get this issue you may want to downgrade to GDB 7.2 | ||
Can not insert breakpoint |
|||
All |
For breakpoints with negative numbers Please see: http://forum.lazarus.freepascal.org/index.php/topic,10317.msg121818.html#msg121818 You may also want to try:
This can only be used, if you do not debug within libraries (if you have not written your own lib) For breakpoints with positive numbers This may happen due to incorrect Debugger Setup. Ensure smart linking is disabled. It usually means that the breakpoint is in a procedure that is not called, and not included in your exe. On Windows, if it happens despite correct setup, then add -Xe (external linker) to the custom options. |
Reporting Bugs
- Did you verify your Debugger Setup?
- Did you try Dwarf and Stabs
Check existing Reports
Please check each of the following links
- Search Mantis for category "debugger"
- Search Mantis for text "debugger"
- Search Mantis for text "gdb"
- Search Mantis for text "dwarf"
- Search Mantis for text "stabs"
Bugs in GDB
Description | OS | GDB Version(s) | Reference |
---|---|---|---|
win64 crash with bad dwarf2 symbols | win64 | GDB 7.4 (maybe higher) | http://sourceware.org/bugzilla/show_bug.cgi?id=14014 |
Debuggee doesn't see environment variables set with set environment | win | Solved in GDB 7.4 | http://sourceware.org/bugzilla/show_bug.cgi?id=10989 |
Win32 fails to continue with "winerr 5" (pc register not available) *apparently* not present in 7.0 to 7.2 |
win | GDB 7.3 and up (maybe 6.x too) Appears to be fixed in 7.7.1 |
http://sourceware.org/bugzilla/show_bug.cgi?id=14018 |
Wrong array index with dwarf | * | GDB 7.3 to 7.5 (maybe 7.6.0) fixed in 7.6.1 |
http://sourceware.org/bugzilla/show_bug.cgi?id=15102 |
GDB crashes, if trying to inspect or watch resourcestrings only tested on win32, not known for other platforms only, if using dwarf |
* | GDB 7.0 to 7.2.xx | |
Records (especially: pointer to record) may be mistaken for classes/objects The data/values appear to be displayed correct / further tests pending This also affect the ability to inspect shortstring |
* | GDB 7.6.1 and up (tested and failing up to GDB 8.1) | https://sourceware.org/bugzilla/show_bug.cgi?id=16016 |
Object variables (Members) of the current methods class (self.xxx) can not be watched/inspected To work around use upper case or prefix with self. |
* | GDB 7.7 up to 7.9.0 (incl) Workaround present in Lazarus 1.4 and up |
https://sourceware.org/bugzilla/show_bug.cgi?id=17835 |
gdb cannot continue after SIGFPE or SIGSEGV happen on windows | win | * | https://sourceware.org/bugzilla/show_bug.cgi?id=10004 |
GDB truncates values for "const x = qword(...)" | Win 64 bit maybe others |
Fixed in GDB 7.7 and up, maybe fibed between 7.3 and 7.7 |
Issues with GDB 7.5.9 or 7.6
There are various reports (not confirmed) for different platforms about crashes in gdb 7.5.9 or 7.6.
It is highly recommended not to use those versions.
- http://bugs.freepascal.org/view.php?id=24401
- http://forum.lazarus.freepascal.org/index.php/topic,20756.msg120842.html#msg120842
- http://sourceware.org/bugzilla/show_bug.cgi?id=15453
Create a new Report (GDB and LLDB)
If you have at any time in the past updated, changed, reinstalled your Lazarus then please check the "Options" dialog ("Environment" or "Tools" Menu) for the version of GDB and FPC used. They may still point to old settings.
Basic Information
- Your Operating system and Version
- Your CPU (Intel, Power, ...) 32 or 64 bit
- Version of
- Lazarus (Latest Release or SVN revision) (Include setting used to recompile LCL, packages or IDE (if a custom compile Lazarus is used))
- FPC, if different from default. Please check the "Options" dialog ("Environment" or "Tools" Menu)
- GDB, please check the "Options" dialog ("Environment" or "Tools" Menu)
- Compiler Settings: (Menu: "Project", "Project Options", indicate all settings you used )
- Page "Code generation"
- Optimization settings (-O???): Level (-O1 / ...) Other (-OR -Ou -Os) (Please always test with all optimizations disabled, and -O1)
- Page "Linking"
- Debug Info: (-g -gl -gw) (Please ensure that at least either -g or -gw is used)
- Smart Link (-XX); This must be OFF
- Strip Symbols (-Xs); This must be OFF
Log info for debug session
- Start Lazarus with the following options:
--debug-log=LOG_FILE --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO,DBG_ERRORS
- On Windows
- you need to create a shortcut to the Lazarus exe (like the one on Desktop) and edit it's properties. Add " --debug-log=C:\laz.log --debug-enable=..." to the command line.
- On Linux
- start Lazarus from a shell and append " --debug-log=/home/yourname/laz.log --debug-enable=..." to the command line
- On Mac/OSX
- start Lazarus from a shell /path/to/lazarus/lazarus.app/Contents/MacOS/lazarus --debug-log=/path/to/yourfiles/laz.log --debug-enable=...
Attach the log file after reproducing the error.
If you can not generate a log file, you may try to open the "Debug output" window (from menu "View" -> "Ide Internals").You must open this before you run your app (F9). And then run your app. Once the error occurs, copy, zip, and attach the content of the "debug output" window.
Running the test-case
If you run a different version of GDB you may want to run the test case. Please note, that not all tests have yet the correct expectations for each possible setup. Therefore some tests may fail on some systems.
The debugger test are in the directory:
- Lazarus 1.2.x: debugger\test\Gdbmi\
- Lazarus 1.3 and up: components\lazdebuggergdbmi\test\
In the below the 1.3 path is used. If using 1.2.x substitute as appropriate.
- One time setup
Create directory components\lazdebuggergdbmi\test\Logs: Optional, but helps keeping test result in one place
Create config files: in components\lazdebuggergdbmi\test\
- copy fpclist.txt.sample to fpclist.txt
- copy gdblist.txt.sample to gdblist.txt
open the 2 txt files and edit the path to fpc/gdb, also edit the version (the test may run different test, for different versions). It is possible to specify more than one gdb/fpc
- Running the test
- Open project: components\lazdebuggergdbmi\test\TestGdbmi.lpi
- Lazarus 1.2.x only: Rebuild the IDE wit option "Clean" (Menu Tools: "Configure build IDE" / Restart is not needed). If this is skipped, compilation of the project may fail. Once compilation failed, ALL *.ppu/*.o files in debugger\test must be deleted by hand.
- Run the project (If a test failed, you may have to delete *.exe files in components\lazdebuggergdbmi\test\TestApps
Links
External Links
Experimental Debuggers in pascal
Those are work in progress:
- http://sourceforge.net/projects/duby/
- https://github.com/graemeg/fpdebug
- https://code.google.com/p/vdbg/
- fpdebug in Lazarus/components/fpdebug and debugger/components/fpgdbmidebugger blog FpGdbmiDebugger