Debugging bug in Lazarus 2.0 lazarus / 12-Debugger ---------------------------------------------------------------------- Peter H · 2019-03-23 06:32 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 i := 0;while i < 10 do begin  i := i + 1;end;  Hi, If I set a breakpoint in front of the while statement, then the BP is only hit once. The problem happens also with for loops, is independent from optimization and it happens reproducibly in 32 Bit and 64 bit on Windows 10 and 7. It happens in Lazarus 2.0 (Release version) and also in Codetyphon. It happens with GDB and does not happen with FPdebug. ---------------------------------------------------------------------- ASerge · 2019-03-23 10:24 Confirm. This is due to the fact that for cycle efficiency is written as 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 i := 0;goto EndOfLoop; // The breakpoint is set hererepeat  i := i + 1;  EndOfLoop:until i >= 10; // Not here ---------------------------------------------------------------------- Martin_fr · 2019-03-23 14:24 This is probably not fix-able, unless fpc generates different code or adjusts debug info.... FpDebug is currently over-doing breakpoints. There are some cases (I do not remember exactly) in which it stops 3 times on one line (using F9). So FpDebug needs to be "fixed" and then may behave like gdb too. (but that is not certain yet) ---------------------------------------------------------------------- Peter H · 2019-03-24 18:33 Thank you. This can be worked around , if known. I have also found, with Lazarus 2.0, I get an external SIGSEV, when I run a simple commandline test-program that has only two loops and some breakpoints set. This apparently goes away, if the On/Off button in the assembler tab is switched off, the debugger is reset and  and the assembler tab is closed. I have seen similar with GDB and Codetyphon and Newpascal, but more problems there. There seems to be a problem with assembler debugging in Lazarus (which I dont need normally) Is it possible to disable the disassembly completely? ---------------------------------------------------------------------- Martin_fr · 2019-03-24 18:52 Quote from: Peter H on March 24, 2019, 07:33:34 pmI have also found, with Lazarus 2.0, I get an external SIGSEV, when I run a simple commandline test-program that has only two loops and some breakpoints set. Getting a stacktrace (with unit names and line numbers) and/or a reproducible example would be good. QuoteThere seems to be a problem with assembler debugging in Lazarus (which I dont need normally) Is it possible to disable the disassembly completely? Unfortunately not. But you can leave it open, and switch the power button off. That needs to be done once you start Lazarus, and then should last until you restart the IDE. ---------------------------------------------------------------------- Peter H · 2019-03-24 19:08 Stacktrace: 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 #0 ?? at :0#1 SYSTEM_$$_INITTHREAD$LONGWORD at :0#2 SYSINITPAS_$$_EXEC_TLS_CALLBACK$POINTER$LONGWORD$POINTER at :0#3 ntdll!RtlCheckTokenCapability at :0#4 ntdll!RtlHashUnicodeString at :0#5 ntdll!RtlEnterCriticalSection at :0#6 ntdll!RtlHashUnicodeString at :0#7 ntdll!LdrInitializeThunk at :0#8 ntdll!LdrInitializeThunk at :0#9 ?? at :0  Project (Windows, 64 Bit) 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 program project1;var   i,j:integer; begin i :=0; while i < 10 do begin //BP  i := i + 1;                 //BPend; for j := 0 to 10 do begin  //BP  i:= i-1;end; end.  "//BP" means there was a breakpoint set I do not know, if it is always reproducible, but here "external SIGSEV" happens each time, when the assembly button is "ON" and after starting the program. It still happens after I disable the breakpoints. When  I reset the debugger it does not happen, even with power button and breakpoints "ON". It does not happen with power button off, regardless of breakpoints. In this case the breakpoints work normally, with the above mentioned caveat. So I think, there is a problem with assembly code and breakpoints. (The problem is amplified in Codetyphon, because the assembly window there pops up automatically. Fortunately I have not seen this in Lazarus.) ---------------------------------------------------------------------- Martin_fr · 2019-03-24 20:29 I cant reproduce it right now. But it reminds me of an issue, I once had. Lets first clarify some assumptions: 1) this crash happens in your app? 2) It happens right when you start the app, press F9? If so: - The IDE debugger uses an internal breakpoint, right at the entry of the app. This is needed (or maybe was, with older gdb) to correctly initialize some stuff. - Windows, upon hitting a breakpoint creates a thread in the debugged app - The RTL reacts to the creation of the thread. And here is the problem, the rtl in INITTHREAD, does some stuff for STDOUT. For that it needs the widestring manager. But the thread is created, before the main thread had a chance to init the widestring manager. And hence INITTHREAD crashes. If that is what happens in your case: You can go to the debugger options (Tools > Options). In the property grid find the option "InternalStartBreak". Change its value gdsbMain should be good. In the rare case that your app loads a library that also exports a main symbol, this may cause issues (again may also depend on the gdb version). You would notice such problems as breakpoints - that were set before you pressed run - would not work. If they do, then all is fine. ---------------- If your issue is different, it will require a deeper look. ---------------------------------------------------------------------- Peter H · 2019-03-24 20:46 Quote from: Martin_fr on March 24, 2019, 09:29:52 pmI cant reproduce it right now. But it reminds me of an issue, I once had. Lets first clarify some assumptions: 1) this crash happens in your app? 2) It happens right when you start the app, press F9? Yes and Yes. QuoteYou can go to the debugger options (Tools > Options). In the property grid find the option "InternalStartBreak". Change its value gdsbMain should be good. Apparently this solved the problem in this case. Thank you very much for the explanation! ---------------------------------------------------------------------- Peter H · 2019-03-25 07:56 I have seen another more serious related problem, this time on another computer, running Win7 32 Bit and Lazarus 2.0. 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 program Project1; var  i,j:integer; begin  i := 0;  j := 0; //Set breakpoint here  while i < 10 do begin    i += 1;  end;   while j < 10 do begin  j += 1;  end;end.  The debugger doesnt step into (F7) these while loops, it steps over. i and j are incremented, so the loops are executed. Only if there is a breakpoint set in the body of the loop it will step into the loop. ---------------------------------------------------------------------- CCRDude · 2019-03-25 11:45 These loops get optimized even with "no optimization" set it seems. Add a WriteLn(i) or j -= i into the loop (or use i otherwise) and debugger will step into them. ---------------------------------------------------------------------- Martin_fr · 2019-03-26 16:48 The issues only exists with stabs. Fpc - for whatever odd reason - still generates stabs as default (for 32 bits). Even though dwarf gives usually better results. In project options, debugging, set "type of debug info" to "dwarf with sets". And save that as default for all future projects. ---------- On 64 bits, you may want to go to Tools > Options > Debugger and enable (in the property grid) "FixIncorrectStepOver". Gdb has an issue and sometimes steps into a function, where it should step over (F8). ---------------------------------------------------------------------- Peter H · 2019-03-26 18:50 Huge improvement. Thank you again!