Cannot get the debugger to work as I expect it to... lazarus / 12-Debugger ---------------------------------------------------------------------- Bart · 2006-02-04 18:08 Hi there, I cannot seem to get the integrated debugger to work. Setting breakpoints just works fine. Running to cursor works fine. Stepping Into and stepping over (F7, F8) does not seem to work at all. Nothing happens when I try to step over/into code. The only thing that I can do to continue is to stop the program (F2). Obviously I'm missing something here. I've seen other people talking about tracing the code in the IDE, so I assume there is some way to make it work. Anyone able to give me some help here? Bart ---------------------------------------------------------------------- felipemdc · 2006-02-04 21:29 Some more information is necessary to see what the problem is. What operating system are you using? Which Lazarus and Free Pascal versions? On the menu "Environment" >>> "Debugger Options", on the IDE, What is written for the path? ---------------------------------------------------------------------- Bart · 2006-02-05 12:09 OS: WinME Lazarus: 0.9.10 beta Lazarus date: 2005-10-02 fpc: 2.0.1 (distributed with the win32 Lazarus installer) Debugger options: GNU debugger (gdb) Path: H:\Programmas\Lazarus\mingw\bin\gdb.exe (and yes, it is actually there) Bart ---------------------------------------------------------------------- Marc · 2006-02-06 09:28 when running to the cursor works, it should be possible to stepinto and stepover. However stepinto only works if the debugsymbols of the code stepped into is present. The fcl/rtl of the fpc provided by the FPC team have no debugsymbols (I don't  know about the version shipped with lazarus) I assume you not only have tried F7 F8 but also by the menu ? And does F9 work when you hit a breakpoint ? ---------------------------------------------------------------------- Bart · 2006-02-06 18:04 Quote from: "Marc" I assume you not only have tried F7 F8 but also by the menu ? And does F9 work when you hit a breakpoint ? Yeah, trying it from the menu's doesn't work either. Hitting F9 after a breakpoint (or a run to cursor) does exactly nothing at all. Bart ---------------------------------------------------------------------- Marc · 2006-02-07 14:14 And F4 does work..... strange. What are the last lines in the View -> Debugger output form ? ---------------------------------------------------------------------- Bart · 2006-02-11 15:45 Well, The integrated debugger is behaving irratically. Today it will not stop when I try a "run to cursor", but today it will stop at a set breakpoint and even let me step through the code... When I try run to cursor on a simple project (1 form, 1 memo, 1 button. In the onclick of the button i loop (1 to 3) to add lines to the memo) it runs straight through (not to) the code... Here's the gdb output: ~"This GDB was configured as \"i686-pc-mingw32\".\n" ^done [snip environment variables...] <-file-exec-and-symbols "F:/Lazarus Projecten/debugtest.exe"> ^done (gdb) <-environment-cd "F:/Lazarus Projecten/"> ^done (gdb) <-data-evaluate-expression FPC_THREADVAR_RELOCATE_PROC> ^done,value="0x0" (gdb) <-gdb-set language pascal> ^done (gdb) <-break-insert -t main> ^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr=" $00401041",func="main",file="debugtest.lpr",line="11",times="0"} (gdb) <-break-insert FPC_RAISEEXCEPTION> ^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr= "$0040a34a",func="fpc_raiseexception",file="except.inc",line="180",tim es="0"} (gdb) <-break-insert FPC_BREAK_ERROR> ^done,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr= "$0040c7f2",func="HANDLEERRORADDRFRAME",file="system.inc",line="675",t imes="0"} (gdb) <-break-insert FPC_RUNERROR> ^done,bkpt={number="4",type="breakpoint",disp="keep",enabled="y",addr= "$0040c8d6",func="RUNERROR",file="system.inc",line="711",times="0"} (gdb) &"info file\n" ~"Symbols from \"F:/Lazarus Projecten/debugtest.exe\".\n" ~"Local exec file:\n" ~"\t`F:/Lazarus Projecten/debugtest.exe', file type pei-i386.\n" ~"\tEntry point: $40100c\n" ~"\t$00401000 - $00519420 is .text\n" ~"\t$0051a000 - $00592560 is .data\n" ~"\t$00593000 - $005a757e is .bss\n" ~"\t$005a8000 - $005aaf74 is .idata\n" ^done (gdb) <-exec-run> ^running (gdb) *stopped,thread-id="1",frame={addr="$00401041",func="main",args=[],fil e="debugtest.lpr",line="11"} (gdb) &"info program\n" ~"\tUsing the running image of child thread -984531.0xfff0f791.\n" ~"Program stopped at $401041.\n" ~"It stopped at a breakpoint that has since been deleted.\n" ~"Type \"info stack\" or \"info registers\" for more information.\n" ^done (gdb) <-exec-until udebugtest.pas:35> ^running (gdb) *stopped,reason="exited-normally" (gdb) <-break-delete 2> ^done (gdb) <-break-delete 3> ^done (gdb) <-break-delete 4> ^done (gdb) <-file-exec-and-symbols > ^done (gdb) Can you shed some light over it? Bart ---------------------------------------------------------------------- Marc · 2006-02-21 08:48 Just a wild guess.... try to save your project on a path without spaces. ---------------------------------------------------------------------- Bart · 2006-02-22 15:56 Quote from: "Marc"Just a wild guess.... try to save your project on a path without spaces. Did that. Run to cursor -> Runs through cursor (does not stop) Set a breakpoint, hit run. Stops at breakpoint. Pressing F8/F7 --> nothing happens. Via menu (Start -> Step over) -> first lets me search for generic.inc file, after I found it, now it will stop over the code (but onlu via the menu, so functionkeys do not work). IMHO: If Lazarus is ever going to be a non-beta multi platform application (as I would dearly hope), then it must handle filenames arcoss OS's as the user expects. That is any allowed filename in the given OS must be handled correctly by Lazarus, FPC and it's tools (so under Window spaces in filenames must be handled). Bart ---------------------------------------------------------------------- tech-pro · 2006-02-22 16:16 Why? Spaces in paths are an abomination peculiar to Windows. They have caused nothing but trouble ever since Microsoft introduced the idea, because of the fact that spaces are also used as delimiters for command arguments. The idea should never have seen the light of day. The only thing that matters is that the programs created by FPC/Lazarus handle spaces in paths correctly (if coded to do so ) If users of the development tool have to avoid such paths, I don't see it as a problem, as long as it says so in the docs. ---------------------------------------------------------------------- Marc · 2006-02-23 09:47 Quote from: "Bart" IMHO: If Lazarus is ever going to be a non-beta multi platform application (as I would dearly hope), then it must handle filenames arcoss OS's as the user expects. That is any allowed filename in the given OS must be handled correctly by Lazarus, FPC and it's tools (so under Window spaces in filenames must be handled). It is not a limitation of Lazarus itself neither FPC. However both rely on external (mainly unix targeted) tools. Forinstance, make has known problems with spaces. The linker ld, had/has them also. I wouldn't be surprised if gdb will show something path related space delimited. If having a non spaced path worked for you, then it would have helped me in locating the point where I maybe parse the output of gdb wrong. Otherwise I can't see why it is not working for you, since for me it does.