Locked with Stop and Run active lazarus / 12-Debugger ---------------------------------------------------------------------- Ruptor · 2013-01-29 13:00 I seem to have put the debugger in to a situation where it was running and had the run triangle green at the same time as the stop square was red. The result was my program was running but didn't show the form or appear in the task bar and I couldn't stop it. Everything I tried like closing Lazarus or stopping the debugger came back with the tab "the debugger is running shall I stop it" but it never managed to stop it. The only way out was to hit F9 to force another compile then it managed to stop the running code but then Lazarus disappeared without a trace. Here is a screen shot of the icons. Was it me causing a known problem? ---------------------------------------------------------------------- Blaazen · 2013-01-29 13:16 ~ 4 years ago, when I used Windows Vista, I had similar problems. IIRC I had to click: Run -> Reset Debugger very often. EDIT: Do you have actual version of Lazarus ? ---------------------------------------------------------------------- Martin_fr · 2013-01-29 13:26 Please create a log as described here: http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debu g_session IF that is NOT possible submit at least the content of the "debug output" window (menu: view/debug windows). Note you MUST open this window BEFORE you press F9 or run the debugger. Also please, specify: *  the exact version of your OS (windows I assume?). CPU 32 or 64 bit? * And the compiler settings: Use the "test" button in "project options" and copy the output. * Does your project include any packages? (3rd party, or TAChart, LazReport, DB)? Complete list can be found at the bottom of "project inspector". * You  may want to check packages:, Open each package, go to the option dialog of the package, and on the page "Linking" check the dropdown for "Choose debug type info". If it differs from the settings in your project, try changing it. (ignore it if "generate debug info" is off) ---- And ensure your setup is correct: http://wiki.lazarus.freepascal.org/Debugger_Setup * NO smartlinking * NO optimization, except level 1 ---------------------------------------------------------------------- Ruptor · 2013-01-29 21:24 My OS is windows XP SP2 32 bit. I am using the snapshot labelled on the dwonload page as 39991 but Lazarus help says it is 39989 so don't ask me.  The debug settings are as installed and match the wiki with no optimisation above level 1. I am using LCL and checked them. Will check the other things later. Doesn't the heading "running" instead of "debugging" give a pointer to the problem? Lazarus doesn't seem to think the code is running in debug mode even though it initiated the run. Also the fact that the only way I could get the code to stop was via the route of starting a compile.  Hope this helps. ---------------------------------------------------------------------- Martin_fr · 2013-01-29 21:48 I will need to see either the log, or alternatively the output of the "debug output" window, please. You can start, with the debug output window, and if it is not enough I will still ask for the log. There also is a package called "IdeLazLogger", if installed the "Tools" menu will have an entry "Logging". Then you can specify the logfile in the running IDE (and set check-boxes for all the GBMI/DBG/GDB..... that the wiki says to put on the command-line) --- "Running" is normal. It indeed is shown always for a tiny moment, when the debugger starts. Though if things go fine, it is to short to be seen (maybe will not even trigger a paint event to truly show it) ---------------------------------------------------------------------- Ruptor · 2013-01-29 23:12 You have to remember I am a Lazarus & GUI coding dunce and I just realised that since the log wasn't on when the fault happened I can't give a log that shows the problem. I know that the problem happened immediately the debugger was started and before my form was displayed. If you watch the debug buttons you will see that both the run and stop are on during this period before the form appears then the run goes grey and the pause turns blue to match the running state with the stop on red. My code was stuck before the pase went blue where the run was green and the stop was red if that helps. ---------------------------------------------------------------------- Ruptor · 2013-01-29 23:31 Oh dear! I was trying to recreate the fault with the log switched on when all my source code disappeared from the file. It is my belief that the stuck code occurred by accidentally hitting the F9 key twice when starting my code so I was messing around with F9 when all my source disappeared luckily I have a back up. Here is the log. ---------------------------------------------------------------------- Martin_fr · 2013-01-30 00:56 Sorry for your trouble. I found some pointers in the log. However it seems to be only partial complete. Did you specify all of the tags? Code: [Select]--debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS, DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO 1) 1st (un)expected line Code: [Select]TGDBMIDebugger.ProcessResult Error: ,msg="mi_cmd_symbol_list_lines: Usage: SOURCE_FILENAME" This is probably NOT the cause of your problem, and probably something the debugger/IDE recovered from. Does your unit name or the path to your unit contain any special chars? umlauts, accents, none latin? 2) This is where it fails Code: [Select]TGDBMIDebugger.ProcessResult Error: ,msg="No registers." I wonder why the IDE does not bring up the "oops the debugger failed" dialog. Anyway, this is actually a bug in GDB. And it seems often (not necessarily always) to happen when threads are in play. I see lots of threads being created. Is that your app? It could also be a dll (some driver installed on your system)... What makes me wonder: Afaik it is only gdb 7.3 and up that have this error ( http://sourceware.org/bugzilla/show_bug.cgi?id=14018 ) The IDE is shipped with gdb 7.2 (for exactly this reasons / actually there are more errors that where introduced in 7.3) Can you check the version of your GDB please. Older IDE came with 7.3 or 7.4, and if you updated, maybe it was not replaced (it should have, but ...) Or did you install a newer gdb yourself? Anyway, if your gdb is not 7.2, then please replace it with 7.2 ---------- BTW, if the debugger hangs, have you tried "Reset debugger" from menu "run"? ---------------------------------------------------------------------- Ruptor · 2013-01-30 01:49 My unit path is My Documents\FPCProject\ForexTrd I am using snapshot 39989 for blue line fix and don't know where to find gdb version let alone install something different. My code is simple so can't see where lots of threads would come from. It uses a button to get a directory then click a file that gets read to a stringlist then freed. I shall try reset if it locks again. ---------------------------------------------------------------------- Martin_fr · 2013-01-30 02:04 Look in the "Options" (Menu "Tools"), it has a section debugger. There you mill find the path to gdb. Usually it is in the lazarus dir, in [C:\lazarus\] mingw\gdb\bin (or similar) From the windows start menu, choose run, and execute cmd.exe then in the command window: Code: [Select]cd \lazarus\mingw\gdb\bin gdb.exe it should print the version --- Current 7.2 can be found here: http://svn.freepascal.org/svn/lazarus/binaries/i386-win32/gdb/bin/ (you also need to replace the library) But before replacing, please verify the version. ----- Also, if you can (even if 7.2 fixes it for you). Can you check again how you created the log, and see, if you can generate a log with all the --debug-enable? This would help me to fix the hanging IDE. Just for info: there are 2 problems here: 1) GDB has a bug, and nothing the IDE does can prevent this. So even if the IDE is fixed, the program in gdb will not work 2) Problem in the IDE. IT should report the GDB problem, and not hang. ---------------------------------------------------------------------- Ruptor · 2013-01-30 12:12 gdb reports as version 7.2 My target in the short cut is C:\lazarus\lazarus.exe --debug-log=C:\laz.log --debug_enable=DBG_CMD_E CHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO Am I missing anything in the line? I cut & pasted it from the wiki and put it in my target for a Debug verion of a short cut. ---------------------------------------------------------------------- Martin_fr · 2013-01-30 13:13 Quote from: Ruptor on January 30, 2013, 01:12:41 pm--debug_enable=DBG_ CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO You are right, the wiki was wrong: It should be Code: [Select]--debug- enable=  with a dash, not an underscore (I updated the wiki now) Sorry about that. ---------------------------------------------------------------------- Martin_fr · 2013-01-30 13:34 Quote from: Ruptor on January 30, 2013, 01:12:41 pmgdb reports as version 7.2 That is bad news. The "msg="No registers."" is a bug in GDB. Something that I can not fix. And I do not know a workaround for. Out of interest: Are the threads created by your app. Or do you not know where they come from? If they are not by your app, **maybe** we can identify there source and eliminate it. Maybe. Threads are also created by file open/close dialog. That is done by windows, and can not be avoided.. So if you have a breakpoint after any of this, or single step around them, then you need a GDB that does not break on threads. Otherwise your best chance, is to try other versions of GDB. - As I said my testing shows that GDB 7.3 and above took a turn for the worse. - Disregarding bugs in GDB, the IDE has been tested to work with all GDB versions from 6.3 up Other GDB can be found at:  http://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/ (Some need extra dll) I would suggest to test in this order: 7.0.50 (20100202) 6.7.50 6.8.3 7.5 (I do not expect it to be stable, but for completeness sake. / This needs more dll, I can send them, or you can search them on mingw, or get an SVN client, they are in our SVN too) --- There is a *very*,  *very*,  *very*, minor chance, that the controlflow in the IDE can be altered to change this. But this is rather unlikely. And even if, it would not fix it, just change the likelyhood... ---------------------------------------------------------------------- Ruptor · 2013-01-30 14:16 I have dowloaded the latest gdb although when it runs it says its 7.4 and I will see how it goes. I didn't have to add any DLLs it just seems to run. My code uses directory dialogue that has popup windows so I guess that is where the threads are coming in but that is all hidden from me and I don't want to know anything about. Thanks for your help. I will see what happens. ---------------------------------------------------------------------- Martin_fr · 2013-01-30 14:43 As I said, the log file would still help me to fix the hang, and instead display an error. Also to check why you got the TGDBMIDebugger.ProcessResult Error: ,msg="mi_cmd_symbol_list_lines: Usage: SOURCE_FILENAME" message. Which should be avoided. ---------------------------------------------------------------------- Ruptor · 2013-01-30 23:22 Good news for you or maybe not. I managed to lock Lazarus again with the log file running. It looks like a Lazarus problem to me since it is induced by press F9 at the wrong time when a run has been already initiated. I notice that the green and red are on in the break state too so perhaps the second F9 is being allowed during the program start period before the form appears where the red and green buttons are in the same state as if the program is held in a break state before starting. Just a thought. Any way the locked state is entered when F9 is pressed more than once but I think it has to be at the right time too because it took me several attempts to create the problem. OOPs the log is too big so I will try and send it on your email but if you don't get it can you send me an email to reply on. Thanks ps: can't see email in post any more. That's weird system said Laz2.txt was too large but it has taken it and it is the last half of the log. ---------------------------------------------------------------------- Ruptor · 2013-01-30 23:47 Here is the first half then if it gets loaded. ---------------------------------------------------------------------- Martin_fr · 2013-01-31 01:36 Ok, thanks for the log. I am still reading the log. That will take a while, and I may have to split this over a few days. Indeed the "no register" is not the issue. It is entirely recovered. The IDE sends a command at the wrong time, gdb gives the error, and both are happy. (The IDE deals correctly with  that error). Anyway that all happens after a normal exit of the debugged app. And that is already fixed, but only in 1.1. I will review it for future 1.0.x and decide if it gets merged. Anyway, this is not the problem you have. This also means, you can probably go back to gdb 7.2. But as long as the newer one does the job, it's fine. I will get back, as soon as I finished with the log ---------------------------------------------------------------------- wjackson153 · 2013-01-31 06:48 Can you not compress the file before uploading it, to reduce the file size ? ---------------------------------------------------------------------- Martin_fr · 2013-01-31 11:36 Quote from: Ruptor on January 31, 2013, 12:22:05 amGood news for you or maybe not. I managed to lock Lazarus again with the log file running. It looks like a Lazarus problem to me since it is induced by press F9 at the wrong time when a run has been already initiated. Almost. Actually you managed to press F9 while the debugger was still finishing the last debug session. That is you hit stop, killing the debugged app. Then the debugger indicates readiness for the next F9. But it is not yet. It still takes 1 or 2 seconds to shut down. I know, you recompiled in that time, so it was maybe longer than 1 or 2 sec. But the debugger does not do anything while the compiler runs. Normally you also can not compile while the debugger is active. But as indicated there seems to be a tiny moment at the end of a debug session. ---------------------------------------------------------------------- Ruptor · 2013-01-31 14:09 I quite often edit the code and forget it is still running. When fiddling with values things can happen fast like hitting CTRL F9 then OK then F9 immediately hence the problem showed up under these conditions. FYI my background is real time embedded software and hardware not this high level stuff. WJ I haven’t zipped this up for ages and it never crossed my mind but I thought of it after sending you my project. I assume the log would be unchanged by zipping. ---------------------------------------------------------------------- Martin_fr · 2013-01-31 14:27 Quote from: Ruptor on January 31, 2013, 03:09:44 pmI quite often edit the code and forget it is still running. The IDE actually supports that. You will see that the blue dots (indicatig lines with executable code in the current exe) move. In most cases the IDE gets them right. (Except if you join lines and then insert new lines again) Breakpoints will still be correct too. QuoteWhen fiddling with values things can happen fast like hitting CTRL F9 then OK then F9 immediately hence the problem showed up under these conditions. Yep, the IDE needs to bi fixed. ---------------------------------------------------------------------- Martin_fr · 2013-01-31 15:58 Ok, more details on how to reproduce, and how to avoid. If the debugger is: - running, - and the debugged app is NOT paused (not at a breakpoint or stepping) - and you choose "build" or "compile" => then a dialog will pop up "Can't compile while debugging. Stop Debugger?". If you press: -  yes, - and then press F9 (or run), right after the compiler finishes (F9 is ignored, while the compiler runs), => then you will hang the debugger. * Menu: "Run" > "Reset debugger" will fix the problem * Using "stop" first and then build, is save * Selecting "Build" or "compile" while the debugger is paused is also save. The dialog, will show, and you can select "yes"  and hit F9 as often and as quick as you can. ---  "stop" is  ctrl-F2. Using that first, also saves you from confirming the dialog ---------------------------------------------------------------------- Martin_fr · 2013-01-31 16:21 Given those findings, I also highly recommend to restore GDB 7.2