debugger just hangs. lazarus / 12-Debugger ---------------------------------------------------------------------- lazer · 2022-10-17 09:40 Hi, I have a project which compiles and runs as expected and exits cleanly.  It still needs some features sorting out so I need to start using the debugger. If I do "run to cursor" , I was expecting my prog to run to that point and then see the cursor at the line in the source code window and "step" and "step into" in the run menu available.  Instead I see nothing. Run|Stop ( cntl-F2 ) seems to do nothing and is always enabled. All the other debugging command remain greyed out. Just about anything I want to do including quitting Lazarus prompts me to end debugging, except it never does. The following action ( quit) never happens and if I try to quit again I get asked to end debug again. The only think which seems to work is compile. This also asks but does actually run when it apparently fails to stop anything. If I look ps ax , I see lazarus , gdb and my executable as processes. kill -9 fails to kill my process or gdb, the only way to clean up is kill lazarus. Maybe I'm just expecting something other than what is supposed to happen but it looks like debugger is locking up. Is there something else I should be doing?  Why does the process refuse to stop with cntl-F2 or any other means ? TIA. Quotefpc 3.3.1 from source. Lazarus 2.3.0 (rev Unversioned directory) FPC 3.3.1 x86_64-linux-gtk2 ---------------------------------------------------------------------- MarkMLl · 2022-10-17 09:47 I'd suggest starting off with a very simple project and getting used to breakpoints etc. Make sure that your program is actually compiled to generate debugging information. Note that you can only set an explicit breakpoint on a line for which the compiler actually generates code, identified by a marker in the LH gutter while running. Generally speaking I find it works reliably, although under certain circumstances you can get a gross lockup if you put a breakpoint in (e.g.) a menu event handler. I assure you that you'll know it when you see it, since the only way to recover from that one if by using and killing the program being tested. MarkMLl ---------------------------------------------------------------------- lazer · 2022-10-17 10:03 Thanks for the reply. Quote although under certain circumstances you can get a gross lockup if you put a breakpoint in (e.g.) a menu event handler. That's unfortunate, most of my program is called via menu handler events. Also in the code editor, the context menu has  "goto bookmark" and "toggle bookmark" both of which seem to have submenus but they are tiny empty rectangles, which I guess are supposed to be populated with existing bookmarks.  I add a bookmark with cnlt-shift-1 and they remain blank. BTW I run lazarus from terminal window, so I can just cntl-c out. ---------------------------------------------------------------------- lazer · 2022-10-17 10:25 OK, I have a one form, one button prog shows the same issues. I have {$D+} at the top of the main form.  Is that correct to get debugging info ? Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure TForm1.Button1Click(Sender: TObject);var i:integer;begin  i:=form1.tag+1;  close;end;  I set a breakpoint on the assignment and it flies through it. If I start debugging with "step over" , I get the disassably window popup at what looks like internal lazarus start up code ( logic enough so far ). I don't seem to get the interaction with the code editor. Maybe I'm just not expecting the right thing. ---------------------------------------------------------------------- MarkMLl · 2022-10-17 10:29 I'd suggest removing that and using Lazarus's project options to set it: apart from anything else you can expect it to be a per-unit thing. MarkMLl ---------------------------------------------------------------------- Martin_fr · 2022-10-17 10:31 1) You need to check if you are using "gdb(mi) based" or "fpDebug" debugger. So we know what to help you with. Tools > Options > Debugger > Backend: the selection is show in the toolbar on top of page. FpDebug is the recommended choice. - If using FpDebug, then (when asked) chose "Dwarf 3" - If using Gdb(MI) then chose "Dwarf with sets" 2) If F9 / Run does not seem to work: menu "Run" > "Reset Debugger" There is a known bug in FpDebug, that if you use F7 or F8 (step- in/over) *BEFORE* your started the debugger with F9 => then the debugger no longer reacts. So with FpDebug, you can not use F8 to get to the first line of code, you must instead set a breakpoint and then use F9 (Run). But once you are stopped at the breakpoint your can use F7/F8 With GDB you can start the debugger with F7/F8. It will (or should) run to the first line in the "begin end." block of the  Project.lpr (the source file that starts with "program ...". It will not stop in any ButtonClick event => there you need a breakpoint as well. 3) "Run To Cursor" => Same as F7/F8 => only works once the debugger has been started with F9. (not sure if it works in GDB) Mind there also is "Step to cursor" which does something different, and may stop unexpectedly. If you are on an older Lazarus, and only have "run to cursor" then that is the mis-named "step to cursor", which will not do what you want. 4) menu: View > Debug Windows > Breakpoints Make sure there are only breakpoints that you know about. Sometimes there are breakpoints in files with a wrong directory => that can lead to confusing behaviour. 5) On LINUX, if you break in an event (focus, key up/down, mouse, ...) the OS (or the desktop) sometimes can hang. Not always... This may also differ from distro to distro. It means GTK blocks until your app finishes its work => this should not happen, IMHO a bug in those linux distros. How ever, if you were running into this, your entire desktop, all apps would be frozen. So I don't think that is the issue here. And I have debugged on Linux (Fedora) without ever running into the issue. ---------------------------------------------------------------------- Martin_fr · 2022-10-17 10:35 Quote from: lazer on October 17, 2022, 12:25:12 pmI have {$D+} at the top of the main form.  Is that correct to get debugging info ? Menu: Project > Project Options Page: Compiler Options > Debugging: "Generate info for debugger" and then Dwarf 3 / with sets => as in my last post. And, if possible disable "smart linking" Also, ensure under "Compilation and Linking" to set Optimization to OFF (Or max 1) ---------------------------------------------------------------------- lazer · 2022-10-17 10:37 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i There is a known bug in FpDebug, that if you use F7 or F8 (step-in/over) *BEFORE* your started the debugger with F9 => then the debugger no longer reacts.That sound similar to what is happening. If I do F9 it just flies through because no breakpoints are working. If I start with F8 it does step in and disassembler comes up at LCL start up code. Looks correct. However, it is starting the prog with "Run to cursor" which is causing the lock up. Smart linking is off. Debugging was already on in project options. Using -O1 EDIT turn to -O0 and rebuilt. Still flying straight through the breakpoint. ---------------------------------------------------------------------- lazer · 2022-10-17 13:51 OK , followed the "recommended" FpDebug, rebuilt with -gw3 and I now have something resembling a working debugger. !! Many thanks for the tips getting that working. ---------------------------------------------------------------------- lazer · 2022-10-18 05:53 Well, I did say "something resembling" ...  big problems with variable evaluation. I can do all the usual stepping through code but I don't seem to have any access to variable values inside a local function. alt-F5 ( evaluate ) pops up the Debug Inspector window with the variable name under the cursor but it's "unavailable( error: Identifier no found: .... )" global string constants are visible, global pascal strings evaluate as empty strings. local variables , object properties etc fail to be found. I have a procedure of a Tform. Within that I have local variables and a local function and a procedure. While stepping in the local function, the debugging cannot find the local variables of the method. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure theForm.test();var  procInt: longint;    function localfn():longint;  begin     if (procInt<>0) then result:=procInt;   // when debugger is on this line it cannot evaluate procInt ###  end; Begin  localfn;end;  debugging info is -gw3 Thanks. ---------------------------------------------------------------------- Martin_fr · 2022-10-18 09:59 Quote from: lazer on October 18, 2022, 07:53:42 amWell, I did say "something resembling" ...  big problems with variable evaluation. Just double checking: Tools > Option > Debugger Backend => is set to FpDebug? How recent is your fpc 3.3.1? The last 3.3.1 test I did is 5 or 6 weeks ago (and IIRC worked fine for watches/variable inspection). There is always a chance something changed in fpc. There may be, due to work on anonymous functions, which may affect nested functions. FPC has a special way to encode "nested procedures" for the debugger. (Because Dwarf doesn't have a way to encode this directly). FpDebug knows how FPC does this. Unless it changed recently... Do you have a small test project, to reproduce? (including lpi file, so I have identical settings) You can try, if gdb can evaluate this. While gdb should do dwarf-3, my experience is, that it does better with "dwarf with sets". That is gdb itself sometimes crashes on certain dwarf info, and it is more likely to crash with dwarf3. I did another quick test on Win-10 64bit with my 5 weeks old fpc 3.3.1 (and FpDebug). I copied your code into the Form.OnCreate event of a new app. In that case the debugger can see the variable. I haven't had time to update my FPC (or launch my Linux VM) Btw, when you are on the "begin" or "end" line => local variables (including from the enclosing function) don't work. That is "normal". Variables are initialized during the "begin" line (and that includes the link to variables in the enclosing function). I am aware that you are NOT on the begin line. But just pointing that out. ---------------------------------------------------------------------- lazer · 2022-10-18 10:42 QuoteJust double checking: Tools > Option > Debugger Backend => is set to FpDebug?Yes, you will recall I could not debug at all with gdb default. How old ?  14th Oct QuoteThere may be, due to work on anonymous functions, which may affect nested functions. I really need a version which works, I was not planning to join the dev team. I probably should not be using "main" if it is that unstable. What do I need pull from github to be in a more known and tested environment? Thanks. ---------------------------------------------------------------------- Martin_fr · 2022-10-18 11:05 Well, I can't tell if it is the FPC version or something else... For that I need to reproduce the issue. (I am building the latest fpc now / for win / Linux will have to wait) The release versions of FPC are tagged in git, so you can checkout/switch to any of them. (I don't know what your git experience level is...) You can also go for the fixes branch. (Same here my last test is 5 weeks ago / but the fixes branch only gets selected updates, so it is less likely to "fail") So for example any of   git switch fixes_3_2   git switch release_3_2_2 and, if needed a fast forward It is possible to have more than one FPC version installed. However on Linux this is a bit of a pain... (fpcdeluxeup should be able / but I don't know exactly how / I use a manual approach, but it's complex) The question is why you went for 3.3.1 ? If you rebuild, "make install" will afaik install ppu into a directory with the  fpc version number in the patch => so make sure to update the fpc.cfg file. Mind the fpc.cfg can be in various locations (/etc  or under /home/____ or a few other places I don't have a list...) ---------------------------------------------------------------------- lazer · 2022-10-18 11:30 QuoteThe question is why you went for 3.3.1 ? LOL   because when I was running 3.2.2 and posted problems I got shouted at by smart Alecs  who told me I was using "OLD" versions and I needed to get up to date. Of course such persons never have anything useful to say about the actual problem. I have /lib/fpc/3.2.2 built , so I can just change the symlinks to point to that.  What should I do with Lazarus? Quote (I don't know what your git experience level is...)Apart from git clone , git branch and git pull not too hot thx ---------------------------------------------------------------------- Martin_fr · 2022-10-18 12:02 Quote from: lazer on October 18, 2022, 01:30:59 pmQuoteThe question is why you went for 3.3.1 ? LOL   because when I was running 3.2.2 and posted problems I got shouted at by smart Alecs  who told me I was using "OLD" versions and I needed to get up to date. 1) This is a public forum. There are thousands of people, with that many opinions... And worst, you can't tell if they actually know what they talk about. That said, my experience lays with the debugger. On that subject I *usually* know what I talk about (since I have implemented large parts of it) As for different FPC versions, I am just a user. Albeit, a user with some experience. 2) Its a bit of a conundrum. FPC 3.2.2 is the latest "stable" release. Unfortunately it is not that "stable". In my opinion, your next best bet is the fixes_3_2 branch (that is 3.2.3 / mind that this version is a "moving" version => it is always the top of the branch). In my opinion.... 3) As for Lazarus 2.3 If you have a version that runs for you => good. There are occasional regressions, where something stops working. Usually it gets fixed within a week or two. As for Lazarus 2.3 and FpDebug => If your 2.3 is from within the last 2 weeks, it should be ok (that is, I am not aware of any regressions).  If your Lazarus 2.3 is between 4 and 10 weeks old => there have been a few unstable revisions. Of course FpDebug is not bug-free => the above only means, that according to my testing, current 2.3 does not have issues that aren't present in 2.2.4 too. However, it has many issues fixed that do exist in 2.2.4. QuoteI have /lib/fpc/3.2.2 built , so I can just change the symlinks to point to that.  What should I do with Lazarus? Apart from git clone and git pull not too hot I don't think that using an older Lazarus will fix that particular issue. However, I did in the meantime update my fpc 3.3.1 (on Windows) => And I can still inspect that variable. It is possible but rather unlikely that this is different on Linux. So it may not be the fpc version after all. But then that means, the origin of the issue is something else. And ideally we find a way that I can reproduce it. Can you reproduce the issue in a new application, with just one method on the form, and your code in that method? In your current app (where you get the error), when you are stopped at the line, in the nested proc: - Are there small blue dots, on the left side in front of the "begin" and "end" line? - What does the stack window show? - What does the local window show? => if you select the 2nd line in the stack window (the caller) and make it current  (context menu / or 3rd button in the stack-win- toolbar "green arrow") After you made it current - What does the local window show? - Can you inspect the variable? => Also either before you step into the nested proc, or after you stepped out => that is when you are in "theForm.test" - Can you inspect the variable? ---------------------------------------------------------------------- lazer · 2022-10-18 13:15 Hmm.   I  just did a small test prog and it variable do evaluate.  That means it's going to be a pain to find out at what point it stops working. Quote- Are there small blue dots, on the left side in front of the "begin" and "end" line?yes. Quote- What does the local window show? - Can you inspect the variable?local variable window empty No. I'll dig around a little.  I have three levels in one part I just looked at . The top level ( a proc of the Tform object ) has local variable window empty I step into next level and do have evaluation and non empty locals. from there I call another proc which is a proc of the Tform object  and I have no eval again.  :? Odd.  I'll try to pin down where I do or not not get eval and try to mimic it in a minimal program. ---------------------------------------------------------------------- Martin_fr · 2022-10-18 13:34 Quote from: lazer on October 18, 2022, 03:15:00 pmlocal variable window empty Ah, not good. There should be (values may differ): Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i $parentfp=$ parentfp_void_pointer($00000000013FFC50)$result=0LOCALFN=0RESULT=0  Do you have (in that unit) any Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$modeswitch ....}What is your "{$mode ....}" ? Or do you specify any of this on the command line? While extremely unlikely (due to other observations/statements you made): The unit with that code is part of your project? It is not in some package? Menu: Project > Project Inspector --- Will show the unit in the  list?   (Or at least the unit is in the same directory as all the units in "project inspector"?) You do see other variables (e.g. locals in other procedures) in that unit? Try doing menu: Run > Build Project > Project options > Debugging Do you have "Use external debug info" enabled? While this should work, try to disable it. If you had it enable, then after switching it off, go to your project directory and remove any *.dbg file (keep backups / though likely you never need them) ---------------------------------------------------------------------- lazer · 2022-10-18 13:58 Main unit ( there's only two and the other is a help dlg which is not called ) . Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$mode objfpc}{$H+} Later I set {$H-} and for some bits including where I'm testing: {$I-} I have seen that kind of local content while in part of this this call stack. It has been empty on either side ( in terms of call depth ) of where it works . Project > Project options > Debugging  : no just -gl QuoteTry doing menu: Run > Build  :  I do lots of that and  "clean" build , which grumbles it can't rebuild the lazarus units (which are root owned ). ---------------------------------------------------------------------- Martin_fr · 2022-10-18 14:17 ok, that sounds all good. Btw, please check in your project folder for files *.ppu For each *.pas / *.pp / *.lpr  file (not for inc files), there should be ONE ppu. If there is more than one => something is wrong Also in your code Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure theForm.test();"theForm" is an object? Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i type theForm = class .... It is not by any chance Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i type theForm = object ....? Because that does not work (fpc does not write full debug info for that) -gl  is fine. It adds code so that stack-dumps on the console (if your app crashes) have units and line numbers (rather than just addresses). It's not needed for the debugger itself (the debugger looks up the address itself). For the debugger it needs "Generate info for the debugger" => But we covered that before. The important bit, is to make sure that the compiler did apply those settings to you unit. => We know that the "line info" (address mapping) is included, because there are "blue dots". => And if you had any other variable (WITHIN that unit), that you were able to inspect, then info for variables is also written. If we know, that (some) variables in that unit can be inspected, then we need to find why that one procedure is excluded. - Can you copy the callstack, and paste the first 3 lines of it? - Is the line you are paused at, in any except or finally block ? (IIRC that should not matter on Linux, but just checking...) ---------------------------------------------------------------------- lazer · 2022-10-18 14:27 I do have a Tobject but it is not the form in question, that is a Tform. The bits which work and those which don't are all within the Tform code. The form procedure are where the problem happens but the form does include and instance of the Tobject. That could the be key to what is happening. ---------------------------------------------------------------------- Martin_fr · 2022-10-18 15:42 Quote from: lazer on October 18, 2022, 04:27:32 pmI do have a Tobject but it is not the form in question, that is a Tform. The bits which work and those which don't are all within the Tform code. The form procedure are where the problem happens but the form does include and instance of the Tobject. Different things. "Object" <> "TObject" Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i type TFoo = object ... end;Is a very old syntax. It is an kinda "advanced record" with some limited inheritance. Notice that the word "object" stands in place of the word "class". You could send the debug info (though that will be a rather large file). Then I could check what FPC generated. Don't know how far that will get us, but it's worth a try. Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i objdump --dwarf=info  your_executable > dwarf.txtzip or tar-gz the result. I also need the unit name, and exact name of outer and nested procedure. I will send my email via PM. ---------------------------------------------------------------------- lazer · 2022-10-18 16:22 QuoteIs a very old syntax. It is an kinda "advanced record" with some limited inheritance.Yes, Object not Tobject, careless slip there. This is some old code I wrote in TPW which I wanted to port. Everything was objects and WM_messages and handles and API calls for everything.  I was hoping to port with a minimum of trashing what I had. The main window went Tform, I was hoping a few syntax adjustments would keep the rest. ---------------------------------------------------------------------- lazer · 2022-10-18 17:14 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i objdump: Warning: DIE at offset 0x2635 refers to abbreviation number 110 which does not exist  Does that matter? Output to that point only seems to concern LCL stuff. ---------------------------------------------------------------------- Martin_fr · 2022-10-18 17:37 Quote from: lazer on October 18, 2022, 07:14:41 pmCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i objdump: Warning: DIE at offset 0x2635 refers to abbreviation number 110 which does not exist  Does that matter? Not sure. I would have to check/debug how FpDebug handles this. For that I would need the actual exe (and potentially some more time). I would not need to run the exe, just load it using some test-tools based on FpDebug. If objdump produced some output, I would start with a look at that. About the "warning", I am not sure if this is caused by FPC, or by the linker that came with your Linux distro. Do you have "smart linking" enabled (Project options > Compilation and linking)? Try to disable it. Also try to see, what happens if you use "dwarf with sets" instead of "Dwarf 3" ---------------------------------------------------------------------- lazer · 2022-10-18 17:53 Nope, same drop out.  something does not like my code. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i     objdump: Warning: DIE at offset 0x2635 refers to abbreviation number 110 which does not exist     Doesn't this error indicate there is something wrong with the internal data structures ? That may explain why it can only provide variable data for some of the source code. ---------------------------------------------------------------------- lazer · 2022-10-19 11:23 I've noticed that once I'm stepping in a program I don't access to run F9, to continue execution. I'm forced to single step. Similarly, once the program is running , I don't have access to "run to cursor". Maybe I'm just misusing the interface but I would expect both these possibilities to work. How mature is this FpDebug debugger interface ? Thanks. ---------------------------------------------------------------------- Thaddy · 2022-10-19 11:28 FpDebug is just fine. But bad code can crash any debugger......... ---------------------------------------------------------------------- lazer · 2022-10-19 11:33 FpDbug is not "fine".  Half the time I have no local variables.  Martin has recognised the issue and is trying to look into it. Can you explain why I run to cursor does not work?  Is the interface fine and I'm missing a trick ? ---------------------------------------------------------------------- Martin_fr · 2022-10-19 14:19 Quote from: lazer on October 19, 2022, 01:33:08 pmFpDbug is not "fine".  Half the time I have no local variables. "FpDebug" vs "the overall debugging experience" vs "the limited debugging that you get for some unknown reasons" Those are technically very different things. Then again from your point of view, it really does not matter what is to blame. You are (and rightly so) interested in what you actually get. Though, the issue is, that there is a possibility that the linker "ln" on your Linux distro (not part of fpc or Lazarus) is broken. Maybe, maybe not..... So right now, we don't know if it is Fpc/Lazarus or something else. The point is, I done lots of debugging (Window / Linux), and I don't have the same problems. Neither does it seem that lots of others have them... For a proper debug experience lots of different parts need to work together - FPC must provide the info - the linker (part of the Linux distro / On Win part of the fpc distro) must pass that info forward - The debugger must handle it. Known issues: - "property Foo: TFoo read GetFoo;" => does not work. Fpc does not provide debug info for that, so no debugger can currently show that. It is being worked on, but will still be some time. - "TFoo = object ... end;" => methods of TFoo have no variables (no locals, no self, ...). A bug in FPC. Quote Martin has recognised the issue and is trying to look into it. I am still waiting for any of the info, I have asked for. I don't yet have the objdump ? As I can not reproduce it, I will need feedback from you (and probably more than what has been asked so far. QuoteCan you explain why I run to cursor does not work?  Is the interface fine and I'm missing a trick ? 1) It may not work to "start the debugger". I.e. if the app is not yet running/paused, then you need to F9 to a breakpoint. Once there it should work. - That, if it is the case, is a bug in FpDebug - at least for "Run to cursor". - "Step to cursor" can not be used to start the debugger, because it would never step into any code... See how it works below. 2) The key shortcut maps to maps to "Step to cursor". That is different from "Run to cursor" https://wiki.freepascal.org/Debugger_Status#Execution_Control_.28Run.2 C_Step.2C_....29 You can change the keymap in the settings (tools > options) "Step to cursor" => continues to "step over" until it - either reaches the cursor pos - steps out of the current procedure Because it "steps over" it will not stop at the cursor-pos inside a nested/recursive call. (This is a feature, not a bug) "Run to cursor" => is like setting a breakpoint at the cursor, and doing Run/F9. "Run to cursor" only exists since Lazarus 2.2. Before Lazarus 2.2 "Run to cursor"  was misnamed, and actually was "Step to cursor". ---------------------------------------------------------------------- lazer · 2022-10-19 14:35 I'm not bashing FpDebug, I just did not appreciate the smart reply from Thaddy, which did not address the questions I was asking. Quote"Run to cursor" => is like setting a breakpoint at the cursor, and doing Run/F9.Sure, from there you need a "continue" option.  I suppose I could set a breakpoint on mainform.close() and do run to cursor again, except that possibility does not exist either. QuoteI am still waiting for any of the info, I have asked for. I don't yet have the objdump ? I already tried with two options settings and the output fails as I reported. There's nothing useful coming form objdump. objdump fails with an invalid reference, maybe debugger is hitting similar issues and quietly swallowing the exception. The lack of eval may relate to the other thread.  If the debugger can't find TspeedButton, maybe there's a lot of other stuff I can't find. Is it possible to build "components" with -gw3 from the source tree.  I looked at make --help but did not find anything. I tried it from IDE but the component file have not changed. ---------------------------------------------------------------------- Martin_fr · 2022-10-19 15:41 I don't use the makefile a lot. I usually build the IDE from within the IDE (as all my installs are in the home folder). If you have a root installation, then rebuilding the LCL will create new files in /home/yourname/.lazarus/___ somewhere. (The details on that aren't exactly my area of expertise) make should take something like OPT, OPTS, or OPTIONS. e.g make bigide OPTS="-gw3" But I am not sure which name to use. ---- If you open (while the debugger is running) one of the LCL units, and navigate to some code inside it, you should see if there are blue dots or not => that should tell you if there is debug info. If there are blue dots, but the variables/types/classes are not present, then its likely the bug that we are hunting. If objdump can't dump it, then yes the debugger likely can't read it either. If there is any chance for me to get the compiled exe, that might help. Because I can then load the debug info from it... Or well tell FpDebug to do so, and see where it goes wrong. Of course it may not mean that I can make it load-able. Just at least add a warning for the broken info. The other point is, looking at the output of objdump, it can be said there is something wrong in the debug info. This may be either FPC or the linker. - If it is FPC, then it must relate to some very specific code/data construct => after all, it does not seem to happen to everyone. - If it is the linker => maybe there is a way to update it. Though I am not that familiar with the linux package system, and I wouldn't know which package you would need to try and update. ---------------------------------------------------------------------- Martin_fr · 2022-10-19 15:46 One more thing about "Run to cursor" The cursor must be at a line with a blue dot. That is a line with code, that the debugger can stop at. If the cursor is at an empty line, that line will never be reached. And the debugger is currently not smart enough to find the next line with code (gdb does that / but gdb also sets a breakpoint 500 lines after the line the user clicked, if those 500 lines have no code (e.g. interface section) => and that is massively irritating) ---------------------------------------------------------------------- lazer · 2022-10-19 17:26 QuoteIf you open (while the debugger is running) one of the LCL units, and navigate to some code inside it, you should see if there are blue dots or not => that should tell you if there is debug info. If there are blue dots, but the variables/types/classes are not present, then its likely the bug that we are hunting. I did run to cursor in a proc where I have no local variables and IDE is pretending it does not know what a TspeedButton is.  I file|reopen  speedbutton.inc ( which got opened automatically at some point and is in the lazarus-main/lcl/include tree ). Here I see blue dots !