Recent

Author Topic: Debugging bug in Lazarus 2.0  (Read 3698 times)

Peter H

  • Sr. Member
  • ****
  • Posts: 272
Debugging bug in Lazarus 2.0
« on: March 23, 2019, 07:32:58 am »
Code: Pascal  [Select][+][-]
  1. i := 0;
  2. while i < 10 do begin
  3.   i := i + 1;
  4. end;
  5.  

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

  • Hero Member
  • *****
  • Posts: 2223
Re: Debugging bug in Lazarus 2.0
« Reply #1 on: March 23, 2019, 11:24:38 am »
Confirm. This is due to the fact that for cycle efficiency is written as
Code: Pascal  [Select][+][-]
  1. i := 0;
  2. goto EndOfLoop; // The breakpoint is set here
  3. repeat
  4.   i := i + 1;
  5.   EndOfLoop:
  6. until i >= 10; // Not here

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging bug in Lazarus 2.0
« Reply #2 on: March 23, 2019, 03:24:49 pm »
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

  • Sr. Member
  • ****
  • Posts: 272
Re: Debugging bug in Lazarus 2.0
« Reply #3 on: March 24, 2019, 07:33:34 pm »
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

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging bug in Lazarus 2.0
« Reply #4 on: March 24, 2019, 07:52:47 pm »
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.
Getting a stacktrace (with unit names and line numbers) and/or a reproducible example would be good.

Quote
There 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

  • Sr. Member
  • ****
  • Posts: 272
Re: Debugging bug in Lazarus 2.0
« Reply #5 on: March 24, 2019, 08:08:50 pm »
Stacktrace:
Code: Pascal  [Select][+][-]
  1. #0 ?? at :0
  2. #1 SYSTEM_$$_INITTHREAD$LONGWORD at :0
  3. #2 SYSINITPAS_$$_EXEC_TLS_CALLBACK$POINTER$LONGWORD$POINTER at :0
  4. #3 ntdll!RtlCheckTokenCapability at :0
  5. #4 ntdll!RtlHashUnicodeString at :0
  6. #5 ntdll!RtlEnterCriticalSection at :0
  7. #6 ntdll!RtlHashUnicodeString at :0
  8. #7 ntdll!LdrInitializeThunk at :0
  9. #8 ntdll!LdrInitializeThunk at :0
  10. #9 ?? at :0
  11.  

Project (Windows, 64 Bit)
Code: Pascal  [Select][+][-]
  1. program project1;
  2. var
  3.  
  4.   i,j:integer;
  5.  
  6. begin
  7.  
  8. i :=0;
  9.  
  10. while i < 10 do begin //BP
  11.   i := i + 1;                 //BP
  12. end;
  13.  
  14. for j := 0 to 10 do begin  //BP
  15.   i:= i-1;
  16. end;
  17.  
  18. end.
  19.  

"//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.)

« Last Edit: March 24, 2019, 09:24:04 pm by Peter H »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging bug in Lazarus 2.0
« Reply #6 on: March 24, 2019, 09:29:52 pm »
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

  • Sr. Member
  • ****
  • Posts: 272
Re: Debugging bug in Lazarus 2.0
« Reply #7 on: March 24, 2019, 09:46:30 pm »
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?
Yes and Yes.

Quote
You 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

  • Sr. Member
  • ****
  • Posts: 272
Re: Debugging bug in Lazarus 2.0
« Reply #8 on: March 25, 2019, 08:56:53 am »
I have seen another more serious related problem, this time on another computer, running Win7 32 Bit and Lazarus 2.0.

Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. var
  4.   i,j:integer;
  5.  
  6. begin
  7.   i := 0;
  8.   j := 0; //Set breakpoint here
  9.   while i < 10 do begin
  10.     i += 1;
  11.   end;
  12.  
  13.   while j < 10 do begin
  14.     j += 1;
  15.   end;
  16. end.
  17.  

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.
« Last Edit: March 25, 2019, 09:01:42 am by Peter H »

CCRDude

  • Hero Member
  • *****
  • Posts: 596
Re: Debugging bug in Lazarus 2.0
« Reply #9 on: March 25, 2019, 12:45:34 pm »
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

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging bug in Lazarus 2.0
« Reply #10 on: March 26, 2019, 05:48:30 pm »
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).
« Last Edit: March 26, 2019, 05:51:03 pm by Martin_fr »

Peter H

  • Sr. Member
  • ****
  • Posts: 272
Re: Debugging bug in Lazarus 2.0
« Reply #11 on: March 26, 2019, 07:50:39 pm »
Huge improvement.
Thank you again!

 

TinyPortal © 2005-2018