How do you use the debugger - gdb lazarus / 12-Debugger ---------------------------------------------------------------------- Elphi · 2007-09-22 19:44 I've set some debugger options type: gdb path: /usr/bin/gdb I've set compiler option to generate debug info for gdb. I've set a breakpoint in my program. When I run the program I expect that it stops at the breakpoint set, but it doesn't. What am I doing wrong? ---------------------------------------------------------------------- antonio · 2007-09-23 23:52 My "Add BreakPoint" menu item is disabled. Is it enabled on your Lazarus? ---------------------------------------------------------------------- Marc · 2007-09-24 09:40 @elphi: it the code run where you placed the breakpoint @antonio: that dialog needs to be implemented, you can add a breakpoint by clicking in the left gutter. ---------------------------------------------------------------------- antonio · 2007-09-24 13:53 Thanks. ---------------------------------------------------------------------- Elphi · 2007-09-24 14:27 Sorry, I not familiar with gdb; where should hit code run? The run items in the IDE are disabled. The breakpoint list show the breakpoint in state 'invalid'. ---------------------------------------------------------------------- Marc · 2007-09-25 11:05 You see this invalid state while running, or before running ? ---------------------------------------------------------------------- Elphi · 2007-09-25 22:19 Before running state = ? (On) When running state = Invalid. I've learned now that breakpoints set in the program body function as expected, but breakpoints in used units are somehow not recognized. I also see that the first 30-40 steps after the breakpoint the "current-line" is set at strange places: at the method header, at empty lines, at defines that aren't valid etc. Can't say why it behaves as expected at some point. Furthermore I get an access violation when I Reset Debugger. When I run the program without breakpoints I can't figure out how to get the console I am supposed to see. Brings me to the original question: how to use gdb? ---------------------------------------------------------------------- Marc · 2007-09-26 09:23 Pointing to wrong locations usually means that a different source is used for compiling than you use in the ide. (unless you're using some older 2.1.x compiler) When a unit gets an invalid breakpoint, it can mean 2 things: 1) that unit isn't compiled with debug info. This is usually the case for rtl or fcl units. Only lazarus units are shipped with debug info. 2) that version of the unit is not used when compiling. ---------------------------------------------------------------------- Elphi · 2007-09-26 20:53 Quote from: "Marc"Pointing to wrong locations usually means that a different source is used for compiling than you use in the ide. (unless you're using some older 2.1.x compiler) Certainly not in this case. I've done a Clean Directory with default settings, and stepping through the source seems ok. Quote from: "Marc"When a unit gets an invalid breakpoint, it can mean 2 things: 1) that unit isn't compiled with debug info. This is usually the case for rtl or fcl units. Only lazarus units are shipped with debug info. Not the case here; it concerms my own units. Quote from: "Marc"2) that version of the unit is not used when compiling. The be sure I've the correct version of the unit I deliberately made a compile time error at the breakpoint line, and the compiler recognizes this error. ---------------------------------------------------------------------- Marc · 2007-09-27 10:59 what fpc version do you use what os (32 or 64 bit) what debugger options did you set ? ---------------------------------------------------------------------- Elphi · 2007-09-27 20:43 Lazarus 0.9.23 svn rev 12157, fpc 2.2.0 x86_64-linux-gtk on CentOS 5 Debugger type: gdb, path: usr/bin/gdb ---------------------------------------------------------------------- Elphi · 2007-09-27 20:50 Lazarus 0.9.23 svn rev 12157, fpc 2.2.0 x86_64-linux-gtk on CentOS 5 Debugger type: gdb, path: usr/bin/gdb ---------------------------------------------------------------------- Marc · 2007-09-28 09:21 with options I mean: project - compiler options - linking ---------------------------------------------------------------------- Elphi · 2007-09-28 19:59 -g -gl ---------------------------------------------------------------------- Elphi · 2007-09-30 13:28 Related to this bug report? http://www.freepascal.org/mantis/view.php?id=9821[/url] ---------------------------------------------------------------------- Marc · 2007-10-01 09:09 Do you get that exact error message from gdb ? ---------------------------------------------------------------------- Elphi · 2007-10-01 21:47 No, I don't "get" anything from gdb. When I start the program it should stop waiting for user input, but nothing happens. Note my question: how to use the debugger... When I then stop "debugging" with Reset Debugger an AV happens. I then can press Ok risking data corruption or Cancel (to kill the program, i.e. Lazarus). It smells like debugger problems doesn't it? ---------------------------------------------------------------------- Marc · 2007-10-02 09:49 Now you talk about a complete different thing. Whne working with lazarus, I don't expect apps waiting for userinput (on the console or didn't you mean that). Stopping the debugger runs through a fixed number of steps which normally should give a certain response. When gdb is waiting for user input, it cannot give those responses and the gdb wrapper doesn't handle that well -> AV, which you can ignore. ---------------------------------------------------------------------- Elphi · 2007-10-03 11:29 Yes I mean a console applcation which Lazarus calls a Program. I certainly am talking about the same thing: debugging my program. Its a rather complex multithreaded application server. When started the user can give commands at the prompt to (de)activate the server, or shut it down. With Lazarus/win32 the program stops at all breakpoints declared. Also I get a terminal window. With Lazarus/Linux-x86_64-gtk, with the same source files I have debugging problems. One problem, location in source mismatch, is solved by running "Clean directory". In my opinion this shouldn't be necessary. Another problem is that when I set the GNU debugger (in "Debugger Options") and run the program, I don't get the terminal window. When setting debugger to "[none]" a get the terminal window, as expected. It seems now that a problem with breakpoints in units that are skipped is related to the fact that the terminal windows doesn't appear. It looks like the programs hangs somewhere. I've found that even from a simple program I don't get a terminal: Code: [Select] program Project1; {$mode objfpc}{$H+} uses   {$IFDEF UNIX}   cthreads,   {$ENDIF}   Classes   { add your units here }; var   Command: Char;   KeepListening: Boolean;   begin   KeepListening := True;   while KeepListening do   begin     write('>');     readln(Command);     case Command of       'c': writeln('continue');       'q': begin              writeln ('quit');              KeepListening := False;            end;     end;   end; end.   Indeed, now I don't think anymore the problem arises from my lack of knowlegde of the GNU-debugger. I looks like a clear case for a bug report, doesn't it? ---------------------------------------------------------------------- Marc · 2007-10-04 10:10 nope, debugging console apps with lazarus throug gdb is not supported. The reason: to control gdb I need the console input/output of gdb. With gdb it is not possible to create a separate console for your application, so when the app stops, I don't know if it is the user program or it is gdb ---------------------------------------------------------------------- Elphi · 2007-10-04 16:52 In essence you are saying that console programs can't be debugged in any way. If I enable gbd I don't get any console, nor from gdb neither from my program. When I disable gdb I can't set breakpoints. That's bad news. As an alternative I've created my server class in a formcreate event handler.    The breakpoints I've set in the source creating the server are ignored. When the form appears and I press a button to activate the server, execution stops in the event handler where no breakpoint is set. I conclude that the debugger  is aware of a previous breakpoint, but doesn't stop there. I'm sure the file compiled is the file with the breakpoints. ---------------------------------------------------------------------- Elphi · 2007-10-04 22:33 In addition to the previous post I went back to win32. Contrary to what you're saying on this platform with gdb set, I can debug the same console program with breakpoints recognized, and it gives me the console of my program for user input. Please, can you clarify this? ---------------------------------------------------------------------- Marc · 2007-10-05 08:36 A linux console is not equal to a windows console. Besides that, gdb may implement things different on windows than on linux. Quote As an alternative I've created my server class in a formcreate event handler. The breakpoints I've set in the source creating the server are ignored. I keep with one of my first postings, there is something wrong with your debuginfo. Either the wrong source, or the wrong unit, or something else. But you should be able to set a breakpoint. Are you sure you didn't name the unit similar to some rtl/fcl unit ? Do you have spaces in the path to any source file ? ---------------------------------------------------------------------- Elphi · 2007-10-05 21:26 Quote from: "Marc"A linux console is not equal to a windows console. Besides that, gdb may implement things different on windows than on linux. Could be, but Lazarus will hide these platform peculiarities for me? Quote from: "Marc"But you should be able to set a breakpoint. I fully agree! Quote from: "Marc"Are you sure you didn't name the unit similar to some rtl/fcl unit ? Do you have spaces in the path to any source file ? mnt/y/y-invent/trunk/middleware/ymserver.pas Obviously there's no simple answer. Hopefully next week I 'll dive into the matter again trying to pinpoint the problem better. Thanks anyways.