[SOLVED]How did I manage to screw up debugging in lazarus lazarus / 12-Debugger ---------------------------------------------------------------------- cdbc · 2023-09-04 02:59 Hi Somehow, in the last couple of days, I managed to f*ck up my debugger in laz; i.e.: When I try to debug even a simple program, I set a breakpoint at the first executable line and click Play; it compiles and runs (I think), that is, it just leaves me there, with the breakpoint still red(not grey, like when debugging) and I can't do anything, apart from clicking the red Stop button?!? which then kills the debugging process altogether... Funny thing, though, the program runs fine outside the debugger  So the last few days I've been debugging with "Writeln" and Logfiles; It's suboptimal, to say the least.... I need a little help on this... Oh, I do have some fairly complex units of code I'm working on, e.g.: a "Service-framework" and a "Plugin-framework" and it's a nuiscence without proper debugging  FPC 3.2.2 & Laz 2.2.6, both used to be stable releases... Regards Benny ---------------------------------------------------------------------- Joanna · 2023-09-04 03:32 I’ve had some problems with break points not going away. I don’t know if this will help but I delete all the breakpoints when I have problems with them ---------------------------------------------------------------------- af0815 · 2023-09-04 04:18 The old questions arise: What kind of system you are using (Linux, Win,...? What debugger have you configured (or misconfigured) (GDB or fpDebug or ?) Have you choiced a type for debugginginfos ? Are you executing with a debugger ? ---------------------------------------------------------------------- cdbc · 2023-09-04 09:13 Hi @af0815: As stated above are the versions of stable fpc & laz -> 3.2.2 & 2.2.6 My OS is fully updated PCLinuxOS with QT5 and I'm using FpDebug with dwarf3 for debugging, along with a debugger friendly debug.xml file and an optimized release.xml files... for their respective uses. Would it perhaps help to rebuild lazarus? As it stands, its very standard, no extra added components etc. It's sad, 'cause I kinda like the FpDebugger over GDB, but alas, switching over to GDB didn't help at all, so switched back to FpDebug. It's not a deadlock, I've checked and I can kill it with a click on the red stop button. The program runs as it should outside lazarus & FpDebug or GDB?!? Regards Benny ---------------------------------------------------------------------- Martin_fr · 2023-09-04 09:33 First of all, make sure your project does not have old or duplicate ppu or o files. If you have include path (maybe mixed with packages...). So also check in any packages that you have. Ideally remove all ppu files, and rebuild. If you use external debug info, also remove the dbg file. Then ensure, that there are no symlinks into your project/packages. I am not sure if it affects fpdebug...., or was only with gdb. But if you have symlinks, and your IDE knows a file as "/home/you/project_foo/unit.pas", yet the compiler (and also debugger) know it as "/home/you/project_foo_alias/unit.pas" then that can cause all sort of issues. You say "only stop works" => what about the pause button? That should work too, it should pause and display the asm window. When you run your app, does the editor show small blue dots in the gutter (where it also shows the breakpoints) in any of your units? (for at least some of the functions?) Do you use "type TFoo = object" ? (old style) or generics? Quotet compiles and runs (I think), that is, it just leaves me there, with the breakpoint still red(not grey, like when debugging) Breakpoints shouldn't be grey, when debugging... (breakpoints can be green, if you disable them) It being "red" is good and correct. The important question is what symbol is show on the breakpoint. ? => this should only be on the breakpoint when your debugger is not running X => this indicates the breakpoint could not be set V (checkmark) => this means the breakpoint was activated for the debug session (This is what it should be, while debugging) || (pause symbol) => Not activated, the debugger did not find the unit in your app (usually if the code may be part of a library, not yet loaded) ---------------------------------------------------------------------- cdbc · 2023-09-04 13:25 Hi first off, see attachment... Regards Benny ---------------------------------------------------------------------- cdbc · 2023-09-04 13:49 Hi @martin_fr: Second off... - no objects, I have classes and corba interfaces - no generics, don't know how to use them yet  - yes, there are blue dots in all units; for testing, I've removed threading,   locking, shared memory and loading of plugin-libraries... - I've vreated one class to hold: a data-container(bom), reader & writer-   classesp(backend) for providing data, the test-object itself(soon to be a   plugin lib) for transferring data to new location, also a class, a "Print"   procedure to write data to console and a "Transfer" procedure to transfer   data... - when I compile it (with or without debug info) and run it from a console, it   works just fine, I just cannot debug the darn thing! - when I click "Pause", I get the asm-view seen in attachment, alas, I don't   read asm'sk  :'( Hope it all makes sense to you  Help, please Regards Benny ---------------------------------------------------------------------- Martin_fr · 2023-09-04 13:55 Ok, that looks all correct. 1) Have you tried a breakpoint on a different line (not an a "begin" line). It shouldn't matter, but ... 2) If using optimization level 1 => try level 0  -O- QuoteFPC 3.2.2 & Laz 2.2.6,Oh, important 3.2.2 => that has a nasty bug, which at least on Windows 64 bit has screwed the debugger before. If you compile your IDE, compile with maximum -O1 -O2 and may break the debugger. On Linux, well it hasn't been reproduced before, but ... ---------------------------------------------------------------------- cdbc · 2023-09-04 15:44 Hi 1) The breakpoint is on "begin"-line, because it's the only line where, it turns    grey, as if it would start debugging, when I step into(F7), it all goes byebye. 2) Just tried with optimization = 0; => no change. 3) Do you think it would help to recompile the IDE with optimization 0 or 1??? 4) I'd hate to have to recompile FPC, as I normally ask my distro- people, to    compile and package fpc & lazarus for me, then I have them in a couple of    hours and part of the distro Nice with a rolling release and people in the    know behind it  PCLinuxOS-kde/QT5 (libc 2.34) Thanks for your help so far, anything else I can do?  Regards Benny ---------------------------------------------------------------------- Martin_fr · 2023-09-04 16:41 Quote from: cdbc on September 04, 2023, 05:44:19 pm1) The breakpoint is on "begin"-line, because it's the only line where, it turns    grey, as if it would start debugging, when I step into(F7), it all goes byebye. I am still not sure about "turning grey" => breakpoints don't get grey. Though, the line background color may turn grey, but that is if the breakpoint is hit => so then the debugger would have stopped at the breakpoint. When that happens => does the stackwindow (open it before) show any form of life? I.e., does it fill up with a stack trace for at least a very brief moment? Open the history Window (debug windows)=> does it have an entry? I would assume that you at some point deleted and reset the breakpoint? Otherwise, does it have "break" enabled, and "auto continue" not set? (Because a breakpoint can do other things than just break) Quote2) Just tried with optimization = 0; => no change. 3) Do you think it would help to recompile the IDE with optimization 0 or 1??? On Windows => definitively. On Linux => I haven't seen problems with the IDE compiled -O2 / but it is possible There is a bug in fpc 3.2.2, where it wrongly translates some parts of the IDE, if the IDE is compiled with -O2 (or higher). Quote4) I'd hate to have to recompile FPC, as I normally ask my distro-people, to No need. (Or not that I know of) Quoteanything else I can do?  Run the IDE from a terminal, so you can see the IDE stdout. Maybe the debugger prints out some error or warning. Run lazarus as  lazarus.exe   --debug-log=FILE   --log-enable=DBG_STATE,DBG_DATA_MONI TORS,DBG_ERRORS,DBG_VERBOSE,DBG_WARNINGS,DBG_BREAKPOINTS,DBG_FPDEBUG_V ERBOSE,FPDBG_BREAKPOINT_ERRORS,FPDBG_BREAKPOINTS and attach the file. NOTE: the file may contain unit names, and names from your sources (variables, functions, types...) ---------------------------------------------------------------------- cdbc · 2023-09-04 17:11 Hi first breakpoint... ---------------------------------------------------------------------- cdbc · 2023-09-04 17:12 Hi second callstack... ---------------------------------------------------------------------- Martin_fr · 2023-09-04 17:34 But the callstack picture shows your app is paused? - There is a callstack - The green run ("play/triangle") button is active - the "pause" button is not active. For all I can see your app is paused at the callstack? Did I misread something in your earlier posts? I thought you said the debugger does not break at the breakpoint? ---------------------------------------------------------------------- cdbc · 2023-09-04 17:53 No you understand it right, as I said, THIS "begin"-line is the only place where the debugger breaks/pauses, one more step(F7) and it's all byebye... Here is an end-message from running in a console...: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 LAZARUS END - cleaning up ...FreeFormEditor: FormEditor1=TFormEditorHint: (lazarus) [TMainIDE.Destroy] B  -> inherited Destroy... TMainIDEHint: (lazarus) [TMainIDE.Destroy] ENDHeap dump by heaptrc unit of /home/bc/.lazarus/bin/lazarus12879891 memory blocks allocated : 2023413665/204994039212879883 memory blocks freed     : 2023412897/20499396248 unfreed memory blocks : 768True heap size : 917504True free heap : 917504Should be : 915200Call trace for block $00007F9C80F12240 size 96  $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas  $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp  $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.ppCall trace for block $00007F9C80F12100 size 96  $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas  $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp  $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.ppCall trace for block $00007F9C815CB240 size 96  $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas  $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp  $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.ppCall trace for block $00007F9C815CB100 size 96  $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas  $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp  $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.ppCall trace for block $00007F9C8157B240 size 96  $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas  $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp  $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.ppCall trace for block $00007F9C8157B100 size 96  $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas  $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp  $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.ppCall trace for block $00007F9C80C42240 size 96  $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas  $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp  $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.ppCall trace for block $00007F9C80C42100 size 96  $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas  $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp  $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.pp [bc@hp test_app]$ Looks kind of interresting... ---------------------------------------------------------------------- Martin_fr · 2023-09-04 18:09 The leaks could mean that the debugger was not cleanly exited (like when "reset debugger" is executed (the don't have to happen). They could have other causes, but don't directly point to stepping and breakpoints. (and line number mapping gets loaded, as you get the blue dots) Please start the IDE with the logfile setting from my previous post. - set the breakpoint on the begin line - start debugger with run, so it will pause at that begin line - when paused at the begin line: click the gutter to set a breakpoint on the line TWO below that (take note if it gets a checkbox, or other symbol) - press F8 as if to single step - Stop - Reset debugger - Exit IDE send the logfile please. --- For this test, disable "external debug info" (if you do use that). So the debug info will be part of an oversized executable. ---------------------------------------------------------------------- Martin_fr · 2023-09-04 18:11 Did you system/OS receive any updates lately? E.g. could the linker have been upgraded? ---------------------------------------------------------------------- cdbc · 2023-09-04 18:12 Just now I tried to run laz with your params: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 lazarus-ide   --debug-log=DBG   --log-enable=DBG_STATE,DBG_DATA_MONITORS,DBG_ERROR S,DBG_VERBOSE,DBG_WARNINGS,DBG_BREAKPOINTS,DBG_FPDEBUG_VERBOSE,FPDBG_B REAKPOINT_ERRORS,FPDBG_BREAKPOINTS Attached is the file... Funnily enough, this time I succeeded in stepping through the small test, ended in a segfault though?!? I'm very puzzled ---------------------------------------------------------------------- cdbc · 2023-09-04 18:15 Well yes possibly, I do a system-update ca. once a week, it's been about 5 days or so... could be around that time, it all went to H*ll in a handbasket. ---------------------------------------------------------------------- cdbc · 2023-09-04 18:26 If I start laz normal, it's back to freezing... ---------------------------------------------------------------------- Martin_fr · 2023-09-04 19:12 Ok, so it seem the logging framework doesn't work either. That however isn't a problem an your side. I just tested, it seems that it doesn't work with the official builds. So back to square 1. You said the same issue happens when you use gdb as debugger? If so, then open Menu: View > Ide Internals > Debug Output   (could be that 2.2.6 still has this in "Debug Windows" submenu, but must be "debug output", not console). Switch to gdb, run => and get the content of that window.  (window must be open *before* run). Also for sanity reasons => a new project with just a few lines of code => that will work in the debugger? ---------------------------------------------------------------------- cdbc · 2023-09-04 19:37 Ok, here's output from gdb in "Debug Output" Tried to paste it here... file is in attachment. It had a lot to say ---------------------------------------------------------------------- cdbc · 2023-09-04 19:40 hmm.. gdb no likey. ---------------------------------------------------------------------- cdbc · 2023-09-04 19:49 And  the sanity check looks like the attachment... ---------------------------------------------------------------------- Martin_fr · 2023-09-04 20:03 OK according to the debug out text, gdb reached the breakpoint at the "begin" line.  (line 48). Anyway gdb confirmed that the line info for the file (the "program foo;" file) is ok. There are lines from 15 with gaps to 70. And the have sensible addresses (it's 32 bit, isn't it?) I wonder on your asm image "fpc_initializeunits" => how did you stop there. If I look at the debug output, you single stepped. Did you single step from the "begin" line? Then that would mean that FPC packed the call to run all the "initialization" sections into that begin line. Which then means, could it be that there is some code in any initialization section that runs forever (and does whatever you see the app doing)? Then of course no other breakpoint would be reached. ---------------------------------------------------------------------- Martin_fr · 2023-09-04 20:07 If you run your app, and it runs past the begin, but doesn't reach the next line. If you then press pause. The asm will pop up => Ignore that, open the stack window, and see if it shows anything (maybe some unit is somewhere in the list of callers) You may need to try that with gdb or fpdebug / gdb (if it does not crash) may be better at finding the stack. But if gdb crashes, then try fpdebug. ---------------------------------------------------------------------- cdbc · 2023-09-04 20:35 Okidoki, makes sense, btw. it's 64 bit machine/os/fpc/laz I'll try to hunt down a/some initialization sections and have a looksee... yes I single-stepped from "begin" Will try your suggestions, think I have to reboot my machine now, this fiddling with GDB have made it sluggish  :'( will report back here, with my progress... Thanks so far Martin  Regards Benny ---------------------------------------------------------------------- cdbc · 2023-09-10 12:02 Hi Pheeeewwwww.... finally back on track  In my search-quest, I found not a(ny) intialization "BuBu", but instead: 1) In a class that gets used as a kinda plugin(like fpimage architecture) and    will end up in a library as a real plugin, I found a double-free, checking for    nil is no good, when you call free  In the process I learnt, that FreeAndNil    doesn't check for nil  Somehow FpDebug was aware of that... 2) In a key containerclass I'd somehow managed to keep inheritance, but    new/re-introduce the interfaces it supports, which resulted in an    "Interfaces are not related" warning from fpc and the need to typecast a    hole slew, throughout the code, even though, they clearly were the same    interfaces and classes  What a hype & a mess  After I got the D*MNED double free out of the way, I could slowly start debugging again, but FpDebug kept crashing at random places in the code, then I scrutinized the whole code-tree and found the just as subtle 2) bug. So Kudos to FpDebug, well spotted, but you could just have said so  That took a lot of coffee and cigarettes... Thank you Martin_Fr for your help, in getting me as far as I could debug a little and find my way  Regards Benny ---------------------------------------------------------------------- Martin_fr · 2023-09-10 12:18 double free and nil stuff..... If you are on Linux, or can run your app in a Linux VM => valgrind --tool=memcheck yourapp The resulting traces can be loaded into the IDE menu: view > leaks and traces (Afaik under fpc trunk using llvm as backend, there are settings for similar checks / but not yet gone there myself) 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 but FpDebug kept crashing at random places in the code FpDebug, aka the IDE ? I.e. the IDE said it had a crash, and may be corrupted? Or your app crashed under FpDebug? In case of the former, it be interesting if Lazarus 3.0 still crashed... But since you fixed the stuff.... ---------------------------------------------------------------------- cdbc · 2023-09-10 14:06 Hi It was crashing while debugging in the IDE, then I noticed in the console output(started lazarus-ide in konsole) that some internal debugger classes tripped over some interface stuff of mine, from then on things moved forward... I really respect the amount of work you've put into FpDebug, thanks... Everything is now back to normal and I've learnt a few things, along the way. Regards Benny ---------------------------------------------------------------------- Martin_fr · 2023-09-10 14:18 Quotethat some internal debugger classes tripped over some interface stuff of mine, from then on things moved forward..."interfaces" are empty  for the debugger (just an empty structure, the methods are not in the info). So the debugger will/should just show an empty struct "()" or similar... But it should not "trip". When you get to 3.0, I'd appreciate if you can check if it still happens. Thanks. ---------------------------------------------------------------------- cdbc · 2023-09-10 15:31 Hi You're absolutely right, it showed me these 3 possibilities: 1) IDataReader() => everything is OkiDoki 2) IDataReader=nil => after an assignment, something went wrong, look into    it, typos, conditions not met etc... 3) IDataReader??? => something "fishy" is going on, investigate longer,    harder deeper!!! It was the 3) the put me on the sent  Cool. I will keep an eye out in the new upcoming release... Looking forward to it  Regards Benny