Re: [Lazarus] Need testers for the a new debugger
On Sat, 22 Nov 2014 02:33:45 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 21 Nov 2014 23:51:13 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 21 Nov 2014 16:31:26 +0100 Reimar Grabowski reimg...@web.de wrote: [...] Create new project - run - stop - AV. The Assembler window initialized only if it was not docked. I fixed that. The AV is gone. Then I got an AV when closing the IDE. The destructor didn't clean up the queued async calls. I fixed that. Without the AVs you can see the mem leaks. I fixed the three mem leaks. That does not fix the AV with the internal debugger for me but GDB is running much better now and the assembler window is working. R. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Thu, 4 Dec 2014 15:56:14 +0100 Reimar Grabowski reimg...@web.de wrote: On Sat, 22 Nov 2014 02:33:45 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 21 Nov 2014 23:51:13 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 21 Nov 2014 16:31:26 +0100 Reimar Grabowski reimg...@web.de wrote: [...] Create new project - run - stop - AV. The Assembler window initialized only if it was not docked. I fixed that. The AV is gone. Then I got an AV when closing the IDE. The destructor didn't clean up the queued async calls. I fixed that. Without the AVs you can see the mem leaks. I fixed the three mem leaks. That does not fix the AV with the internal debugger for me but GDB is running much better now and the assembler window is working. Check if you have enabled 'Reset debugger after each run'. That crashes the new debugger. Disable it. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 11/25/2014 07:50 PM, Mattias Gaertner wrote: On Mon, 24 Nov 2014 11:48:38 +0100 Joost van der Sluis jo...@cnoc.nl wrote: On 11/22/2014 12:18 AM, Mattias Gaertner wrote: On Fri, 21 Nov 2014 23:08:00 + Martin Frb laza...@mfriebe.de wrote: [...] So as far as the debugger goes, this would then be correctly following the debug info. Funny fpc. Thanks for checking. BTW, the default TGDBMIDebugger jumps even worse. Begin, End, Begin, i:=3. So the new debugger is better here. :-) Yet another thing the new debugger is better at. Btw: It could be that this problem is fixed in fpc-trunk. If not I have to look at it. There's also the NextOnlyStopOnStartLine debugger-specific-option. You can try if that fixes your problem. This is enabled by default. If I disable it I get the same as with the TGDBMIDebugger. BTW, Step into does not work with FPC 2.7.1. More likely is that you've encountered one of the situations where Step into does not work. Normally it works? Joost. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Fri, 28 Nov 2014 12:37:42 +0100 Joost van der Sluis jo...@cnoc.nl wrote: [...] BTW, Step into does not work with FPC 2.7.1. More likely is that you've encountered one of the situations where Step into does not work. Normally it works? You are right. Sorry for the false alarm. I will report, when I come back to that project. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 11/22/2014 12:45 PM, C Western wrote: I have been switching back and forth between gdb and the new one - both have some issues. The one I noticed most recently with the new one is with a multi threaded application - a break set in the thread seem to cause the debugger to become lost. Is the debugger set up to cope in this situation? (I will often turn off the multi threading for debugging, but this is not always possible.) I did not do anything threading-related. So I'm not surprised that it does not really work. Can you create a bug report for this? And the OS you were using? Regards, Joost. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 11/22/2014 12:18 AM, Mattias Gaertner wrote: On Fri, 21 Nov 2014 23:08:00 + Martin Frb laza...@mfriebe.de wrote: [...] So as far as the debugger goes, this would then be correctly following the debug info. Funny fpc. Thanks for checking. BTW, the default TGDBMIDebugger jumps even worse. Begin, End, Begin, i:=3. So the new debugger is better here. :-) Yet another thing the new debugger is better at. Btw: It could be that this problem is fixed in fpc-trunk. If not I have to look at it. There's also the NextOnlyStopOnStartLine debugger-specific-option. You can try if that fixes your problem. Regards, Joost. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 24/11/14 10:46, Joost van der Sluis wrote: On 11/22/2014 12:45 PM, C Western wrote: I have been switching back and forth between gdb and the new one - both have some issues. The one I noticed most recently with the new one is with a multi threaded application - a break set in the thread seem to cause the debugger to become lost. Is the debugger set up to cope in this situation? (I will often turn off the multi threading for debugging, but this is not always possible.) I did not do anything threading-related. So I'm not surprised that it does not really work. Can you create a bug report for this? And the OS you were using? The OS was linux - x86_64 I just tried on lazarus/examples/multithreading/multithreadingexample1.lpi Setting a break point on line 100 (in the thread routine) seems to lead to immediate disaster. Colin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Sat, 22 Nov 2014 03:14:39 -0300 Flávio Etrusco flavio.etru...@gmail.com wrote: On Fri, Nov 21, 2014 at 10:33 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 21 Nov 2014 23:51:13 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: (...) Without the AVs you can see the mem leaks. I fixed the three mem leaks. Here's a patch to change the Append method, just in case ;-) That is a design decision. That is up to Joost and Martin to decide. You may want to create a bug report. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
Why do you want to pass the record instead of the pointer? The pointer is valid during the entire call (inside Append). Append does not store the pointer, but a copy of the data. So this is save. Passing the pointer saves the need to pass the entire record by value (or in other word, to make a mem copy (or registers) of the entire record) when passing to the function. Which would meant that the data would be copied twice, as it is once copied in inside the Append function anyway. The param could be const/constref instead of pointer. But as the argument is already pointer, why? Please mail how to get the mem leak, and why this fixes it. On 22/11/2014 06:14, Flávio Etrusco wrote: On Fri, Nov 21, 2014 at 10:33 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 21 Nov 2014 23:51:13 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: (...) Without the AVs you can see the mem leaks. I fixed the three mem leaks. Here's a patch to change the Append method, just in case ;-) Best regards, Flávio -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Sat, 22 Nov 2014 11:27:30 + Martin Frb laza...@mfriebe.de wrote: Why do you want to pass the record instead of the pointer? [...] The param could be const/constref instead of pointer. The patch passes the parameter as const. But as the argument is already pointer, why? Someone may be too lazy to read Append and think Append stores the pointer instead of copying the content. There was such a case in the code, creating a mem leak. I fixed that yesterday. With a const record parameter this could not happen. Psychology. ;) Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 22/11/2014 01:33, Mattias Gaertner wrote: On Fri, 21 Nov 2014 23:51:13 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 21 Nov 2014 16:31:26 +0100 Reimar Grabowski reimg...@web.de wrote: [...] Create new project - run - stop - AV. The Assembler window initialized only if it was not docked. I fixed that. The AV is gone. Then I got an AV when closing the IDE. The destructor didn't clean up the queued async calls. I fixed that. Without the AVs you can see the mem leaks. I fixed the three mem leaks. I have no idea what the code is doing. Hopefully I didn't break anything. Look ok to me. In fact I had seen a mem leak in the disassembler before, but never been able to reproduce (or find). Might have been the one fixed in Revision: 46954 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
I have been switching back and forth between gdb and the new one - both have some issues. The one I noticed most recently with the new one is with a multi threaded application - a break set in the thread seem to cause the debugger to become lost. Is the debugger set up to cope in this situation? (I will often turn off the multi threading for debugging, but this is not always possible.) Colin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
I've seen this for try...finally blocks when I implemented the initial debugger. It was to do with line info generated for these bloks Marc Original Message From:Mattias Gaertner nc-gaert...@netcologne.de Sent:Fri, 21 Nov 2014 16:23:54 +0100 To:lazarus@lists.lazarus.freepascal.org Subject:Re: [Lazarus] Need testers for the a new debugger On Fri, 21 Nov 2014 15:12:48 + Martin Frb laza...@mfriebe.de wrote: On 21/11/2014 14:03, Mattias Gaertner wrote: On Mon, 14 Jul 2014 23:13:14 +0200 Joost van der Sluis jo...@cnoc.nl wrote: [...] The debugger has been improved a lot and I could need some help testing the thing. On single stepping the debugger always jumps into a proc, then to the end of the proc and then to the first line. Actually it does not do it for every procedure. Maybe only for those with implicit try..finally. Bug or design? Without looking at it, I have seen that with gdb too, though only for certain complier help procs (iirc chek object stuff) Can you reproduce it? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Mon, 14 Jul 2014 23:13:14 +0200 Joost van der Sluis jo...@cnoc.nl wrote: [...] The debugger has been improved a lot and I could need some help testing the thing. On single stepping the debugger always jumps into a proc, then to the end of the proc and then to the first line. Bug or design? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 21/11/2014 14:03, Mattias Gaertner wrote: On Mon, 14 Jul 2014 23:13:14 +0200 Joost van der Sluis jo...@cnoc.nl wrote: [...] The debugger has been improved a lot and I could need some help testing the thing. On single stepping the debugger always jumps into a proc, then to the end of the proc and then to the first line. Bug or design? Without looking at it, I have seen that with gdb too, though only for certain complier help procs (iirc chek object stuff) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Fri, 21 Nov 2014 15:12:48 + Martin Frb laza...@mfriebe.de wrote: On 21/11/2014 14:03, Mattias Gaertner wrote: On Mon, 14 Jul 2014 23:13:14 +0200 Joost van der Sluis jo...@cnoc.nl wrote: [...] The debugger has been improved a lot and I could need some help testing the thing. On single stepping the debugger always jumps into a proc, then to the end of the proc and then to the first line. Actually it does not do it for every procedure. Maybe only for those with implicit try..finally. Bug or design? Without looking at it, I have seen that with gdb too, though only for certain complier help procs (iirc chek object stuff) Can you reproduce it? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Mon, 14 Jul 2014 23:13:14 +0200 Joost van der Sluis jo...@cnoc.nl wrote: Hi, To install the debugger just install the components/lazdebuggers/lazdebuggerfp.lpk package. After you've done this, go to tools-options-debugger and select the 'FpDebug internal Dwarf-debugger'. You forgot to mention what to place into the executable edit below, because Lazarus does not like it when you leave it empty. So I just tried with 'gdb' and that works, but 'gimp', 'eclipse' or any other executable in the path works as well. So the internal debugger does not use the value of this edit but I have to put something there so that on the next start Lazarus doesn't open its config window before starting to tell me that there is no debugger specified. Since I don't want to confuse myself I am not inclined to put 'gdb' there. So my debugger executable now is 'gcc', which is IMHO a little strange. Onto the real problem. Starting and Stopping a program leads to an AV, always, any program. Create new project - run - stop - AV. So I get AVs for just saving while my program is running (I use ctrl+s as a shortcut for quick compile, just an eclipse habit (build on save) to get rid of error markers). Unfortunately there is not much more info I can give you: TMainIDE.DoInitProjectRun ProgramFilename=/tmp/project1 [TMainIDE.DoRunProject] Debugger=TFpDebugDebugger [TMainIDE.DoRunProject] END Got PID: 23353, TID: -1 TApplication.HandleException Access violation Stack trace: $ more useless stack trace text... Ubuntu 14.04 64bit Lazarus rev 46936 FPC 2.7.1 rev 28946 R. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 21/11/2014 15:23, Mattias Gaertner wrote: Without looking at it, I have seen that with gdb too, though only for certain complier help procs (iirc chek object stuff) Can you reproduce it? Actually no, I cant. But I have the RTL with debug info. If you dont then stepping needs to step over those. Yet, afaik it actually steps through them, because they may call step-able code (e.g. helper for interface). Not sure what happens when you have no debug info on RTL. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Fri, 21 Nov 2014 15:55:17 + Martin Frb laza...@mfriebe.de wrote: On 21/11/2014 15:23, Mattias Gaertner wrote: Without looking at it, I have seen that with gdb too, though only for certain complier help procs (iirc chek object stuff) Can you reproduce it? Actually no, I cant. But I have the RTL with debug info. I don't. I have standard fpc. If you dont then stepping needs to step over those. Yes, of course. But I see it for example with any constructor. Even as simple as this: type TMyClass = class public i: Integer; constructor Create; end; constructor TMyClass.Create; begin i:=3; end; procedure TForm1.FormCreate(Sender: TObject); var c: TMyClass; begin c:=TMyClass.Create; // - breakpoint end' Run, Step into, cursor moves to 'begin' of the constructor. Step into, cursor moves to 'end' of the constructor. Step into, cursor moves to 'i:=3'. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Fri, 21 Nov 2014 16:31:26 +0100 Reimar Grabowski reimg...@web.de wrote: On Mon, 14 Jul 2014 23:13:14 +0200 Joost van der Sluis jo...@cnoc.nl wrote: Hi, To install the debugger just install the components/lazdebuggers/lazdebuggerfp.lpk package. After you've done this, go to tools-options-debugger and select the 'FpDebug internal Dwarf-debugger'. You forgot to mention what to place into the executable edit below, because Lazarus does not like it when you leave it empty. So I just tried with 'gdb' and that works, but 'gimp', 'eclipse' or any other executable in the path works as well. I changed the setup code, so that an empty debugger exe invokes the setup dialog only if the default gdbmi debugger is selected. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Fri, 21 Nov 2014 16:31:26 +0100 Reimar Grabowski reimg...@web.de wrote: On Mon, 14 Jul 2014 23:13:14 +0200 Joost van der Sluis jo...@cnoc.nl wrote: [...] Onto the real problem. Starting and Stopping a program leads to an AV, always, any program. I can confirm this with fpc 2.6.4 too. Create new project - run - stop - AV. So I get AVs for just saving while my program is running (I use ctrl+s as a shortcut for quick compile, just an eclipse habit (build on save) to get rid of error markers). Unfortunately there is not much more info I can give you: TMainIDE.DoInitProjectRun ProgramFilename=/tmp/project1 [TMainIDE.DoRunProject] Debugger=TFpDebugDebugger [TMainIDE.DoRunProject] END Got PID: 23353, TID: -1 TApplication.HandleException Access violation Stack trace: $ more useless stack trace text... Ubuntu 14.04 64bit Lazarus rev 46936 FPC 2.7.1 rev 28946 I got a better one: Failed to read data at address $0008 from processid 4512. Errcode: 5 TApplication.HandleException Invalid floating point operation Stack trace: $013C71A2 line 582 of ../debugger/assemblerdlg.pp $0071DB79 line 4204 of include/control.inc $0071D75D line 4162 of include/control.inc $004301F1 $007119B1 line 1451 of include/control.inc $006FB675 line 4662 of include/wincontrol.inc $006FE073 line 5287 of include/wincontrol.inc $004736F3 line 1443 of include/customform.inc $0084057E line 112 of lclmessageglue.pas $007DADEA line 3618 of gtk2/gtk2proc.inc $007EF2B1 line 1421 of gtk2/gtk2callback.inc $007EF9DC line 1598 of gtk2/gtk2callback.inc $7F6A13AB8C0F Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 21/11/2014 22:46, Mattias Gaertner wrote: But I see it for example with any constructor. Even as simple as this: type TMyClass = class public i: Integer; constructor Create; end; constructor TMyClass.Create; begin i:=3; end; procedure TForm1.FormCreate(Sender: TObject); var c: TMyClass; begin c:=TMyClass.Create; // - breakpoint end' Run, Step into, cursor moves to 'begin' of the constructor. Step into, cursor moves to 'end' of the constructor. Step into, cursor moves to 'i:=3'. With this code, I get the same. It would take a longer time to analyse the line info in the asm as fpc generates it (as that is already cryptic enough), but I would think this is as fpc generates it. In the asm output ( -al ) .section .debug_line # === header start === ... # [41:1] .byte2 .uleb128.Ll3-.Ll2 .byte14 .Ll2 is a label at the start of the constructor. Also in the asm the comment introducing line 41 # [41] end; comes before # [40] i:=3; So as far as the debugger goes, this would then be correctly following the debug info. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Fri, 21 Nov 2014 23:08:00 + Martin Frb laza...@mfriebe.de wrote: [...] So as far as the debugger goes, this would then be correctly following the debug info. Funny fpc. Thanks for checking. BTW, the default TGDBMIDebugger jumps even worse. Begin, End, Begin, i:=3. So the new debugger is better here. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Fri, 21 Nov 2014 23:51:13 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 21 Nov 2014 16:31:26 +0100 Reimar Grabowski reimg...@web.de wrote: [...] Create new project - run - stop - AV. The Assembler window initialized only if it was not docked. I fixed that. The AV is gone. Then I got an AV when closing the IDE. The destructor didn't clean up the queued async calls. I fixed that. Without the AVs you can see the mem leaks. I fixed the three mem leaks. I have no idea what the code is doing. Hopefully I didn't break anything. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Fri, Nov 21, 2014 at 10:33 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Fri, 21 Nov 2014 23:51:13 +0100
Mattias Gaertner nc-gaert...@netcologne.de wrote:
(...)
Without the AVs you can see the mem leaks. I fixed the three mem leaks.
Here's a patch to change the Append method, just in case ;-)
Best regards,
Flávio
diff --git a/components/debuggerintf/dbgintfdebuggerbase.pp
b/components/debuggerintf/dbgintfdebuggerbase.pp
index 146ba74..261d95a 100644
--- a/components/debuggerintf/dbgintfdebuggerbase.pp
+++ b/components/debuggerintf/dbgintfdebuggerbase.pp
@@ -1240,7 +1240,7 @@ type
procedure SetCount(const AValue: Integer);
public
procedure Clear;
-function Append(const AnEntryPtr: PDisassemblerEntry): Integer;
+function Append(const AnEntry: TDisassemblerEntry): Integer;
procedure Merge(const AnotherRange: TDBGDisassemblerEntryRange);
// Actual addresses on the ranges
function FirstAddr: TDbgPtr;
@@ -4706,12 +4706,13 @@ begin
FCount := 0;
end;
-function TDBGDisassemblerEntryRange.Append(const AnEntryPtr:
PDisassemblerEntry): Integer;
+function TDBGDisassemblerEntryRange.Append(const AnEntry: TDisassemblerEntry
+ ): Integer;
begin
if FCount = Capacity
then Capacity := FCount + Max(20,FCount div 4);
- FEntries[FCount] := AnEntryPtr^;
+ FEntries[FCount] := AnEntry;
Result := FCount;
inc(FCount);
end;
diff --git a/components/lazdebuggergdbmi/gdbmidebugger.pp
b/components/lazdebuggergdbmi/gdbmidebugger.pp
index 5f4df11..5d61759 100644
--- a/components/lazdebuggergdbmi/gdbmidebugger.pp
+++ b/components/lazdebuggergdbmi/gdbmidebugger.pp
@@ -4042,7 +4042,7 @@ function TGDBMIDebuggerCommandDisassemble.DoExecute:
Boolean;
if (ItmPtr^.FuncName = LastItem^.FuncName)
then ItmPtr^.FuncName:= LastItem^.FuncName;
end;
- ADestRange.Append(ItmPtr);
+ ADestRange.Append(ItmPtr^);
// now we can move the data, pointed to by ItmPtr // reduce search range
if ItmPtr2 nil
then begin
@@ -4388,7 +4388,7 @@ function TGDBMIDebuggerCommandDisassemble.DoExecute:
Boolean;
Itm.SrcFileLine := 0;
Itm.Offset := 0;
itm.Statement := 'error';
-NewRange.Append(@Itm);
+NewRange.Append(Itm);
FKnownRanges.AddRange(NewRange); // NewRange is now owned by
FKnownRanges
NewRange := nil;
FreeAndNil(DisAssList);
diff --git a/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas
b/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas
index 6a23801..5706864 100644
--- a/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas
+++ b/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas
@@ -804,7 +804,7 @@ begin
AnEntry.SrcFileLine:=ASrcFileLine;
AnEntry.SrcFileName:=ASrcFileName;
AnEntry.SrcStatementIndex:=StatIndex;
- ARange.Append(@AnEntry);
+ ARange.Append(AnEntry);
ALastAddr:=AnAddr;
inc(StatIndex);
Inc(AnAddr, {%H-}PtrUInt(p) - {%H-}PtrUInt(@CodeBin));
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 24/08/14 16:44, Joost van der Sluis wrote:
On 07/21/2014 10:11 PM, C Western wrote:
Managed to create a small test program:
program tproj;
uses sysutils;
procedure a(const s: string);
var
a: string;
r: array [0..10] of Double;
begin
a := s+s+s;
r[8] := StrToFloat(a);
WriteLn(a, ' ', r[8])
end;
begin
a('6'); -Set break point here, and hit step into here twice
end.
First step into ends on begin in procedure, second on final end.
Seems to be related to size of stack frame - if I didn't have the
array in, it works as expected. I compiled it with all stack checks on.
I know this stuff can be difficult - I have certainly seen some odd
things with Delphi and gdb. My hope is we can resolve some of these
things as we now have control over all parts of the system.
Solving this particular problem was easy, but debugging your
test-application opened a whole new can of worms.
I've re-written the step-into-line code completely. It's not fool-proof,
but at least it works stepping into a procedure one level deep. (That
means: if the procedure being called has debug-info.) If it does not
have debug-info but another procedure with debug info is called
further-on, it will probably work.
The problem lies in functions that do not set the stack-frame. Among
those are the compiler-procedures. If two of those are called after each
other, the debugger can loose track...
So, please test. I'm convinced that a solution that always works and is
also reasonable fast is impossible. (gdb also makes comparable mistakes)
Oh, and I added re-direction of the console in- and output to the
console-debug screen.
Thanks for looking at this - I will try it out. Two things strike me:
1. How about a slow step option?
2. Could the compiler add more information to make this easier? Or is it
simply a matter of compiling everything with a stack frame?
Colin
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Mon, Aug 25, 2014 at 6:26 AM, C Western l...@c-m-w.me.uk wrote: 1. How about a slow step option? What's is slow step option? Is it stepping over each instruction until the next known line reached? 2. Could the compiler add more information to make this easier? Or is it simply a matter of compiling everything with a stack frame? How about using a 3d party library compiled without debugging info / stack frame? The library could use your code compiled with debug info (i.e. by calling a callback), where the debugger should stop. thanks, Dmirty -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 08/25/2014 02:02 PM, Dmitry Boyarintsev wrote: On Mon, Aug 25, 2014 at 6:26 AM, C Western l...@c-m-w.me.uk mailto:l...@c-m-w.me.uk wrote: 1. How about a slow step option? What's is slow step option? Is it stepping over each instruction until the next known line reached? As I wrote that a 'perfect' step (the step you described) would be very slow, I think that this is what he means, yes. I've tried that: LCL without debug-info, created a OnFormCreate event and then I stepped into the CreateForm function. With this 'slow step' it took more than 15 minutes before the debugger stopped inside the event. So a slow step is not a real option. What could be done is adding a setting for how many levels deep the debugger will use simple single-stepping. But for now I'm happy with the current solution. 2. Could the compiler add more information to make this easier? Or is it simply a matter of compiling everything with a stack frame? How about using a 3d party library compiled without debugging info / stack frame? The library could use your code compiled with debug info (i.e. by calling a callback), where the debugger should stop. Indeed. That's one problem. Another problem is that on i386 a third-party library could use another calling convention. And for some (most?) compiler-proc's it is not possible to create a stack-frame, which also would slow down the code. What the compiler could do is adding line-info for the complete code. But I doubt that an average developers will appreciate that. An alternative could be to add line-info, but with a remark that the code could be skipped during stepping. But then we need to add something new to the Dwarf-format. Joost. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Mon, Aug 25, 2014 at 10:47 AM, Joost van der Sluis jo...@cnoc.nl wrote: 2. Could the compiler add more information to make this easier? Or is it simply a matter of compiling everything with a stack frame? How about using a 3d party library compiled without debugging info / stack frame? The library could use your code compiled with debug info (i.e. by calling a callback), where the debugger should stop. Indeed. That's one problem. Another problem is that on i386 a third-party library could use another calling convention. And for some (most?) compiler-proc's it is not possible to create a stack-frame, which also would slow down the code. What the compiler could do is adding line-info for the complete code. But I doubt that an average developers will appreciate that. An alternative could be to add line-info, but with a remark that the code could be skipped during stepping. But then we need to add something new to the Dwarf-format. The only option I would think of, is to set break-points at all known routines and let the process run, until a break point is hit. That requires no changes to either compiler or debug-info format. I don't think that would be slow. Of course, there won't be enough of hardware breakpoints, but software breakpoints should do the trick at least of x86 platforms. I guess that what I would for duby... when I get chance to get back to it. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 07/21/2014 10:11 PM, C Western wrote:
Managed to create a small test program:
program tproj;
uses sysutils;
procedure a(const s: string);
var
a: string;
r: array [0..10] of Double;
begin
a := s+s+s;
r[8] := StrToFloat(a);
WriteLn(a, ' ', r[8])
end;
begin
a('6'); -Set break point here, and hit step into here twice
end.
First step into ends on begin in procedure, second on final end.
Seems to be related to size of stack frame - if I didn't have the
array in, it works as expected. I compiled it with all stack checks on.
I know this stuff can be difficult - I have certainly seen some odd
things with Delphi and gdb. My hope is we can resolve some of these
things as we now have control over all parts of the system.
Solving this particular problem was easy, but debugging your
test-application opened a whole new can of worms.
I've re-written the step-into-line code completely. It's not fool-proof,
but at least it works stepping into a procedure one level deep. (That
means: if the procedure being called has debug-info.) If it does not
have debug-info but another procedure with debug info is called
further-on, it will probably work.
The problem lies in functions that do not set the stack-frame. Among
those are the compiler-procedures. If two of those are called after each
other, the debugger can loose track...
So, please test. I'm convinced that a solution that always works and is
also reasonable fast is impossible. (gdb also makes comparable mistakes)
Oh, and I added re-direction of the console in- and output to the
console-debug screen.
Joost.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
2014.07.14. 23:13 keltezéssel, Joost van der Sluis írta: To install the debugger just install the components/lazdebuggers/lazdebuggerfp.lpk package. Can anybody install on Win32? I 've tried that myself again and it installed without any problems. Maybe you can try to run the Lazarus itself in GDB, after you've installed the package. Then when you get the 'out of memory' problem, type 'bt' and send us the backtrace. If you do not know how to work with GDB from the console, look here: http://wiki.freepascal.org/Creating_a_Backtrace_with_GDB Joost.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
2014.07.21. 11:42 keltezéssel, Joost van der Sluis írta: I 've tried that myself again and it installed without any problems. Maybe you can try to run the Lazarus itself in GDB, after you've installed the package. Then when you get the 'out of memory' problem, type 'bt' and send us the backtrace. If you do not know how to work with GDB from the console, look here: http://wiki.freepascal.org/Creating_a_Backtrace_with_GDB Joost. Tried with 45950 (FPC 2.6.4) and got the attached error. Gabor -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 20/07/14 15:47, Joost van der Sluis wrote: I haven't seen the spurious SIGSEGV for a while, so maybe that is fixed. I am still seeing the spurious leaving of a routine on pressing step into on one particular begin, but mostly it looks good - I think it is rather faster than the gdb debugger. It's not that strange it's faster then the gdb-debugger, as gdb is an external application from which the output is parsed. The step-into-next-line code is quite complicated. Just single-stepping until another procedure with line-info has been hit is too slow. So it uses watchpoints on the stack, so that the debuggee stops when a new procedure is being called, or the current procedure has ended. Then it compares the line-info with the line-info at the start of the step-into-next-line. It is very well possible that for some reason the start of the procedure is ignored, so that it immediately steps to the end of the procedure. Can you create a small test-application with a procedure that has this problem? With some steps to reproduce? If you want to look at it yourself, look at the TDbgControllerStepIntoLineCmd class in fpdbgcontroller.pas. The DoContinue function is called when the debuggee has to start running again. When the debuggee stops running, ResolveEvent is being called. ResolveEvent has to set Finished to true if the command has finished. If Finished is set to false, DoContinue is called again, and the debuggee continues running. Not sure about the spurious step - I notice on some routines stepping steps to the end line sometimes and then back into the routine. Perahps it is related to this? Do you have an example? It could be that the execution point really jumps up-and-down, or that the debug-info gives some strange results. Joost.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
Am 21.07.2014 13:45 schrieb Joost van der Sluis jo...@cnoc.nl: Not sure about the spurious step - I notice on some routines stepping steps to the end line sometimes and then back into the routine. Perahps it is related to this? Do you have an example? It could be that the execution point really jumps up-and-down, or that the debug-info gives some strange results. This happens with GDB as well. Mostly in constructors. Or it's related to implicit exception frames... :/ Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 21/07/14 12:44, Joost van der Sluis wrote:
On 20/07/14 15:47, Joost van der Sluis wrote:
I haven't seen the spurious SIGSEGV for a while, so maybe that is fixed.
I am still seeing the spurious leaving of a routine on pressing step
into on one particular begin, but mostly it looks good - I think it is
rather faster than the gdb debugger.
It's not that strange it's faster then the gdb-debugger, as gdb is an
external application from which the output is parsed.
The step-into-next-line code is quite complicated. Just single-stepping
until another procedure with line-info has been hit is too slow. So it
uses watchpoints on the stack, so that the debuggee stops when a new
procedure is being called, or the current procedure has ended. Then it
compares the line-info with the line-info at the start of the
step-into-next-line. It is very well possible that for some reason the
start of the procedure is ignored, so that it immediately steps to the
end of the procedure.
Can you create a small test-application with a procedure that has this
problem? With some steps to reproduce?
Managed to create a small test program:
program tproj;
uses sysutils;
procedure a(const s: string);
var
a: string;
r: array [0..10] of Double;
begin
a := s+s+s;
r[8] := StrToFloat(a);
WriteLn(a, ' ', r[8])
end;
begin
a('6'); -Set break point here, and hit step into here twice
end.
First step into ends on begin in procedure, second on final end.
Seems to be related to size of stack frame - if I didn't have the array
in, it works as expected. I compiled it with all stack checks on.
I know this stuff can be difficult - I have certainly seen some odd
things with Delphi and gdb. My hope is we can resolve some of these
things as we now have control over all parts of the system.
Colin
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 19/07/14 22:26, Joost van der Sluis wrote:
Did you step directly into fpc_shortstr_SInt, or did you do a 'step
into', and did it eventually arrived at fpc_shortstr_SInt, because it
was the first procedure with debug-info?
In the first case, a software-debug breakpoint is set, which is
probably
not removed correctly. In that case the debuggee does SIGSEGV, only it
will only do this because the debugger did change it's code.
In the second case, it's difficult to say what happens, since
hardware-breakpoints are used in that case.
Do you get a message on the console like 'failed to write data at
xx'?
Just tried it again - it doesn't seem to be consistent. The specific was
stepping into a routine, and the problem seems to happen when stepping
into at the first begin. Trying it just now the debugger step into in
these circumstances - it now exits the routine. There are lots of
Failed to read data at address $10B70F08C08347F8 from processid 11321.
Errcode: 5
Failed to read data at address $E800C766D388 from processid 11321.
Errcode: 5
Failed to read data at address $E800C766D388 from processid 11321.
Errcode: 5
Failed to read data at address $E800C766D388 from processid 11321.
Errcode: 5
Failed to read data at address $E800C766D388 from processid 11321.
Errcode: 5
Failed to read data at address $E800C766D388 from processid 11321.
Errcode: 5
Can you run Lazarus in a debugger (gdb, but in principle fpdebug is also
possible ;) ) and set a breakpoint on fpdbglinuxclasses.pas:591. This is
the line where the error above is printed. Then please try to reproduce
the problem, and send me a backtrace when that breakpoint is hit.
The behavior failed to read messages seem rather random. I think they
may only arise when I have the locals window open, in which case
presumably read failures are to be expected. A backtrace (below) doesn't
look that useful. The step into failing on a begin failure seems
consistent, though it certainly doesn't happen on every begin.
Breakpoint 1, READWORDSIZE (parentfp=0x7fd9e359e9c0, ADR=0, AVAL=
18446744073709551615) at fpdbglinuxclasses.pas:591
591 log('Failed to read data at address '+FormatAddress(Adr)+'
from processid '+inttostr(Process.ProcessID)+'. Errcode: '+inttostr(e));
(gdb) where
#0 READWORDSIZE (parentfp=0x7fd9e359e9c0, ADR=0, AVAL=18446744073709551615)
at fpdbglinuxclasses.pas:591
#1 0x0140925f in READDATA (this=0x7fd9e1515040, AADRESS=1, ASIZE=
2000, ADATA=0) at fpdbglinuxclasses.pas:614
#2 0x0149580a in DOREADDATA (this=0x7fd9f1d07e00)
at fpdebugdebugger.pas:1443
#3 0x014938e2 in EXECUTE (this=0x7fd9e8bb84e0)
at fpdebugdebugger.pas:852
#4 0x00718ad0 in THREADFUNC (PARAMETER=0x7fd9e8bb84e0)
at ../unix/tthread.inc:109
#5 0x7fd9e8bb84e0 in ?? ()
#6 0x7fd9e154d000 in ?? ()
#7 0x7fd9e8bb84e0 in ?? ()
#8 0x0064901c in SYSFREEMEM_FIXED (LOC_FREELISTS=0x20, PMC=
0x7fd9e801fb00) at ../inc/heap.inc:1154
#9 0x7fd9e359eaa8 in ?? ()
#10 0x in ?? ()
Colin
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
2014.07.14. 23:13 keltezéssel, Joost van der Sluis írta: To install the debugger just install the components/lazdebuggers/lazdebuggerfp.lpk package. Hi All, Can anybody install on Win32? Gabor -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 19/07/14 22:26, Joost van der Sluis wrote: Do you get a message on the console like 'failed to write data at xx'? Just tried it again - it doesn't seem to be consistent. The specific was stepping into a routine, and the problem seems to happen when stepping into at the first begin. Trying it just now the debugger step into in these circumstances - it now exits the routine. There are lots of Failed to read data at address $10B70F08C08347F8 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Can you run Lazarus in a debugger (gdb, but in principle fpdebug is also possible ;) ) and set a breakpoint on fpdbglinuxclasses.pas:591. This is the line where the error above is printed. Then please try to reproduce the problem, and send me a backtrace when that breakpoint is hit. The behavior failed to read messages seem rather random. I think they may only arise when I have the locals window open, in which case presumably read failures are to be expected. A backtrace (below) doesn't look that useful. The step into failing on a begin failure seems consistent, though it certainly doesn't happen on every begin. You are right, the backtrace looks normal. I suspected that the read was not being called from within the debug-thread. Although in that case the error-code normally is 3, not 5. But from the backtrace it is clear that this is not the case. You are probably right that it is something unrelated, such as the watches-window. But I can not reproduce your problem, with a rtl compiled with OPT=-gw2 I can step through as much as I want. I did fix some problems with resetting breakpoints and did apply your patch to find relative filenames. Can yu update and try again? Maybe I'm lucky... Joost.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 20/07/14 15:47, Joost van der Sluis wrote: You are right, the backtrace looks normal. I suspected that the read was not being called from within the debug-thread. Although in that case the error-code normally is 3, not 5. But from the backtrace it is clear that this is not the case. You are probably right that it is something unrelated, such as the watches-window. But I can not reproduce your problem, with a rtl compiled with OPT=-gw2 I can step through as much as I want. I did fix some problems with resetting breakpoints and did apply your patch to find relative filenames. Can yu update and try again? Maybe I'm lucky... I haven't seen the spurious SIGSEGV for a while, so maybe that is fixed. I am still seeing the spurious leaving of a routine on pressing step into on one particular begin, but mostly it looks good - I think it is rather faster than the gdb debugger. Not sure about the spurious step - I notice on some routines stepping steps to the end line sometimes and then back into the routine. Perahps it is related to this? Colin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
when I switched to the new debugger, I have no output in the Console window (Terminal Output). Whenever I use WriteLn() or DebugLn() in code, this window remains empty while with GDB I can see it. Yeah, that window was added because with gdb it's difficult to debug console-applications. But in this case you can use the console itself, so you don't need this console-window. Maybe I could add a setting to let you choose which console to use. And it's possible to re-direct everything to the console window like is done width the gdb output. But I think that that' something that Martin is better at. It has nothing to do with the debugger, but is an IDE-thing. For now you could try to start lazarus from the console, and then use that console to see the debug-output. Joost.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 16/07/14 08:53, Joost van der Sluis wrote: Looks promising, but (on current SVN): an explicit raise Exception.Create causes an assembler window to appear, trying to show ../inc/except.inc rather than the source line with the raise as the standard debugger does. Do you have a rtl with debug-info enabled? In that case it's normal, as this is the location where the exception actually takes place. I do indeed have debug info enabled in the RTL. I can live with the rtl showing, though I would encourage a special case test for an explicit call to raise, as I assume is in the gdb interfaces. However the inability to show the rtl source is a problem - again gdb handles it fine, so I assume it is an issue with the way filenames like ../inc/except.inc are handled - any change of fixing this? Or an indication of where I might look? Colin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 19/07/14 10:35, C Western wrote:
On 16/07/14 08:53, Joost van der Sluis wrote:
Looks promising, but (on current SVN):
an explicit raise Exception.Create causes an assembler window to
appear,
trying to show ../inc/except.inc rather than the source line with the
raise as the standard debugger does.
Do you have a rtl with debug-info enabled? In that case it's normal, as
this is the location where the exception actually takes place.
I do indeed have debug info enabled in the RTL. I can live with the rtl
showing, though I would encourage a special case test for an explicit
call to raise, as I assume is in the gdb interfaces.
However the inability to show the rtl source is a problem - again gdb
handles it fine, so I assume it is an issue with the way filenames like
../inc/except.inc are handled - any change of fixing this? Or an
indication of where I might look?
Follow up to this - a simple patch (attached) allows the rtl source to
show, rather than the assembler window. However there seems to be a more
fundamental problem, in that a step into that ends up stepping into a
rtl routine like fpc_shortstr_SInt reports a SIGSEGV in the debugged
program, when no such exception has occurred.
Colin
diff -uwNr '--exclude=.svn' '--exclude=Makefile' '--exclude=Makefile.fpc' '--exclude=Makefile.compiled' '--exclude=*.rsj' '--exclude=*.bak' '--exclude=*.po' lazarus/components/fpdebug/fpdbgdwarfdataclasses.pas lazarus.w/components/fpdebug/fpdbgdwarfdataclasses.pas
--- lazarus/components/fpdebug/fpdbgdwarfdataclasses.pas 2014-07-05 10:32:19.458170514 +0100
+++ lazarus.w/components/fpdebug/fpdbgdwarfdataclasses.pas 2014-07-19 12:34:20.493380536 +0100
@@ -474,6 +474,7 @@
FInfoData: Pointer;
FFileName: String;
+FCompDir: String;
FUnitName: String;
FIdentifierCase: Integer;
FProducer: String;
@@ -538,6 +539,7 @@
function GetLineAddressMap(const AFileName: String): PDWarfLineMap;
function GetLineAddress(const AFileName: String; ALine: Cardinal): TDbgPtr;
procedure BuildLineInfo(AAddressInfo: PDwarfAddressInfo; ADoAll: Boolean);
+function FullFileName(const AFileName:string): String;
property Valid: Boolean read FValid;
property FileName: String read FFileName;
@@ -3246,7 +3248,7 @@
procedure TDwarfLineInfoStateMachine.SetFileName(AIndex: Cardinal);
begin
if (Aindex 0) and (AIndex = FOwner.FLineInfo.FileNames.Count)
- then FFileName := FOwner.FLineInfo.FileNames[AIndex - 1]
+ then FFileName := FOwner.FullFileName(FOwner.FLineInfo.FileNames[AIndex - 1])
else FFileName := Format('Unknown fileindex(%u)', [AIndex]);
end;
@@ -3361,6 +3363,13 @@
Result := FAddressMap;
end;
+function TDwarfCompilationUnit.FullFileName(const AFileName: String): String;
+begin
+ Result := AFileName;
+ if FCompDir = '' then exit;
+ Result := LazFileUtils.ResolveDots(FCompDir+AFileName);
+end;
+
function TDwarfCompilationUnit.GetUnitName: String;
begin
Result := FUnitName;
@@ -3604,6 +3613,9 @@
if LocateAttribute(Scope.Entry, DW_AT_name, AttribList, Attrib, Form)
then ReadValue(Attrib, Form, FFileName);
+ if LocateAttribute(Scope.Entry, DW_AT_comp_dir, AttribList, Attrib, Form)
+ then ReadValue(Attrib, Form, FCompDir);
+
if LocateAttribute(Scope.Entry, DW_AT_producer, AttribList, Attrib, Form)
then ReadValue(Attrib, Form, FProducer);
diff -uwNr '--exclude=.svn' '--exclude=Makefile' '--exclude=Makefile.fpc' '--exclude=Makefile.compiled' '--exclude=*.rsj' '--exclude=*.bak' '--exclude=*.po' lazarus/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas lazarus.w/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas
--- lazarus/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas 2014-07-17 20:51:23.060036838 +0100
+++ lazarus.w/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas 2014-07-19 12:28:17.965977467 +0100
@@ -1563,7 +1563,7 @@
if sym = nil then
Exit;
-result.SrcFile := sym.FileName;
+result.SrcFile := ExtractFileName(sym.FileName);
result.SrcLine := sym.Line;
result.SrcFullName := sym.FileName;
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
Follow up to this - a simple patch (attached) allows the rtl source to show, rather than the assembler window. However there seems to be a more fundamental problem, in that a step into that ends up stepping into a rtl routine like fpc_shortstr_SInt reports a SIGSEGV in the debugged program, when no such exception has occurred. Did you step directly into fpc_shortstr_SInt, or did you do a 'step into', and did it eventually arrived at fpc_shortstr_SInt, because it was the first procedure with debug-info? In the first case, a software-debug breakpoint is set, which is probably not removed correctly. In that case the debuggee does SIGSEGV, only it will only do this because the debugger did change it's code. In the second case, it's difficult to say what happens, since hardware-breakpoints are used in that case. Do you get a message on the console like 'failed to write data at xx'? Joost.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 19/07/14 15:18, Joost van der Sluis wrote: Follow up to this - a simple patch (attached) allows the rtl source to show, rather than the assembler window. However there seems to be a more fundamental problem, in that a step into that ends up stepping into a rtl routine like fpc_shortstr_SInt reports a SIGSEGV in the debugged program, when no such exception has occurred. Did you step directly into fpc_shortstr_SInt, or did you do a 'step into', and did it eventually arrived at fpc_shortstr_SInt, because it was the first procedure with debug-info? In the first case, a software-debug breakpoint is set, which is probably not removed correctly. In that case the debuggee does SIGSEGV, only it will only do this because the debugger did change it's code. In the second case, it's difficult to say what happens, since hardware-breakpoints are used in that case. Do you get a message on the console like 'failed to write data at xx'? Just tried it again - it doesn't seem to be consistent. The specific was stepping into a routine, and the problem seems to happen when stepping into at the first begin. Trying it just now the debugger step into in these circumstances - it now exits the routine. There are lots of Failed to read data at address $10B70F08C08347F8 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Step over works fine on the begin If I step one instruction in the assembler window, step into then seems to work OK, including into the RTL routines. Colin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
Did you step directly into fpc_shortstr_SInt, or did you do a 'step into', and did it eventually arrived at fpc_shortstr_SInt, because it was the first procedure with debug-info? In the first case, a software-debug breakpoint is set, which is probably not removed correctly. In that case the debuggee does SIGSEGV, only it will only do this because the debugger did change it's code. In the second case, it's difficult to say what happens, since hardware-breakpoints are used in that case. Do you get a message on the console like 'failed to write data at xx'? Just tried it again - it doesn't seem to be consistent. The specific was stepping into a routine, and the problem seems to happen when stepping into at the first begin. Trying it just now the debugger step into in these circumstances - it now exits the routine. There are lots of Failed to read data at address $10B70F08C08347F8 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Failed to read data at address $E800C766D388 from processid 11321. Errcode: 5 Can you run Lazarus in a debugger (gdb, but in principle fpdebug is also possible ;) ) and set a breakpoint on fpdbglinuxclasses.pas:591. This is the line where the error above is printed. Then please try to reproduce the problem, and send me a backtrace when that breakpoint is hit. Joost.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 07/16/2014 09:53 AM, Joost van der Sluis wrote: I hung lazarus by hitting F4 (step to current line). The backtrace may help: Step to current line is indeed broken, I'll fix that. This one is fixed. But I discovered that removing breakpoints while the debuggee is running is buggy. Joost. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
Hi, when I switched to the new debugger, I have no output in the Console window (Terminal Output). Whenever I use WriteLn() or DebugLn() in code, this window remains empty while with GDB I can see it. Of course, it's Linux+Qt (AFAIR this window is present not in Windows). Vojtěch __ Od: Joost van der Sluis jo...@cnoc.nl Komu: lazarus@lists.lazarus.freepascal.org Datum: 14.07.2014 23:14 Předmět: [Lazarus] Need testers for the a new debugger Hi all, The debugger has been improved a lot and I could need some help testing the thing. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
2014.07.15. 18:50 keltezéssel, Joost van der Sluis írta: Damn, I didn't think of that. Should be fixed now. Joost. Tried again and got out of memory at lpk install, Lazarus crash and never start after. Gabor -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 14/07/14 22:13, Joost van der Sluis wrote: Hi all, As I've written before there's a new debugger available for Lazarus. (Actually there are two new debuggers, but I'm talking about the new gdb-less debugger) The debugger has been improved a lot and I could need some help testing the thing. Looks promising, but (on current SVN): an explicit raise Exception.Create causes an assembler window to appear, trying to show ../inc/except.inc rather than the source line with the raise as the standard debugger does. Do you have a rtl with debug-info enabled? In that case it's normal, as this is the location where the exception actually takes place. I hung lazarus by hitting F4 (step to current line). The backtrace may help: Step to current line is indeed broken, I'll fix that. Joost-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
2014.07.16. 9:58 keltezéssel, Joost van der Sluis írta: At install? That's really strange. Did you get Lazarus up again? Normally you can always fix things with a 'make all' from the command-line. Then start lazarus, and do a 'Build all' from within the IDE. Thinks like 'Out of memory' or 'Disk full' can happen during debugging. (If that happens, it's a bug, but it is the kind of error-message you can expect when a debugger fails.) But at install? Someone else an idea? Joost. After lpk install. Copied trunk to an empty directory, make bigide, start Lazarus, select FPC source directory, open lazdebuggerfp.lpk, Install, OK, Yes, when IDE restarted see the splash screen and the earlier attached error messages. FPC 2.6.4, XP SP3 32bit. Gabor -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
Il 14/07/2014 23:13, Joost van der Sluis ha scritto: Hi all, As I've written before there's a new debugger available for Lazarus. (Actually there are two new debuggers, but I'm talking about the new gdb-less debugger) The debugger has been improved a lot and I could need some help testing the thing. [...] In my setup (Lazarus trunk + fpc 2.6.4) it fails to compile: fpdbglinuxclasses.pas(436,27) Error: Incompatible types: got procedure variable type of procedure(TObject) of object;Register expected procedure variable type of procedure;Register It would appear that the reason is that in fpc process.pp TProcessForkEvent is defined as a procedure as opposed to procedure of object (as required in fpdbglinuxclasses.pas). I've tried to fix it but I don't have fpc v2.6.4 here, nor Linux. (I'm in the train) Can you do a svn update, try again, and tell if it works? Joost.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
2014.07.14. 23:13 keltezéssel, Joost van der Sluis írta: To install the debugger just install the components/lazdebuggers/lazdebuggerfp.lpk package. After you've done this, go to tools-options-debugger and select the 'FpDebug internal Dwarf-debugger'. Hi, components\lazdebuggers\lazdebuggerfp\lazdebuggerfp.lpk Compile error on Win32 with 2.6.4: fpdebugdebugger.pas(1371,11) Error: identifier idents no member Queue Gabor -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
Am 15.07.2014 09:47 schrieb Gabor Boros gaborbo...@yahoo.com: 2014.07.14. 23:13 keltezéssel, Joost van der Sluis írta: To install the debugger just install the components/lazdebuggers/lazdebuggerfp.lpk package. After you've done this, go to tools-options-debugger and select the 'FpDebug internal Dwarf-debugger'. Hi, components\lazdebuggers\lazdebuggerfp\lazdebuggerfp.lpk Compile error on Win32 with 2.6.4: fpdebugdebugger.pas(1371,11) Error: identifier idents no member Queue TThread.Queue is only supported in FPC 2.7.1. Maybe try to replace it with a Application.QueueAsyncCall. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
Am 15.07.2014 09:47 schrieb Gabor Boros gaborbo...@yahoo.com mailto:gaborbo...@yahoo.com : 2014.07.14. 23:13 keltezéssel, Joost van der Sluis írta: To install the debugger just install the components/lazdebuggers/lazdebuggerfp.lpk package. After you've done this, go to tools-options-debugger and select the 'FpDebug internal Dwarf-debugger'. components\lazdebuggers\lazdebuggerfp\lazdebuggerfp.lpk Compile error on Win32 with 2.6.4: fpdebugdebugger.pas(1371,11) Error: identifier idents no member Queue TThread.Queue is only supported in FPC 2.7.1. Maybe try to replace it with a Application.QueueAsyncCall. Damn, I didn't think of that. Should be fixed now. Joost.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 14/07/14 22:13, Joost van der Sluis wrote: Hi all, As I've written before there's a new debugger available for Lazarus. (Actually there are two new debuggers, but I'm talking about the new gdb-less debugger) The debugger has been improved a lot and I could need some help testing the thing. Looks promising, but (on current SVN): an explicit raise Exception.Create causes an assembler window to appear, trying to show ../inc/except.inc rather than the source line with the raise as the standard debugger does. I hung lazarus by hitting F4 (step to current line). The backtrace may help: (gdb) where #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0065747d in INTRTLEVENTWAITFOR (AEVENT=0x7f6544ca5ec0) at ../unix/cthreads.pp:923 #2 0x7f65444954c0 in ?? () #3 0x00649e41 in RTLEVENTWAITFOR (STATE=0x7f6544ca5ec4) at ../inc/thread.inc:319 #4 0x7fff3af7e7a0 in ?? () #5 0x01493b5b in EXECUTEINDEBUGTHREAD (this=0x7f6567371960, AMETHOD=...) at fpdebugdebugger.pas:1379 #6 0x01493f97 in PREPARECALLSTACKENTRYLIST (this=0x7f6567371960) at fpdebugdebugger.pas:1483 #7 0x0148fea5 in REQUESTCOUNT (this=0x7f65444954c0, ACALLSTACK=0x7f6543d982c0) at fpdebugdebugger.pas:311 #8 0x00c840cc in REQUESTATLEASTCOUNT (this=0x7f65444954c0, ACALLSTACK=0x7f6543d982c0, AREQUIREDMINCOUNT=11) at dbgintfdebuggerbase.pp:4158 #9 0x00c76a45 in REQUESTATLEASTCOUNT (this=0x7f656671a2c0, ACALLSTACK=0x7f6543d982c0, AREQUIREDMINCOUNT=11) at ../debugger/debugger.pp:6430 #10 0x00c687d8 in HASATLEASTCOUNT (this=0x7f6543d982c0, AREQUIREDMINCOUNT=11) at ../debugger/debugger.pp:3860 #11 0x00c7614e in COUNTLIMITED (this=0x7f6543d982c0, ALIMIT=11) at ../debugger/debugger.pp:6321 warning: Range for type error type has invalid bounds 0..-101 #12 0x01345dda in BREAKPOINTCHANGED (this=0x7f65666faf50, ASENDER=0x7f6566719f60, ABREAKPOINT=0x7f654f6464a0) at ../debugger/callstackdlg.pp:692 #13 0x00c6f55c in UPDATE (this=0x7f6566719f60, ITEM=0x7f654f6464a0) at ../debugger/debugger.pp:5099 #14 0x00c4f72d in UPDATE (this=0x7f6566719f60, ITEM=0x7f654f6464a0) at debugmanager.pas:370 #15 0x007102d9 in CHANGED (this=0x7f6544ca5ec0, ALLITEMS=128) at ../objpas/classes/collect.inc:49 #16 0x0002 in ?? () #17 0x01217c0e in DOCHANGED (this=0x7f654f6464a0) at dbgintfmiscclasses.pas:509 #18 0x00c6b90c in DOCHANGED (this=0x7f654f6464a0) at ../debugger/debugger.pp:4500 #19 0x00c4ff59 in DOCHANGED (this=0x7f654f6464a0) at debugmanager.pas:452 #20 0x01217ab2 in CHANGED (this=0x7f654f6464a0) at dbgintfmiscclasses.pas:498 #21 0x00c80b27 in DOCHANGED (this=0x7f654f2e3dc0) at dbgintfdebuggerbase.pp:3340 #22 0x01490e27 in DOCHANGED (this=0x7f654f2e3dc0) at fpdebugdebugger.pas:581 #23 0x01217ab2 in CHANGED (this=0x7f654f2e3dc0) at dbgintfmiscclasses.pas:498 #24 0x01490c74 in DOSTATECHANGE (this=0x7f654f2e3dc0, AOLDSTATE=DSRUN) at fpdebugdebugger.pas:538 #25 0x00c81acd in DOSTATECHANGE (this=0x7f6544300ee0, AOLDSTATE=DSRUN) at dbgintfdebuggerbase.pp:3564 #26 0x00c8a672 in SETSTATE (this=0x7f6567371960, AVALUE=DSPAUSE) at dbgintfdebuggerbase.pp:5690 ---Type return to continue, or q return to quit--- #27 0x01493414 in FDBGCONTROLLERHITBREAKPOINTEVENT (this=0x7f6567371960, CONTINUE=false, BREAKPOINT=0x0) at fpdebugdebugger.pas:1219 #28 0x013eb0f3 in SENDEVENTS (this=0x7f654f275e40, CONTINUE=false) at fpdbgcontroller.pas:554 #29 0x01493c2f in DEBUGLOOPFINISHED (this=0x7f6567371960) at fpdebugdebugger.pas:1396 #30 0x01491c01 in DODEBUGLOOPFINISHEDASYNC (this=0x7f655e40bd60, DATA=0) at fpdebugdebugger.pas:816 #31 0x0069118c in PROCESSASYNCCALLQUEUE (this=0x7f6576be4430) at include/application.inc:1071 #32 0x0068f06e in IDLE (this=0x7f6576be4430, WAIT=true) at include/application.inc:396 #33 0x00691cb0 in HANDLEMESSAGE (this=0x7f6576be4430) at include/application.inc:1265 #34 0x006923b4 in RUNLOOP (this=0x7f6576be4430) at include/application.inc:1399 #35 0x006fe076 in APPRUN (this=0x7f6576be4a30, ALOOP=...) at include/interfacebase.inc:54 #36 0x00692331 in RUN (this=0x7f6576be4430) at include/application.inc:1387 #37 0x00630a8a in main () at lazarus.pp:128 Colin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Need testers for the a new debugger
Hi all, As I've written before there's a new debugger available for Lazarus. (Actually there are two new debuggers, but I'm talking about the new gdb-less debugger) The debugger has been improved a lot and I could need some help testing the thing. The debugger only works on i386 and x86_64 with Linux, Windows and OS/X. Note that on Windows it is not possible to debug x86_64 applications with a 32-bit Lazarus. And on OS/X you have to sign your Lazarus-executable, and you'll have to use a dSym-debug bundle. (see the dsymutil command) This debugger is initially started by Marc Weustink and I used some stuff from Duby, written by Dmitry Boyarintsev. The part to actually parse the debug-info and to evaluate expressions is mostly written by Martin Friebe. This code is shared with the FpGdbmiDebugger. Please report any bugs you may find. Maybe I can not help with bugs in the expression-evaluation part, which is Martin's code. To install the debugger just install the components/lazdebuggers/lazdebuggerfp.lpk package. After you've done this, go to tools-options-debugger and select the 'FpDebug internal Dwarf-debugger'. You can simply use this new debugger, but keep in mind that when you think that your application is behaving somewhat strange, it also might be a bug in the debugger, instead of a problem with your application. Happy debugging, Joost van der Sluis. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
Il 14/07/2014 23:13, Joost van der Sluis ha scritto: Hi all, As I've written before there's a new debugger available for Lazarus. (Actually there are two new debuggers, but I'm talking about the new gdb-less debugger) The debugger has been improved a lot and I could need some help testing the thing. [...] In my setup (Lazarus trunk + fpc 2.6.4) it fails to compile: fpdbglinuxclasses.pas(436,27) Error: Incompatible types: got procedure variable type of procedure(TObject) of object;Register expected procedure variable type of procedure;Register It would appear that the reason is that in fpc process.pp TProcessForkEvent is defined as a procedure as opposed to procedure of object (as required in fpdbglinuxclasses.pas). Do I need fpc 2.7 in order to test it, or there's some other reason? Giuliano -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
