Debugger Problem in RC1 lazarus / 12-Debugger ---------------------------------------------------------------------- JimKueneman · 2012-08-07 13:06 First a thank you.  RC1 is much more stable on Lion than the previous release while in the debugger on OSX but there is still one show stopper.  Running in OSX Lion.  Run an application that say has a checkbox in it.  Break somewhere and try to get the value of a property of that class, for instance: Code: [Select]if CheckGroupMisc.Checked[0] then     begin Hover the mouse over "Checked"... (or putting it in the watch window) The debugger throws this then none of the watch variables will work anymore: QuoteWarning:  A timeout occured, the debugger will try to continue, but further error may occur later. You have to restart the IDE to get the watches to work again. Thanks, Jim ---------------------------------------------------------------------- Martin_fr · 2012-08-07 14:20 I guess you have a 64 bit CPU? The time-outs itself ar unfortunately unavoidable. They are due tu (a bug(s) in the gdb that comes with the Mac OS (gdb 6.3.5). There is a gdb in Mac-ports, but so far I did not get it to work. The warning for the timeouts can be disabled, so you don't have to acknowledge them. However having a total failure afterwards is not expected. Please check the following. 1) after the error (while the timeout dialog is open), check the process list, and see if a gdb is still running. 2) start lazarus with Code: [Select] --debug-log=/home/yourname/laz.log --debug-enable=DBG_C MD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO, DBG_WARNINGS,DBGMI_STRUCT_PARSER and supply the log, after the error has happened to specify a commandline, change into the lazarus folder and run the exe in the app folder (something like...) ./lazarus.app/xxxx/MacOS/xxx/lazarus --debug-..... (not sure about the exact path) see also http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips ---------------------------------------------------------------------- Martin_fr · 2012-08-08 14:06 Any feedback? ---------------------------------------------------------------------- JimKueneman · 2012-08-10 02:56 Sorry been busy week at work.  I tried to run it but I could not get the command line to work with the options....  Have not had time to try to solve it.... Any yes it is a 64bit iMac Jim ---------------------------------------------------------------------- Martin_fr · 2012-08-10 09:43 As for the command line Code: [Select]  cd  /path/to/lazarus ./lazarus.app/Content/MacOS/lazarus   --debug- log=/home/yourname/laz.log --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_D ATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO,DBG_WARNINGS,DBGMI_STRU CT_PARSER Alternative, start lazarus normal, install the package "IdeLazLogger" Then (after restart) in the Tools menu you find an entry logging. It allows you to specify a logfile, and all the options. The setting is NOT saved, but only for the current run of the IDE. So start the IDE make the settings, run the debugger ---------------------------------------------------------------------- JimKueneman · 2012-08-10 17:02 Attached.... ---------------------------------------------------------------------- Phil · 2012-08-10 17:40 Just FYI: The default debugger for OS X is now lldb: http://lldb.llvm.org/lldb-gdb.html Note gdb is still included with Xcode. Thanks. -Phil ---------------------------------------------------------------------- Martin_fr · 2012-08-10 22:43 Unfortunately the example you debugged does not show what you described above. Or maybe there are a few misunderstandings. So let me go through the points, and tell you: - What I did understand - What can be expected, and what are known limits - What your example shows or maybe misses Then you can tell me, if I misunderstood any of your statements. Quote from: JimKueneman on August 07, 2012, 03:06:43 pmRunning in OSX Lion.  Run an application that say has a checkbox in it.  Break somewhere and try to get the value of a property of that class, for instance: Code: [Select]if CheckGroupMisc.Checked[0] then     begin Hover the mouse over "Checked"... (or putting it in the watch window) The debugger throws this then none of the watch variables will work anymore: QuoteWarning:  A timeout occured, the debugger will try to continue, but further error may occur later. "then none of the watch variables will work anymore" * What I understand: I would have thought that you have other watches, that did work before, and that stop work then. For example, you may hafe inspected a local variable, or self, or anything. And the watches window has shown the value, but after the timeout it does no longer (and also does not, if you step or run to next breakpoint. * What the example shows In your example you never inspected anything that worked. they all failed. That is different. * What can be inspected. All the examples are Properties ( http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Properties ). Unfortunately the support for properties is very limited (those limitations apply to all platforms, but due to the old Mac GDB it may be bigger on MAC) I know that seeing the value of a property is important, and that it is annoying if it does not work. But it simply can not be solved with current GDB. So if you can try to watch: - local variables - self - OpenDialog.FDefaultExt  (note the F, accessing the Field behind the property) And see if those work. (And keep working, even after you got a time out / e.g they will be refreshed after a step (F8)) Returning to properties: On the link I gave above, it says that those properties that point to field (and OpenDialog.DefaultExt  points to FDefaultExt ) will work, if "dwarf" (can be found on project options / linking) is used. You can try this. But I am not sure, it may require an more up to date gdb, which on MAC is not available * Conclusion: If none properties (e.c local/global vars or fields from objects) work, and keep working after a timeout, then that is all there is. I do check the MacPorts gdb once in a while (more once in a year), and if ever that will work then there is going to be a big step forward (still not everything) QuoteYou have to restart the IDE to get the watches to work again. In your example you where missing the working watches. I would need to see a log, where - a watch is successfully displayed - you get the timeout - you run again, but the watch that was displayed before does fail now Mind having that a log is no guarantee it can be fixed. It depends on if the gdb is all at fault, or if the IDE is not recovering correctly. ------------------------- BTW, instead of restarting the IDE, have you tried to do "Reset debugger" from the "Run" menu? There is an option (Environment/Options/debugger to automatically reset it after each run. ---------------------------------------------------------------------- JimKueneman · 2012-08-11 21:49 Okay I am starting to get my head around Lazarus (as most coming from Delphi).  I see what you are saying and yes that is what I am seeing.  Not being able to see properties in objects that have getters is a serious handycap for sure.  I will just have to live without it... Thanks, Jim ---------------------------------------------------------------------- Martin_fr · 2012-08-12 00:20 Well anyway a few tips, you may try to get around that problem. - Try "dwarf" (I do not know, if it will work for 64 bit Mac. It seems to work on 32 bit Mac) It saves you from adding the leading F "FActive" instead of "Active" and therefore allows evaluation in hints. - Use the "debug inspector" It shows all fields, so you can often find the data, from which the value would be calculated. (If you use stabs, try -gp (in "Other" > "Custom options") to keep the case intact) - If you need to see values from a nested object, use the "Evaluate/Modify" window. It allows to edit the expression much quicker. So you can first get it right, and then add a watch. For Example - TList.Count translates to TList.FList.Count - TList can be done as ^TObject(TList.FList.Flist)    (assuming the list contains TObjects) You can always use Code-navigation to see what the getter would return. After a while, you will just know the ones you need. ---------------------------------------------------------------------- JimKueneman · 2012-08-16 12:59 Those are good tips and do work most of the time.  One thing is that dialog is most annoying.  There are times when it pops up so many times I can't even do what I need to do.  I am now running Lazarus through a Parallels XP virtual machine when I need to debug.  How can I turn off that dialog? Thanks, Jim ---------------------------------------------------------------------- Martin_fr · 2012-08-16 13:23 In the Options dialog (environment menu), on the debugger page, is a table with various options. You can disable "WarnOnTimeOut" You can also lower the value of "TimeoutForEval". But you must keep it greater than 0 (that is minimum is 50). A negative value will hang the debugger (in your case) 50 is as save as 200. Only if you have an *extremely* slow computer, then 50 may be slower. Because it will lead to additional checks on working commands. (They will still work 100%)