What is the right way to get debug working? lazarus / 12-Debugger ---------------------------------------------------------------------- micheus · 2012-04-16 16:58 I'm converting an Delphi project (already working for years) and now I'm in test(validation) process. A few informations: - There is a form that I create dynamically for data edition (database fields); - The dataset (TMDODataSet) is opened before I call ShowModal and closed in OnClose event. After I start the program I can call this form with success; I edit the data and close the form; It's all fine. Then, I call the form again and now I get this error: raised exception class 'External: SIGSEGV'. I read this thread: SIGSEGV wen running project with debugger, but it isn't related to it - I don't have the CMGxSrv.dll in my system. By debuging I found that the error occurs in the dataset open call, but I'm not able to debug it (MDO pack). In an other thread, someone told me: "You need to build the compiler with debug info to be able to trace into maskutils." So, I tried by setting: - Tools->Configure Build Lazarus; - Profile to build: Build All; - I checked out Debug in the Defined (right box); - and then I clicked Build. I tried to debug the code again and I still get the same error. As an other possible option, I opened the MDO source package and changed its Compiler Options. In the Linking item I checked "Generate debuggin info for GDB (slows compiling) (-g)". This time I'm getting this error dialog when I Lazarus is started and when I left it: http://imageshack.us/photo/my- images/29/lazarusdebug.png Does anybody has any suggestion? Quote from: My Lazarus InformationLazarus v0.9.30.4 FPC 2.4.2  (I think it should to be 2.6.0 as I download lazarus-0.9.30.4-fpc-2.6.0-win32.exe) SVN 35940 TIA /Micheus ---------------------------------------------------------------------- Martin_fr · 2012-04-16 17:40 1) The heaptrc is not a real error. It shows if there are memory leaks. In your case it shows that there are none. Don't specify -gh You need -g  (or -gw if you use dwarf) 2) "- Tools->Configure Build Lazarus;" This will rebuild the LCL (and packages listed in the "install packages" in Lazarus "package" menu) If your unit is part of the RTL or fpc packages (as maskutils is) then you must rebuild fpc itself. This is not something you can do from inside lazarus. Search for "fpc buildfaq" http://wiki.lazarus.freepascal.org/buildfaq You do need an released version installed. And in the path. (make sure make, is the fpc/gnu make, and not pointing to Delphi's make). make.exe clean  make.exe all  OPT="-g -O-1"  make.exe install  INSTALL_PREFIX=c:\FPC\  Don't forget to create/adapt fpc.cfg ---------------------------------------------------------------------- JuhaManninen · 2012-04-16 17:59 Quote from: micheus on April 16, 2012, 06:58:04 pmLazarus v0.9.30.4 FPC 2.4.2  (I think it should to be 2.6.0 as I download lazarus-0.9.30.4-fpc-2.6.0-win32.exe) SVN 35940 It is possible indeed that you have different versions mixed. It can cause the SIGSEGV. Try to delete everything, including config files, and install again. Make a clean install of FPC 2.6.0 before you start compiling FPC yourself. Actually for you I would recommend either Lazarus trunk or the new fixes branch leading to Lazarus 1.0.   http://wiki.lazarus.freepascal.org/Lazarus_1.0_fixes_branch You need all the latest developments when porting Delphi code. Juha ---------------------------------------------------------------------- micheus · 2012-04-16 18:04 Quote from: Martin_fr on April 16, 2012, 07:40:05 pmDon't specify -ghI didn't this by my self; and by checking in the project's Compiler Options the "Use Heaptrc Unit  (-gh)" isn't checked (neither for MDO package). I had left everything with default settings. QuoteYou need -g  (or -gw if you use dwarf)-g option was set as I told in the first post. QuoteIf your unit is part of the RTL or fpc packages (as maskutils is) then you must rebuild fpc itself. This is not something you can do from inside lazarus. Search for "fpc buildfaq" http://wiki.lazarus.freepascal.org/buildfaqThanks. I didn't know about this. QuoteYou do need an released version installed. And in the path. (make sure make, is the fpc/gnu make, and not pointing to Delphi's make). make.exe clean  make.exe all  OPT="-g -O-1"  make.exe install  INSTALL_PREFIX=c:\FPC\  Don't forget to create/adapt fpc.cfgWill this explains the wrong FPC version? I will try this soon and come back here tomorrow. (I have no more time to chekc this today) Thanks ---------------------------------------------------------------------- Pascaluvr · 2012-04-16 19:07 "Lazarus v0.9.30.4 FPC 2.4.2  (I think it should to be 2.6.0 as I download lazarus-0.9.30.4-fpc-2.6.0-win32.exe) SVN 35940" When you upgraded Lazarus with the 2.6.0 version you will find that while 2.60 is installed Lazarus is still pointing to the 2.4.2 directory.  (I had the same problem and was confused too) - simply make sure Lazarus is pointing to the correct FPC directory. ---------------------------------------------------------------------- micheus · 2012-04-17 17:54 Nothing is so bad that could not become worse...  Quote from: JuhaManninen on April 16, 2012, 07:59:37 pmIt is possible indeed that you have different versions mixed. It can cause the SIGSEGV. Try to delete everything, including config files, and install again. Make a clean install of FPC 2.6.0 before you start compiling FPC yourself.I checked and there were two fpc folders under Lazarus directory (2.4.2 and 2.6.0). I was assuming that only one should to exists after each new install (update). So, I uninstalled Lazarus; did a register cleanup by using CCleaner; I clear some remainder files under Lazarus directory and I did a new install of 2.6.0. Now, when I start Lazarus I'm getting a Access Violation dialog and I need to cancel - so, I can't load Lazarus anymore. I tried to install back the old one (lazarus-0.9.30-fpc-2.4.2-win32.exe), but no success. As a last option I executed these commands to rebuild Lazarus: Quote from: Martin_fr on April 16, 2012, 07:40:05 pmYou do need an released version installed. And in the path. (make sure make, is the fpc/gnu make, and not pointing to Delphi's make). make.exe clean  make.exe all  OPT="-g -O-1"  make.exe install  INSTALL_PREFIX=C:\Freeware\Lazarus\fpc\ Is there any other place I need to proced a cleanup in order to get Lazarus working again? /Micheus ---------------------------------------------------------------------- Martin_fr · 2012-04-17 20:16 The "make.exe" was about FPC not lazarus. (though there are Makefiles for Lazarus too) To clean all old stuff away: - There are no registry entries - There is (vista / may differ on other win)   C:\Users\USERNAME\AppData\Local\lazarus - There is   C:\lazarus   or wherever you did your install to Delete the 2 folders, and remove desktop/startup-menu shortcuts. Then install   Lazarus fixes + fpc 2.6.0 :   Lazarus-0.9.31-36###-fpc-2.6.0-201204##-win32.exe from snapshots (this is preparation for the next release. So currently this is good quality) --- If you want/need more than one install, then search for --primary- config-path Before trying to debug into the RTL/fpc-packages: post an example of the failing code. Maybe someone can tell. as for debugging the LCL and Lazarus components: you can open them in the packages menu, add debug options there, and recompile package by package (no need to rebuild the entire IDE) --- As for heap trc: There *was* (I believe it got fixed) a package, that included this, and forced it on the entire build.... ---------------------------------------------------------------------- micheus · 2012-04-18 22:12 Quote from: Martin_fr on April 17, 2012, 10:16:52 pmThe "make.exe" was about FPC not lazarus. (though there are Makefiles for Lazarus too)I used as a last option since I was not able to start the IDE. QuoteC:\Users\USERNAME\AppData\Local\lazarusThis one! I forgot to check the user folder. Thanks. QuoteThen install Lazarus fixes + fpc 2.6.0I tried Lazarus-0.9.31-36892-fpc-2.6.0-20120418-win32.exe, but I was not able to compile RXNew component pack (my project uses it): Msg=C:\Freeware\lazarus\components\rxfpc\rxctrls.pas(3356,5) Error: Wrong number of parameters specified for call to "Frame3D" QuoteIf you want/need more than one install, then search for --primary-config-pathI don't. I just moved to 2.6.0 due that problem with FormatMaskText. Back to the original problem... QuoteBefore trying to debug into the RTL/fpc-packages: post an example of the failing code. Maybe someone can tell.Take a look at this video (1m19s). You will see there is nothing easy to verify - The first action works fine and in a second one none (whithout leave the program) So, I think I realy need to debug it, despite I don't know way if the same code was working before in Delphi. Quoteas for debugging the LCL and Lazarus components: you can open them in the packages menu, add debug options there, and recompile package by package (no need to rebuild the entire IDE)Should I do this by marking  "Generate debuggin info for GDB (slows compiling) (-g)" in the MDO package options? I already did this and as you can see in the video I cannot enter in the MDO source code. Thanks for your attention Micheus ---------------------------------------------------------------------- Martin_fr · 2012-04-19 02:03 Once you got a SigSegV it is impossible to continue debugging. http://sourceware.org/bugzilla/show_bug.cgi?id=10004 But that does not need to concern you. I should also mention: I know the debugger well, very well. But I do not know the database components. So my help goes about how to debug only. ---- About adding debug info. You will notice the blue dots on the left hand (only while running): - If they are there, then there is debug info - If they are not, then there is not. QuoteShould I do this by marking  "Generate debuggin info for GDB (slows compiling) (-g)" in the MDO package options? I already did this and as you can see in the video I cannot enter in the MDO source code. Assuming MDO comes as full source. - Yes you should enable the  "Generate debuggin info for GDB (slows compiling) (-g)" - And you should make sure to set or unset "dwarf" the same way as in your project. - Switch optimization to -O1 - And you must "recompile clean" the package. The last tool button "More" drops down a menu, with that option. - Then also make sure you do a "Build all" (in the run menu) for your project. ---- When you hit the breakpoint, try stepping (F7 - Step into) instead of hitting run. That way you will see, if it steps into the package. It is better to confirm that before the error happens. If you can not step into it, then stop here, and report back. See if codetools can jump to the source (find declaration), and see which unit and which path the code is in. ---- One thing that seemed odd, is that the assembler window, did not show any assembler.... So whatever happened with the SigSegV, it might have gone very bad... When the error happens, definitely check out the stack window (Menu: View > Debug window) The stack has "copy to clipboard" so you can post a copy here. You may also want to open the "debug output" window (do open it, before you start your app), and copy the content (once the error happened and you viewed the stack) ---- If there are threads involved (that can happen, even without your code using threads) then there is a problem. The IDE only supports thread debugging in the snapshots. With the 0.9.30.x you can only view one thread, and you can not choose which one. If so, start another topic on the forum, maybe some one knows how to get RX running... Though the problem does not have to be threads. The SigSegV may have corrupted the stack. Then the debugger can not find where the error happens. Or it is in a dll or the kernel, and the stack format is not what the debugger expects .... In that case its a long way. Single step through the code, until you find the line where it happens. Then do it over again, but "step into" on that line, and single step the method that was called, until you hit the error again. Repeat and repeat again. Each time one level down --- I hope that some of it will help ---------------------------------------------------------------------- ludob · 2012-04-19 07:30 Quote from: micheus on April 19, 2012, 12:12:46 amQuoteThen install Lazarus fixes + fpc 2.6.0I tried Lazarus-0.9.31-36892-fpc-2.6.0-20120418-win32.exe, but I was not able to compile RXNew component pack (my project uses it): Msg=C:\Freeware\lazarus\components\rxfpc\rxctrls.pas(3356,5) Error: Wrong number of parameters specified for call to "Frame3D" Download rx from Lazarus ccr. https://lazarus- ccr.svn.sourceforge.net/svnroot/lazarus-ccr/components/rx/ and http://wiki.lazarus.freepascal.org/Using_the_Lazarus- ccr_SVN_repository. That problem has been solved already. ---------------------------------------------------------------------- ludob · 2012-04-19 08:53 Don't know if this is the cause of your SIGSEGV but I found a problem in TMDOCustomDataSet.Destroy where the dataset isn't closed before being destroyed. The result is that the inherited destroy (tdataset) calls again TMDOCustomDataSet.InternalClose while FBlobStreamList is already freed -> SIGSEGV. This problem is solved by adding the following line to TMDOCustomDataSet.Destroy: Code: [Select]destructor TMDOCustomDataSet.Destroy; begin   if FFBLoaded then   begin     if Active then Close;   // ADD THIS LINE     FreeAndNil(FDataLink); ---------------------------------------------------------------------- micheus · 2012-04-19 09:13 Quote from: Martin_fr on April 19, 2012, 04:03:33 amI should also mention: I know the debugger well, very well. (...) So my help goes about how to debug only.It's all that I need.  I will answer you as soon as I try what you suggest me. Quote from: ludob on April 19, 2012, 10:53:10 amDon't know if this is the cause of your SIGSEGV but I found a problem in TMDOCustomDataSet.Destroy where the dataset isn't closed before being destroyed.ludob, thanks for suggesting this fix. Anyway, it cannot be applied in this initial report I did because I didn't destroy it. In that form where the problem appears, I just open and close it - the datamodule is used by the form that called it (that with the dbgrid). Just making a mention, I opted for use lazarus-0.9.30.2-fpc-2.4.4-win32.exe ---------------------------------------------------------------------- BigChimp · 2012-04-19 10:32 Quote from: micheus on April 19, 2012, 11:13:42 amJust making a mention, I opted for use lazarus-0.9.30.2-fpc-2.4.4-win32.exe Obligatory upgrade reference: e.g. 0.9.30.4 with FPC 2.6: http://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%2 0bits/Lazarus%200.9.30.4/lazarus-0.9.30.4-fpc-2.6.0-win32.exe/download Regards, BigChimp *) who knows, perhaps there've been fixes meanwhile... Mmm... didn't read the entire thread again. I'd still try installing FPC 2.6+Lazarus 0.9.30.4 in a different directory and try to fix your compilation problems with that version. Otherwise you keep running into bugs that have already been fixed and you can spend your time backporting fixes... ---------------------------------------------------------------------- ludob · 2012-04-19 11:24 Quote from: micheus on April 19, 2012, 11:13:42 amAnyway, it cannot be applied in this initial report I did because I didn't destroy it. In that form where the problem appears, I just open and close it - the datamodule is used by the form that called it (that with the dbgrid). Then it would be useful to give some more details what you are actually doing since opening, closing and reopening MDODatasets is working nicely here. I'm using MDO from svn : https://mdo.svn.sourceforge.net/svnroot/mdo on fpc 2.7.1 and lazarus 1.1.  In the video I noticed you are using parameters. Perhaps this fix applies to your situation: QuoteRevision: 13 Author: korba812 Date: 23:35:51, vendredi 14 janvier 2011 Message: Fixed: Crash when SQL at MDOQuery contains parameters (ID: 3156354) ---------------------------------------------------------------------- micheus · 2012-04-20 22:03 Quote from: Martin_fr on April 19, 2012, 04:03:33 amAbout adding debug info. You will notice the blue dots on the left hand (only while running): - If they are there, then there is debug info - If they are not, then there is not.Exactly as in Delphi - I do know how to debug in Delphi. QuoteAssuming MDO comes as full source. - Yes you should enable the  "Generate debuggin info for GDB (slows compiling) (-g)" - And you should make sure to set or unset "dwarf" the same way as in your project. (I set it On) - Switch optimization to -O1 - And you must "recompile clean" the package. The last tool button "More" drops down a menu, with that option. - Then also make sure you do a "Build all" (in the run menu) for your project.I didn't verify these red ones before. I did what you said and now I was able to debug a little more deep into MDO - great.  QuoteWhen the error happens, definitely check out the stack window (Menu: View > Debug window)Ok. I also used to use Stack and Watches windows in Delphi. Also I used to explore the break-points conditionals, but it seems that Lazarus still don't offer us it with support to expressions. Is it? I tried: self.FNAME = 'QryCidade' and I got a crach. Despite the error occurs in that line with DstTitular.Open, now I was able to verify that the error comes from another dataset that is being (automaticly) opened: QryCidade. This should be happening because this last dataset is one of many others used in LookupLists dataset of DBLookup components. I'm opening these lookup datasets in OnShow event - that occurs after I have positioned the main dataset record and I call ShowModal. Call Stack before crash and Call Stack after crash This way, I'll need to go a little more deep in the dataset class, but I don't still got the debug information for db.pas file. So, I tried build Lazarus:  1) in the console, I used those Make orientations you (Martin_fr) had explained before; I had made these changes below to fpc.cfg - everything else (like paths) seems to be currect: Quote from:  Changes to fpc.cfg file # Optimizer switches for i386 compiler -O1 -Op386 # generate always debugging information for GDB (slows down the compiling process) -gc -gh -gl -gv -gwAfter everthing has been compiled, when I started Lazarus and tried to build my project I got this compiler message: SIGAA.lpr(1,1) Fatal: Can't find unit Interfaces used by SIGAA I took a look at the Lazarus directories and I find that the lcl\units\i386-win32\win32 and  lcl\units\i386-win32\nogui folders are empty and also there ara only a few files in  lcl\units\i386-win32 (four). Then I continued...  2) in the IDE, Configure Build dialog, I selected Clena Up + Build All and I marked Debug for Defines; All those absent files were generated/copied... ... and that heap error by Heaptrc is back (I had to reinstall Lazarus once again - I shouldn't really mark that Debug option).  Just to verify, all I need to do is build the FPC (using command line) with some specific options - not the LCL (the IDE build option). Is it right? I feel my neoron are dying with the age.  Thanks for any other help someone can give me. /Micheus ---------------------------------------------------------------------- Martin_fr · 2012-04-21 00:28 Quote from: micheus on April 21, 2012, 12:03:25 amAlso I used to explore the break-points conditionals, but it seems that Lazarus still don't offer us it with support to expressions. Is it? I tried: self.FNAME = 'QryCidade' and I got a crach. I do not recall, how good breakpoint properties work in 0.9.30 series. In 0.9.31 you can use all brk-point properties, including: - brk-p that enable/disable other brk-p - brk-p that do not stop, but take a snapshot of all watched values About expression in condition. Yes they are tricky. Because they are left to gdb, and gdb's pascal parser is not so great. (same expression as watch may work, because for watches the IDE does a lot of extra work). - One rule brk-p-conditions should NOT contain spaces. - Play with single/double quotes (not sure what gdb likes) - dynamic array may sometimes need data^[1] Open the "debugger output" window, then enter condition as watch, and see what IDE sends to gdb Quote This way, I'll need to go a little more deep in the dataset class, but I don't still got the debug information for db.pas file. So, I tried build Lazarus:  1) in the console, I used those Make orientations you (Martin_fr) had explained before; db.pas is NOT part of the lazarus source. it is in fpc packages.     packages\fcl-db\src\base\db.pas So you need to rebuild fpc. the make I gave you are for that. You need to cd into the fpc directory and call them there. I always only build svn checkouts. I don' know if the FPC dir in Lazarus has all the makefiles. You may have to download a copy of fpc. Quote I had made these changes below to fpc.cfg - everything else (like paths) seems to be currect: Quote from:  Changes to fpc.cfg file # Optimizer switches for i386 compiler -O1 -Op386 # generate always debugging information for GDB (slows down the compiling process) -gc -gh that "-gh" will include heaptrc You do not need -gh to compile units.  It does not affect the compilation of the unit.. It is only needed for final projects. Thet it will includu the heaptrc memory manager, and ALL code (in that executable) will use it. You might add -gt  (trash unused memory) Also note -O1 does NOT undo a -O2 if anything else use -O2. use -O-1  -O- switches off all *previous* -O. Any -O found later (e.g. command line) will still take effect. QuoteAfter everthing has been compiled, when I started Lazarus and tried to build my project I got this compiler message: SIGAA.lpr(1,1) Fatal: Can't find unit Interfaces used by SIGAA I took a look at the Lazarus directories and I find that the lcl\units\i386-win32\win32 and  lcl\units\i386-win32\nogui folders are empty and also there ara only a few files in  lcl\units\i386-win32 (four). Maybe when you used make, lazarus was build for a different widgetset? (ws=nogui). Iwouldn't know why... Anyway, it is best to always build lazarus from the Tools menu. (and keep a working lazarus.exe backup) The make is only needed for fpc. Quote Just to verify, all I need to do is build the FPC (using command line) with some specific options - not the LCL (the IDE build option). Is it right? Yes. See above. You may need to download a compilable fpc... It should have a MakeFile in the top level fpc dir. Then you need to change the Lazarus path to fpc (in options) Also the new compiled FPC, needs a fpc.cfg It has a few pitfalls, when one does it the first time. I saw -gw in the options you listed ( gw = dwarf) - stabs/dwarf are simply different encodings for the debug info I assume you selected dwarf in your projet settings too, then. You should add -godwarfsets (0.9.31 has it as option) Remind me which fpc you are using now 2.4.2 ? 2.4.4? IIRC you dropped 2.6 due to rx issues? Or was it a Lazarus unit that broke it? I'd still recommend to try updating. Maybe the rx can be downloaded from SVN? Not sure where your version is from? There is an rx in lazarus too, and one in the CCR. ---------------------------------------------------------------------- ludob · 2012-04-21 06:22 Quote from: micheus on April 21, 2012, 12:03:25 amI feel my neoron are dying with the age.  Thanks for any other help someone can give me. Well, did you try rx from the link I gave you and that solves your compiling error with 2.6.0? Did you look at the query crash with parameters fix solved in MDO from svn? Did you give us more details on what you are doing with MDO that is different from just open close reopen of a dataset that simply works? Refusing a helping hand is the quickest way of not getting any help anymore ---------------------------------------------------------------------- micheus · 2012-04-26 21:13 Sorry by the delay. I'm very busy these days - my current job has nothing to do with programming (it's secondary nowadays). Quote from: Martin_fr on April 21, 2012, 02:28:57 amRemind me which fpc you are using now 2.4.2 ? 2.4.4?lazarus-0.9.30.2-fpc-2.4.4. I'm downloading the svn sources and will try to build the entire project. Quote from: ludob on April 21, 2012, 08:22:00 amWell, did you try rx from the link I gave you and that solves your compiling error with 2.6.0?No, because as I told before (Reply #11) I'm not using that version (in the last install I did): "Just making a mention, I opted for use lazarus-0.9.30.2-fpc-2.4.4-win32.exe" Quote from: ludobDid you look at the query crash with parameters fix solved in MDO from svn?Yes. That is exactly the source I had use for install MDO package. Quote from: ludobDid you give us more details on what you are doing with MDO that is different from just open close reopen of a dataset that simply works?Just a few details. Please, pay attention to the subject of this topic. At this moment, I just want to learn how to be able to debug my code - I still could not do this. I had talked about the MDO problem as part of what I'm experiencing and why I' trying to debug some "internal" code (as I know now). After I get those "blue dots" in the db.pas source, then - probably - I'll open an new thread for talk about that specific problem. Quote from: ludobRefusing a helping hand is the quickest way of not getting any help anymore Maybe you had understood I refused your help, but this impression was caused only by the fact I'm focused in my initial question: "the right way to get debug working?". Dont' get me wrong. As you (for years), I also tried to help lot of newbies in a forum of Delph (here in Brazil) and (I think) I understand how much frustrating can be do not get a feedback - you gave your time, for what? You did not waste your time.  Thanks for the help all you gave me. /Micheus ---------------------------------------------------------------------- ludob · 2012-04-27 08:52 Quote from: micheus on April 26, 2012, 11:13:11 pmMaybe you had understood I refused your help, but this impression was caused only by the fact I'm focused in my initial question: "the right way to get debug working?". Your focusing on getting debugging working was clear from your second or third post. Martin_fr is the lazarus debugging guru and has done a great job in improving the lazarus debugging experience. So when he is on the case, I leave it in his good hands and try to help on the other issues at hand, ie. rx and MDO. But when Martin_fr insists on upgrading fpc that you downgraded because of rx, I felt it necessary to recall the fact that the rx problem is solved and should not stop you from upgrading. Quote from: micheus on April 26, 2012, 11:13:11 pmDont' get me wrong. As you (for years), I also tried to help lot of newbies in a forum of Delph (here in Brazil) and (I think) I understand how much frustrating can be do not get a feedback - you gave your time, for what? If not getting feedback was that frustrating I would have stopped helping people for years already   Helping others for the recognition or the eventual "thank you" never lasts. That is only the icing on the cake. Now that we are psychoanalyzing the forum helpers: in this case, it wasn't the not getting feedback that triggered my "refusing a helping hand" reaction but the "cherry picking" in the solutions proposed. If the debugging expert says do 1+2+3, you do 1+3, it doesn't work and then say "Thanks for any other help someone can give me." then my reaction is "what if you started with doing 2". I'm glad to see that your are upgrading fpc. ---------------------------------------------------------------------- Martin_fr · 2012-04-27 14:58 Quote from: ludob on April 27, 2012, 10:52:03 amQuote from: micheus on April 26, 2012, 11:13:11 pmMaybe you had understood I refused your help, but this impression was caused only by the fact I'm focused in my initial question: "the right way to get debug working?". But when Martin_fr insists on upgrading fpc that you downgraded because of rx, I felt it necessary to recall the fact that the rx problem is solved and should not stop you from upgrading. I would say "I suggested" rather than "insisted. (And I meant those suggestions in the context of fixing the bug, not getting the debugger work). IMHO the following applies: - To get the debugger working (include fpc units like db.pas) , using fpc 2.4.4 (and lazarus 0.9.30.2) is sufficient.  (Except on win 64 bit, where 2.4.4 may be problematic) - Upgrading (as far as debugging goes) has advantages. 0.9.31 has new features in the debugger:   ~ thread window   ~ history   ~ better evaluation of watches (e.g dynamic arrays)   ~ some bug fixes But again 0.9.30 provides a good and stable debug too. Then again, initially I would have assumed, this thread as a means to find the bug itself. Only later it got clear, that it also is an exercise to explore the "how to" debug... Quoteit wasn't the not getting feedback that triggered my "refusing a helping hand" reaction but the "cherry picking" in the solutions proposed. If the debugging expert says do 1+2+3, you do 1+3, it doesn't work and then say "Thanks for any other help someone can give me." then my reaction is "what if you started with doing 2". I think (at least I perceive it as) it wasn't so much cherry picking (about my suggestions) as misunderstanding (partly due to incomplete info on my site). It required (ongoing) several iterations on how to "rebuild fpc". I specified the "make" commands. But I did (being myself on SVN) not realize, that the fpc installed by the Lazarus installer does not have the Makefiles. This is not strictly debug related, hence not my strong site. And rebuilding FPC is something many have struggled with. ---------------------------------------------------------------------- micheus · 2012-05-02 22:06 Hello there Unfortunately I stoped at making svn fpc. I opened a new thread in the Miscellaneous->Other session: How to build the SVN version of FPC - under Windows