Locals window shows for all locals lazarus / 12-Debugger ---------------------------------------------------------------------- 440bx · 2019-05-04 15:20 Hello, For some reason, the debugger "locals" window shows " for all the function/procedure locals (using GDB as it was originally installed by the Lazarus install program).  There is nothing unusual about the functions/procedures. It didn't use to do that.  When it first happened a while back, I simply thought there was something in that particular program it didn't like and worked around it.  Now it seems to happen all the time. If I right click on any of the local variables and select "watch", that works fine.  Is there something that should be "reset"/"changed" in my Lazarus installation that would make the locals window work again ?  Ideas and suggestions, appreciated. Thank you for your help. ---------------------------------------------------------------------- Martin_fr · 2019-05-04 15:40 Just to be sure, you stepped past the "begin" line? On the begin (begin of procedure) line, this may happen. Also, you do not have optimizations enabled? Opt = 0. 64bit IDE and 64 bit project? Not related to nested procedures? Do the variables work, if you add them to the watches window? Please either provide a log http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debu g_session Or the entire output of: View > Ide Internals > Debug Output (Please make sure you do open that window before you start debugging.) Please provide a sample of the var declaration of such a method. ---------------------------------------------------------------------- 440bx · 2019-05-04 17:57 Quote from: Martin_fr on May 04, 2019, 05:40:24 pmJust to be sure, you stepped past the "begin" line? yes, definitely.  Quote from: Martin_fr on May 04, 2019, 05:40:24 pmAlso, you do not have optimizations enabled? Opt = 0. I was using the "debug" build mode which has O1.  To determine if that made a difference, I changed it to 0 and still got the for all the locals. Quote from: Martin_fr on May 04, 2019, 05:40:24 pm64bit IDE and 64 bit project? 32bit IDE producing a 32bit executable running on Win7 64bit. Quote from: Martin_fr on May 04, 2019, 05:40:24 pmNot related to nested procedures? No nested procedures anywhere in the program. Quote from: Martin_fr on May 04, 2019, 05:40:24 pmDo the variables work, if you add them to the watches window? Yes!.  I can add any of the locals that produced an and they show just fine. Quote from: Martin_fr on May 04, 2019, 05:40:24 pmPlease either provide a log http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debu g_session Attached the compressed log to this post. Quote from: Martin_fr on May 04, 2019, 05:40:24 pmOr the entire output of: View > Ide Internals > Debug Output (Please make sure you do open that window before you start debugging.) Done almost exactly as you requested.  The log is obtained from View > Debug Windows > Debug Output, which is what I believe you meant. Quote from: Martin_fr on May 04, 2019, 05:40:24 pmPlease provide a sample of the var declaration of such a 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 function WndProc (Wnd : hWnd; Msg : UINT; wParam, lParam : ptrint)         : ptrint; stdcall;  { main application/window handler function                                }const  ConhostProcesses   = 'conhost.exe process list';   ListBox       : HWND  =  0;   ID_LISTBOX            = 1000;  ID_STATWIN            = 2000;   Visible       : pchar = nil;   Bitness       : pchar = nil;   {-------------------------------------- -------------------------------------}   ListboxHeader = 'Window handle    Process Id    Thread Id    V(isible)  '   +                'Executable name';   EMPTY_STRING  : pchar = #0;   {------------------ ---------------------------------------------------------}   VisibleYes            = 'V';  VisibleNo             = ' ';   Bitness32             = '_32_';  Bitness64             = ' 64 ';  BitnessUnknown        = '    ';   ProcessList           : PProcessList = nil;  ConsoleList           : PConsoleList = nil;  ConhostList           : PConhostList = nil; var  ClientRect            : TRECT;  StatRect            : TRECT;  Style                 : ptruint;   StatWnd             : HWND;   i                     : TConsoleListRange; begin  WndProc := 0;   case Msg of    WM_CREATE:    begin      {$ifdef DEBUG}        if IsDebuggerPresent() then DebugBreak();      {$endif}       { allocate memory for the list of conhost processes                   }       ConsoleList := HeapAlloc(GetProcessHeap(),                             HEAP_ZERO_MEMORY,                             sizeof(ConsoleList^));       if ConsoleList = nil then It's not a method (I don't have any of those) just the typical WndProc that handles window messages.  A breakpoint is/was set at the statement "ConsoleList := HeapAlloc...". While preparing this for you, I noticed something that is probably very important.  The problem occurs only when the executable is 32bit.  If the executable is 64bit, the locals show just fine. Maybe the problem is in GDB and not in Lazarus but, if that is the case, what I don't understand is why it used to work. Now that I've realized the problem only occurs in 64bit, it is not that much of an issue for me since the final version is always 64bit.  I only use the 32bit target to ensure the program works in both bitnesses. ---------------------------------------------------------------------- Martin_fr · 2019-05-04 18:51 The Log is all good. Nothing that would indicate an incorrect setting in the IDE. It is beyond strange that gdb has issues getting the values as locals, but can do them as watch. Especially for basic types like HWnd (which in the end is just an int or cardinal...) It even gets the values, with the threads and stackframes (for thread and stack window), which is very similar to the local data. To me it looks like a bug in gdb. But not sure what triggers it. Between successfully getting it for stack/thread and then failing for locals, the only thing happening is getting the disassembler. Are you using dwarf or stabs? It looks like stabs (Project > Project Options > Debugging: Debug information type). I do highly recommend to use "dwarf (with sets)". Does it make a difference? (If you debug in packages, you may need to change it for each package too.) As for the issue (if dwarf does not help), I would recommend to try one of the alternative debuggers https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032% 20bits/Alternative%20GDB/ I have no test results for Win 7. On Windows 10, all tests show that 8.2 is good. (And I am planing to change to it for the next major release, i.e., 2.2.0) I would expect it to be fine on Win7 too. If you for any reason want to use "stabs", then you should go with GDB 7.7.1. It is (remotely) possible that a recent Windows update could have caused changes. For once cross debugging (Bitness of IDE and app differ) lost the ability to pause the debugged app (fixed in trunk / But that fix would not help you).  Some people reported running in compatibility mode helped them. I don't however see, how that could cause the observed inconsistency in gdb.... I also noted you do receive a strange 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 stopped,reason="signal-receivedFor which I found no reason. Maybe try DissableLoadSymbolForLibraries in the Tools > Option > Debugger But that seems otherwise unrelated to the issue I hope some of this will help ---------------------------------------------------------------------- 440bx · 2019-05-04 20:10 Quote from: Martin_fr on May 04, 2019, 08:51:17 pmI hope some of this will help Before anything, I have to say, your explanation was thorough, detailed and accurate.  You really do great work.  Thank you. Quote from: Martin_fr on May 04, 2019, 08:51:17 pmIt is beyond strange that gdb has issues getting the values as locals, but can do them as watch. Especially for basic types like HWnd (which in the end is just an int or cardinal...) It even gets the values, with the threads and stackframes (for thread and stack window), which is very similar to the local data. I agree.  I found it puzzling too. Quote from: Martin_fr on May 04, 2019, 08:51:17 pmAre you using dwarf or stabs? It looks like stabs (Project > Project Options > Debugging: Debug information type). I do highly recommend to use "dwarf (with sets)". Does it make a difference? (If you debug in packages, you may need to change it for each package too.) That was the magic question.  It was set to "automatic".  I never gave that a second thought, it seemed to work fine.  I checked the executable and it was using stabs.  I changed it to "dwarf (with sets)" and ... problem solved.  The locals are there.  That is great.    It also explains why thngs worked when compiling for a 64bit target and didn't work for a 32bit target.  As I am sure you know, when compiling for a 64bit target, the debug info is dwarf, not stabs. Quote from: Martin_fr on May 04, 2019, 08:51:17 pmAs for the issue (if dwarf does not help), I would recommend to try one of the alternative debuggers https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032% 20bits/Alternative%20GDB/ Fortunately and, thanks to you, I won't need to go that route. Quote from: Martin_fr on May 04, 2019, 08:51:17 pmIf you for any reason want to use "stabs", then you should go with GDB 7.7.1. I don't have any.  I just want to use what works.  Simplicity is good. Quote from: Martin_fr on May 04, 2019, 08:51:17 pmIt is (remotely) possible that a recent Windows update could have caused changes. I disable Windows updates.  That thing is nothing but headaches.  First thing I do in a Windows installation, ensure there will be no updates.  I wish I could do that with VS2017, another source of headaches. Quote from: Martin_fr on May 04, 2019, 08:51:17 pmI also noted you do receive a strange 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 stopped,reason="signal-receivedFor which I found no reason. This is a guess but, it may be because I have conditional calls to DebugBreak() sprinkled in the code.  I'm guessing GDB considers that a signal. The problem is solved.  Thank again Martin.  Very nicely done.