Debug Freez while step-by-spet application lazarus / 12-Debugger ---------------------------------------------------------------------- Shebuka · 2011-04-21 10:37 Hi, I recently updated lazarus from 0.9.28 to 0.9.30 and fpc from 2.4.0 to 2.4.2 on my Mac OS X 10.6 (overwriting old ones, don't know how to make a 'clean' install...). Now I have a problem while debugging my applications... If i go step- by-step it's all ok, but as i stop on some variable/function to read some vars or simple think about code, after like 5-20 seconds (randomly) whole debugger freez and i can't neither go step forward niether let it run... 'Stop debug' neither works, so i need to 'reset debugger'. But this is not all, after 'resetting debugger' the application remain in background as not responding, also lazarus remains not responding when i exit it and only 'force exit' (apple's icon menu 'force application closure') close lazarus and the frozen app in background... How to solve this? ---------------------------------------------------------------------- Martin_fr · 2011-04-21 11:36 This is a known problem on Mac.  Unfortunately not all the reasons for it are known yet. You can try and recompile your Lazarus IDE as described here: http://w iki.lazarus.freepascal.org/GDB_Debugger_Tips#Debug_session_freezes But, as not all reasons are known yet, this may not help. You may need to provide further feedback. 1) Are you using a 32 or 64 bit Mac? 2) Please open the "debug output" window (from "view" / "debug windows"). You must open this window, before you start debugging your app. Then debug your app, until the session freezes, copy,zip and attach the content of the debug output window. 3) If you can, start your lazarus from a shell, with debug-log: /path/to/lazarus/lazarus.app/Content/MacOs/lazarus --debug- log=/path/to/wherever/log.txt And attach the log (or at least the last lines of it). If you recompile your Lazarus, then you may also specify -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG This will not fix the problem, but provide more info in the logfile ---------------------------------------------------------------------- Shebuka · 2011-04-21 16:27 Quote from: Martin_fr on April 21, 2011, 01:36:50 pmThis is a known problem on Mac.  Unfortunately not all the reasons for it are known yet. You can try and recompile your Lazarus IDE as described here: http://w iki.lazarus.freepascal.org/GDB_Debugger_Tips#Debug_session_freezes But, as not all reasons are known yet, this may not help. You may need to provide further feedback. 1) Are you using a 32 or 64 bit Mac?   Versione sistema:   Mac OS X 10.6.7 (10J869)     //System Version   Versione kernel:   Darwin 10.7.0                     //Kernel Version   Estensioni e Kernel a 64 bit:   No                    //Extensions and Kernel at 64bit Quote2) Please open the "debug output" window (from "view" / "debug windows"). You must open this window, before you start debugging your app. Then debug your app, until the session freezes, copy,zip and attach the content of the debug output window. 3) If you can, start your lazarus from a shell, with debug-log: /path/to/lazarus/lazarus.app/Content/MacOs/lazarus --debug- log=/path/to/wherever/log.txt And attach the log (or at least the last lines of it). If you recompile your Lazarus, then you may also specify -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG This will not fix the problem, but provide more info in the logfile I'tried your suggestions wit 2 different 'runs', on the first run i'v started lazarus from shell and opened debug output window and copied all the things as i freez (after stop on breakpoint i'v hovered over .Paint property), there are 3 files (in debug_output.zip) in zip: terminal output, debug output and debug log. After that i'v tried to insert debug defines and rebuild lazarus, all ok until it autorestart where i'v got 'debugger experienced unknown condition' ' Exception: EProcess.with message "Executable not found: "/Volumes/Mac"" ' (my HD name has space), so I cutted out the space and recompiled IDE, all ok, then redone shell launch and experienced again the freez on breakpoint after howering .Paint property. All new more debug is in 'debug_output_2.zip' btw, noticed that in the first debug_log there is also all information about rebuilding lazarus process and at the end the access violation info of the screenshot. ---------------------------------------------------------------------- Martin_fr · 2011-04-21 17:33 The issue with the executable not found (due to space), when you restart lazarus, is not related to the debugger. You should report it on the bugtracker, please. and include the stacktrace from the end of debug_log.txt, in your first zip. Also make sure you do have "startlazarus" as an executable => but it shouldn't crash either way. I can see where your debugger hangs: "stretched.Bitmap" FIRST) while it should of course not hang, please make sure you read the section on properties, on the wiki. It may be that the value can not be inspected even if the hang issue is dealt with. 2nd) QuoteAfter that i'v tried to insert debug defines and rebuild lazarusWhich defines? -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG? The 2nd logfile does not look like these 2 where in effect. Several possibilities: - if you add them to the "options" field in the "configure build lazarus" dialog, then they need the leading "-d". If you use "Edit defines" then you must not include the "-d" - You may have to check "clean all" or at least set the "IDE" radiobutton to "clean and build" (in the listbox where IDE, and Examples are listed) Otherwise the compiler may think that the sources are not changed, and does not actually recompile them. anyway, if I am right, the results of -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG aren't needed anymore. 3rd) If this is either a "watch" expression, or could be part of what you hovered the mouse over, then it should be possible to use the DBG_WITH_TIMEOUT trick. See the above hints on how to recompile. Please note that this is in a way a workaround. Each time the issue is encountered the debugger will pop up a warning dialog. But it should allow you to continue. As described on the wiki, unfortunately the gdb shipped for OSX does not always respond correctly. And the alternative from MacPorts seems to have other problems (Afaik no one has yet found a way to really use it) In order to ensure, that you specified the define correctly, you can try to add: DBG_ENABLE_TERMINAL This is linux only, so it should fail to compile/link on Mac. ---------------------------------------------------------------------- Martin_fr · 2011-04-21 18:33 I changed the IDE, so the timeout can be configured in the options dialog, under debugger-properties. (and will be set by default on mac) You need svn or tomorrows (22 apr) snapshot. 0.9.31, it is NOT in fixes Also I can't test it, since the error does not happen, on my test environment. ---------------------------------------------------------------------- Shebuka · 2011-04-22 08:24 Quote from: Martin_fr on April 21, 2011, 07:33:02 pmThe issue with the executable not found (due to space), when you restart lazarus, is not related to the debugger. You should report it on the bugtracker, please. and include the stacktrace from the end of debug_log.txt, in your first zip. Also make sure you do have "startlazarus" as an executable => but it shouldn't crash either way. Ok, I'll report it. Finder says that "startlazarus" is an Executable Unix Document QuoteI can see where your debugger hangs: "stretched.Bitmap" FIRST) while it should of course not hang, please make sure you read the section on properties, on the wiki. It may be that the value can not be inspected even if the hang issue is dealt with. Before Update it was functioning well, but i try to reproduce it on some more common property like .Text or .Caption and report back. Quote2nd) QuoteAfter that i'v tried to insert debug defines and rebuild lazarusWhich defines? -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG? The 2nd logfile does not look like these 2 where in effect. Several possibilities: - if you add them to the "options" field in the "configure build lazarus" dialog, then they need the leading "-d". If you use "Edit defines" then you must not include the "-d" - You may have to check "clean all" or at least set the "IDE" radiobutton to "clean and build" (in the listbox where IDE, and Examples are listed) Otherwise the compiler may think that the sources are not changed, and does not actually recompile them. anyway, if I am right, the results of -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG aren't needed anymore. I'v putted into "options" field in the "configure build lazarus" dialod with -d. In first log you can find them on line 250, 506, 624, 636, 648 and 1071 (in so much places?), but 'clean build' was specified only for LCL, all others 'only build' Quote3rd) If this is either a "watch" expression, or could be part of what you hovered the mouse over, then it should be possible to use the DBG_WITH_TIMEOUT trick. See the above hints on how to recompile. Please note that this is in a way a workaround. Each time the issue is encountered the debugger will pop up a warning dialog. But it should allow you to continue. As described on the wiki, unfortunately the gdb shipped for OSX does not always respond correctly. And the alternative from MacPorts seems to have other problems (Afaik no one has yet found a way to really use it) In order to ensure, that you specified the define correctly, you can try to add: DBG_ENABLE_TERMINAL This is linux only, so it should fail to compile/link on Mac. Will try this. Then try to reproduce bug on .Caption. And at the end try the snapshot (which i understand now has DBG_WITH_TIMEOUT by default) ---------------------------------------------------------------------- Shebuka · 2011-04-22 08:57 Trying to clean build lazarus with DBG_ENABLE_TERMINAL and it compiles just as before... 2 logs: In first one defines are in 'Options' (with -d ahead) In second one defines are defined via 'Edit Defines' and checked, also checked 'Clean all'. ---------------------------------------------------------------------- Shebuka · 2011-04-22 09:11 Other log files, this one with one step-forward after breakpoint and a freez over .Text Hot to make a real clean install of 9.31 snapshot? I mean it's not enough to simply delete Developer/lazarus folder, what other to clean? ---------------------------------------------------------------------- Martin_fr · 2011-04-22 10:58 With the snapshot you can check, if you got the right version: Open "options" from "tools" menu. Select "debugger" in the tree. On the page is an object-inspector like grid, with options. It should display an entry "TimeOutForEval" with a value of 2000. Older Lazarus Versions die not have that entry. QuoteTrying to clean build lazarus with DBG_ENABLE_TERMINAL and it compiles just as before...Hm, I know some people reported errors because of that. If it compiles check the "Menu" / "View" / "debug windows" for an entry "Console output". If that is not there, then recompile went wrong QuoteBefore Update it was functioning well, but i try to reproduce it on some more common property like .Text or .Caption and report back. GDB has problems with some pascal data type. In 0.9.30 the IDE tries to correct more of those cases. But for that it must make additional requests to the debugger. (Like "ptype value") It seems that the gdb supplied by Apple sometimes has issues with this. ----------- I'll just got on my PC; so I'll look through the remaining logs, to see,. if I can spot anything else. ---------------------------------------------------------------------- Martin_fr · 2011-04-22 11:10 About -dDBG_ENABLE_TERMINAL Sorry, that was my error => that would nly fail with the snapshot => I only added it a few days back, so it isn't in the release. But the rest is still correct. the compilation looks fine, that is the defines seem in the right place. Your very last "debug_log.txt" also looks correct (is has -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG) --- Just to point out: -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG => does NOT fix anything. It is only for adding info to the log file) -dDBG_WITH_TIMEOUT  is the one that should help ---------------------------------------------------------------------- Shebuka · 2011-04-22 12:09 Quote from: Martin_fr on April 22, 2011, 01:10:09 pmAbout -dDBG_ENABLE_TERMINAL Sorry, that was my error => that would nly fail with the snapshot => I only added it a few days back, so it isn't in the release. But the rest is still correct. the compilation looks fine, that is the defines seem in the right place. Your very last "debug_log.txt" also looks correct (is has -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG) That logs help you in some manner to figure out where is the problem? QuoteJust to point out: -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG => does NOT fix anything. It is only for adding info to the log file) -dDBG_WITH_TIMEOUT  is the one that should help I know, i'v read the wiki topic you have linked. I like to help you figure out the 'right' solution, so, if you need other info/logs/tests just ask Now i'll try to install the snapshot and see if timeout unfreez my gdb ---------------------------------------------------------------------- Martin_fr · 2011-04-22 12:34 The new log, confirmed that the issue happened where I suspected. so the timeout should solve it. If it does, I will see that I remove the "warning" dialog, as it will become a bit annoying. One more thing. In the logfile, I saw that your app was compiled using -gl, but neither -g -gs or -gw. I am not sure, if -gl does include any of them. You should check on the "linking" page of the "project options", that "generate debugging info for gdb (slows compiling) (-g)" is checked? (alternatively the "dwarf option", not sure which one will work better) QuoteTCompiler.Compile WorkingDir="/users/fbk/Projects/Tests/ZipTest/" CompilerFilename="/usr/local/bin/ppc386" CompilerParams=" -MObjFPC -Scghi -O1 -gl -WG -vewnhi -l -Fi/users/fbk/Projects/Tests/ZipTest/lib/i386-darwin -Fu/Developer/lazarus/lcl/units/i386-darwin -Fu/Developer/lazarus/lcl/units/i386-darwin/carbon -Fu/Developer/lazarus/components/zlibar/lib -Fu/Developer/lazarus/packager/units/i386-darwin -Fu/users/fbk/Projects/Tests/ZipTest/ -Fu. -FU/users/fbk/Projects/Tests/ZipTest/lib/i386-darwin/ -oPasZipTest -dLCL -dLCLcarbon PasZipTest.lpr" [TCompiler.Compile] CmdLine="/usr/local/bin/ppc386  -MObjFPC -Scghi -O1 -gl -WG -vewnhi -l -Fi/users/fbk/Projects/Tests/ZipTest/lib/i386-darwin -Fu/Developer/lazarus/lcl/units/i386-darwin -Fu/Developer/lazarus/lcl/units/i386-darwin/carbon -Fu/Developer/lazarus/components/zlibar/lib -Fu/Developer/lazarus/packager/units/i386-darwin -Fu/users/fbk/Projects/Tests/ZipTest/ -Fu. -FU/users/fbk/Projects/Tests/ZipTest/lib/i386-darwin/ -oPasZipTest -dLCL -dLCLcarbon PasZipTest.lpr" ---------------------------------------------------------------------- Shebuka · 2011-04-22 14:28 Quote from: Martin_fr on April 22, 2011, 02:34:29 pmThe new log, confirmed that the issue happened where I suspected. so the timeout should solve it. If it does, I will see that I remove the "warning" dialog, as it will become a bit annoying. Current Snapshot doesn't have this: QuoteOpen "options" from "tools" menu. Select "debugger" in the tree. On the page is an object-inspector like grid, with options. It should display an entry "TimeOutForEval" with a value of 2000.It's still freezing on .Text property, btw if I assign .Text to a string variable i can inspect it without problems. Maybe we need to wait for tomorrow to see new updated snapshot? I can't even rebuild current snapshot because of problem in LazToDo's (/Developer/lazarus/examples/todolist/tododlg.pas(93,43) Error: Identifier not found "itmEditInsertText") QuoteOne more thing. In the logfile, I saw that your app was compiled using -gl, but neither -g -gs or -gw. I am not sure, if -gl does include any of them. You should check on the "linking" page of the "project options", that "generate debugging info for gdb (slows compiling) (-g)" is checked? (alternatively the "dwarf option", not sure which one will work better) I know it's strange, but with fpc 2.4.0 and Laz 0.9.28 i always had only -gl option selected and all works just fine. ---------------------------------------------------------------------- Martin_fr · 2011-04-22 15:09 Seems the snapshot wasn't build tonight. Let's hope we get it fixed till tomorrow. What I saw from the log, is that the IDE sends a:   ptype stretched.Bitmap or   ptype Edt_UnZip_dst.Text (depending which logfile) The debugger returns the echo   &"ptype Edt_UnZip_dst.Text\n" as is expected. And then nothing. Normally expected would be a result, followed by a prompt "(gdb)" I have seen this exact behaviour before (not on my box, but reports from others), and whenever it happened, it could be fixed with the timeout. Normally the missing result, would mean gdb is still busy, and so the IDE would wait. But in this case, gdb actually finished, but never outputted the result (gdb may have run into an error internally).  This always meant, that gdb was actually waiting for the next command and would execute it properly. Of course the IDE doesn't know that  gdb is ready, if gdb doesn't prompt for the next command => so the ide waits forever. With the timeout, the IDE will send a test-command to see if gdb is ready. So if you compile with DBG_WITH_TIMEOUT (or the new snapshot, once available), 1 or 2 seconds after the "ptype" was issued (in the "debug output" window; or log, if compiled verbose), there should be a "-data-evaluate-expression" command. And gdb should return a prompt. If the "-data-evaluate-expression"  does not happen, then that is really odd. (Especially with the snapshot, I made the timeout apply to a bigger range of commands) If the "-data-evaluate-expression"  happens, but no prompt "(gdb)" follows, then the problem is more serious, because gdb crashed for good. You can also test this by using gdb by hand /usr/bin/gdb -i mi /path/to/your/app/project1 or /usr/bin/gdb -i mi /path/to/your/app//project1.app/Content/MacOs/project1   replace unit and line with correct values -insert-break unit1.pas:111 -exec-run on breakpoint ptype Edt_UnZip_dst.Text see the echo, but no result, no prompt. issue -data-evaluate-expression 1 ---- btw, if that gets a prompt, what happens with (note the ^) ptype Edt_UnZip_dst^.Text ------------------ BTW: TEdit.Text is implemented as property Text: string read GetText ... so the GetText method must be executed to get the value. That does not work at all currently, and should return an empty value or error msg always (of course not hang....) That shortcoming on properties is the same for all platforms (win, linux, mac...) ---------------------------------------------------------------------- Martin_fr · 2011-04-29 14:32 For further reference, you may whish to follow the development of the issue at http://bugs.freepascal.org/view.php?id=19262 Unfortunately those latest fixes are not yet ported to the fixes branch (Snapshots), but require an svn checkout (trunk). They may (or may not) get ported (to fixes) at some later point, that is yet to be decided.... ---------------------------------------------------------------------- Shebuka · 2011-05-02 08:47 Quote from: Martin_fr on April 29, 2011, 04:32:01 pmFor further reference, you may whish to follow the development of the issue at http://bugs.freepascal.org/view.php?id=19262 Unfortunately those latest fixes are not yet ported to the fixes branch (Snapshots), but require an svn checkout (trunk). They may (or may not) get ported (to fixes) at some later point, that is yet to be decided.... Hi, friday i'v tried the last snapshot and by default it is still without DBG_WITH_TIMEOUT, i'v manage to rebuild IDE commenting the line of LazToDoList with problematic itmEditInsertText (btw, it will be fixed in some time or it's better to send a bug report also for snapshots?). After rebuild there is still no entry in debugger options for setting of timeout. Now i can debug without freezes I understand that there is a problem with .Text because of .GetText implementation, but why I can't view a value of a property that has as read a direct association with the field of a class ( like FSomeField: Integer and then property SomeField: Integer read FSomeField write SetSomeField ) btw how to get the latest fixes from the trunk? ---------------------------------------------------------------------- Martin_fr · 2011-05-02 09:53 Where are you looking for the "timeout" option? On the page where you can set the debugger executable name /usr/bin/gdb is a small property grid. It should be in there. Trunk is only available via SVN http://wiki.lazarus.freepascal.org/Getting_Lazarus The latest fixes in trunk were: - application that do not use TObject at all, or that do not have "Exception" in debug info, would not debug (debugger freezes at startup) - shorter timeouts In the next couple of days (more likely end of the week) I will review those changes and decide, if any of them should be merged to fixes. That can be monitored here: http://wiki.lazarus.freepascal.org/Lazarus_0.9.30_branch What gets merged depends on: - the risk of new bugs (also affecting other platforms) - usually, I wait a few days, sometimes a few weeks to see if any problems arise in trunk - merge dependencies. Sometimes code can not be merged, because other changes make the code incompatible property SomeField ... read FSomeField. Good question that should be possible. It's an issue how fpc encodes this in debug info. I don't remember which fpc version it was added. I assume inspecting FSomeField works? Also if you try something like  AnObject.SomeField  AnObject.FSomeField then you may have to do  (note the ^)  AnObject^.SomeField  AnObject^.FSomeField or  TSomeClass(AnObject).FSomeField The IDE tries to correct this. But due to the timeout issue, the IDE may not know that it has to correct it. If so this unfortunately limits the ability of tooltip inspection... You can enter those terms in the watches window, or use the "evaluation dialog" (via the editors popup menu) ---------------------------------------------------------------------- Shebuka · 2011-05-04 08:08 Quote from: Martin_fr on May 02, 2011, 11:53:44 amWhere are you looking for the "timeout" option? On the page where you can set the debugger executable name /usr/bin/gdb is a small property grid. It should be in there. Yes, i'm looking in 'IDE Options' > 'Debugger' > 'General' and there are 3 entries: ConsoleTry (blank), Debug_Startup_Options (blank) and OverrideRTLCallingConvention (ccDefault) QuoteTrunk is only available via SVN http://wiki.lazarus.freepascal.org/Getting_Lazarus The latest fixes in trunk were: - application that do not use TObject at all, or that do not have "Exception" in debug info, would not debug (debugger freezes at startup) - shorter timeouts In the next couple of days (more likely end of the week) I will review those changes and decide, if any of them should be merged to fixes. That can be monitored here: http://wiki.lazarus.freepascal.org/Lazarus_0.9.30_branch What gets merged depends on: - the risk of new bugs (also affecting other platforms) - usually, I wait a few days, sometimes a few weeks to see if any problems arise in trunk - merge dependencies. Sometimes code can not be merged, because other changes make the code incompatible I will try to get the trunk version and see if timeout can be set in it Quoteproperty SomeField ... read FSomeField. Good question that should be possible. It's an issue how fpc encodes this in debug info. I don't remember which fpc version it was added. I assume inspecting FSomeField works? Also if you try something like  AnObject.SomeField  AnObject.FSomeField then you may have to do  (note the ^)  AnObject^.SomeField  AnObject^.FSomeField or  TSomeClass(AnObject).FSomeField The IDE tries to correct this. But due to the timeout issue, the IDE may not know that it has to correct it. If so this unfortunately limits the ability of tooltip inspection... You can enter those terms in the watches window, or use the "evaluation dialog" (via the editors popup menu) Yes, if i inspect directly FSomeField it works well. But i can't use AnClass^. over my class objects because it generate 'illegal qualificator' error, but i must use AnRecord^. over records to access fields.