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.

Il 14/07/2014 23:13, Joost van der Sluis ha scritto:

[...]

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140715/a4741010/attachment.html>

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

TThread.Queue is only supported in FPC 2.7.1. Maybe try to replace it with a Application.QueueAsyncCall.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140715/e334b729/attachment.html>

Damn, I didn't think of that. Should be fixed now.

Joost.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140715/b6bf5e51/attachment-0001.html>

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 0x000000000065747d in INTRTLEVENTWAITFOR (AEVENT=0x7f6544ca5ec0) at ../unix/cthreads.pp:923
#2 0x00007f65444954c0 in ?? ()
#3 0x0000000000649e41 in RTLEVENTWAITFOR (STATE=0x7f6544ca5ec4) at ../inc/thread.inc:319
#4 0x00007fff3af7e7a0 in ?? ()
#5 0x0000000001493b5b in EXECUTEINDEBUGTHREAD (this=0x7f6567371960, AMETHOD=...) at fpdebugdebugger.pas:1379
#6 0x0000000001493f97 in PREPARECALLSTACKENTRYLIST (this=0x7f6567371960) at fpdebugdebugger.pas:1483
#7 0x000000000148fea5 in REQUESTCOUNT (this=0x7f65444954c0, ACALLSTACK=0x7f6543d982c0) at fpdebugdebugger.pas:311 #8 0x0000000000c840cc in REQUESTATLEASTCOUNT (this=0x7f65444954c0, ACALLSTACK=0x7f6543d982c0, AREQUIREDMINCOUNT=11) at dbgintfdebuggerbase.pp:4158
#9 0x0000000000c76a45 in REQUESTATLEASTCOUNT (this=0x7f656671a2c0, ACALLSTACK=0x7f6543d982c0, AREQUIREDMINCOUNT=11) at ../debugger/debugger.pp:6430
#10 0x0000000000c687d8 in HASATLEASTCOUNT (this=0x7f6543d982c0, AREQUIREDMINCOUNT=11) at ../debugger/debugger.pp:3860 #11 0x0000000000c7614e in COUNTLIMITED (this=0x7f6543d982c0, ALIMIT=11) at ../debugger/debugger.pp:6321
warning: Range for type <error type> has invalid bounds 0..-101 #12 0x0000000001345dda in BREAKPOINTCHANGED (this=0x7f65666faf50, ASENDER=0x7f6566719f60, ABREAKPOINT=0x7f654f6464a0) at ../debugger/callstackdlg.pp:692
#13 0x0000000000c6f55c in UPDATE (this=0x7f6566719f60, ITEM=0x7f654f6464a0) at ../debugger/debugger.pp:5099 #14 0x0000000000c4f72d in UPDATE (this=0x7f6566719f60, ITEM=0x7f654f6464a0) at debugmanager.pas:370
#15 0x00000000007102d9 in CHANGED (this=0x7f6544ca5ec0, ALLITEMS=128) at ../objpas/classes/collect.inc:49
#16 0x0000000000000002 in ?? ()
#17 0x0000000001217c0e in DOCHANGED (this=0x7f654f6464a0) at dbgintfmiscclasses.pas:509
#18 0x0000000000c6b90c in DOCHANGED (this=0x7f654f6464a0) at ../debugger/debugger.pp:4500
#19 0x0000000000c4ff59 in DOCHANGED (this=0x7f654f6464a0) at debugmanager.pas:452
#20 0x0000000001217ab2 in CHANGED (this=0x7f654f6464a0) at dbgintfmiscclasses.pas:498
#21 0x0000000000c80b27 in DOCHANGED (this=0x7f654f2e3dc0) at dbgintfdebuggerbase.pp:3340
#22 0x0000000001490e27 in DOCHANGED (this=0x7f654f2e3dc0) at fpdebugdebugger.pas:581
#23 0x0000000001217ab2 in CHANGED (this=0x7f654f2e3dc0) at dbgintfmiscclasses.pas:498
#24 0x0000000001490c74 in DOSTATECHANGE (this=0x7f654f2e3dc0, AOLDSTATE=DSRUN) at fpdebugdebugger.pas:538
#25 0x0000000000c81acd in DOSTATECHANGE (this=0x7f6544300ee0, AOLDSTATE=DSRUN) at dbgintfdebuggerbase.pp:3564
#26 0x0000000000c8a672 in SETSTATE (this=0x7f6567371960, AVALUE=DSPAUSE) at dbgintfdebuggerbase.pp:5690
---Type <return> to continue, or q <return> to quit--- #27 0x0000000001493414 in FDBGCONTROLLERHITBREAKPOINTEVENT (this=0x7f6567371960, CONTINUE=false, BREAKPOINT=0x0) at fpdebugdebugger.pas:1219
#28 0x00000000013eb0f3 in SENDEVENTS (this=0x7f654f275e40, CONTINUE=false) at fpdbgcontroller.pas:554
#29 0x0000000001493c2f in DEBUGLOOPFINISHED (this=0x7f6567371960) at fpdebugdebugger.pas:1396
#30 0x0000000001491c01 in DODEBUGLOOPFINISHEDASYNC (this=0x7f655e40bd60, DATA=0) at fpdebugdebugger.pas:816
#31 0x000000000069118c in PROCESSASYNCCALLQUEUE (this=0x7f6576be4430) at include/application.inc:1071
#32 0x000000000068f06e in IDLE (this=0x7f6576be4430, WAIT=true) at include/application.inc:396
#33 0x0000000000691cb0 in HANDLEMESSAGE (this=0x7f6576be4430) at include/application.inc:1265
#34 0x00000000006923b4 in RUNLOOP (this=0x7f6576be4430) at include/application.inc:1399
#35 0x00000000006fe076 in APPRUN (this=0x7f6576be4a30, ALOOP=...) at include/interfacebase.inc:54
#36 0x0000000000692331 in RUN (this=0x7f6576be4430) at include/application.inc:1387
#37 0x0000000000630a8a in main () at lazarus.pp:128

Colin

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laz_error.png
Type: image/png
Size: 31817 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140716/cda4983f/attachment-0001.png>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140716/b1f0145d/attachment.html>

2014.07.16. 9:58 keltez?ssel, Joost van der Sluis ?rta:

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

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.

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?
______________________________________________________________

Hi all,

The debugger has been improved a lot and I could need some help testing? the thing.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140719/e4686637/attachment.html>

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.patch
Type: text/x-patch
Size: 2882 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140719/7c1c6420/attachment.bin>

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 xxxxxx'?

Joost.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140719/f180baef/attachment-0001.html>

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 $E8000000C766D388 from processid 11321. Errcode: 5
Failed to read data at address $E8000000C766D388 from processid 11321. Errcode: 5
Failed to read data at address $E8000000C766D388 from processid 11321. Errcode: 5
Failed to read data at address $E8000000C766D388 from processid 11321. Errcode: 5
Failed to read data at address $E8000000C766D388 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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140719/f7f86b2d/attachment-0001.html>

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 0x000000000140925f in READDATA (this=0x7fd9e1515040, AADRESS=1, ASIZE= 2000, ADATA=0) at fpdbglinuxclasses.pas:614
#2 0x000000000149580a in DOREADDATA (this=0x7fd9f1d07e00) at fpdebugdebugger.pas:1443
#3 0x00000000014938e2 in EXECUTE (this=0x7fd9e8bb84e0) at fpdebugdebugger.pas:852
#4 0x0000000000718ad0 in THREADFUNC (PARAMETER=0x7fd9e8bb84e0) at ../unix/tthread.inc:109
#5 0x00007fd9e8bb84e0 in ?? ()
#6 0x00007fd9e154d000 in ?? ()
#7 0x00007fd9e8bb84e0 in ?? ()
#8 0x000000000064901c in SYSFREEMEM_FIXED (LOC_FREELISTS=0x20, PMC= 0x7fd9e801fb00) at ../inc/heap.inc:1154
#9 0x00007fd9e359eaa8 in ?? ()
#10 0x0000000000000000 in ?? ()

Colin

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140720/f97c368d/attachment.html>

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140721/855e9d29/attachment.html>

2014.07.21. 11:42 keltez?ssel, Joost van der Sluis ?rta:

Tried with 45950 (FPC 2.6.4) and got the attached error.

Gabor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laz_error.png
Type: image/png
Size: 7292 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140721/74380aca/attachment.png>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140721/dcb4a719/attachment.html>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140721/1e0c2f18/attachment.html>

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

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.

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

C Western 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140825/8a67ca38/attachment-0001.html>

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.

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140825/56cd5075/attachment.html>

[...] 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

Without looking at it, I have seen that with gdb too, though only for certain complier help procs (iirc chek object stuff)

Actually it does not do it for every procedure. Maybe only for those with implicit try..finally.

Can you reproduce it?

Mattias

On Mon, 14 Jul 2014 23:13:14 +0200
Joost van der Sluis 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:
$0000000000000000
more useless stack trace text...

Ubuntu 14.04 64bit
Lazarus rev 46936
FPC 2.7.1 rev 28946

R.

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.

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

I changed the setup code, so that an empty debugger exe invokes the setup dialog only if the default gdbmi debugger is selected.

Mattias

I can confirm this with fpc 2.6.4 too.

I got a better one:

Failed to read data at address $0000000000000008 from processid 4512. Errcode: 5 TApplication.HandleException Invalid floating point operation Stack trace:
$00000000013C71A2 line 582 of ../debugger/assemblerdlg.pp $000000000071DB79 line 4204 of include/control.inc $000000000071D75D line 4162 of include/control.inc $00000000004301F1
$00000000007119B1 line 1451 of include/control.inc $00000000006FB675 line 4662 of include/wincontrol.inc $00000000006FE073 line 5287 of include/wincontrol.inc $00000000004736F3 line 1443 of include/customform.inc $000000000084057E line 112 of lclmessageglue.pas
$00000000007DADEA line 3618 of gtk2/gtk2proc.inc
$00000000007EF2B1 line 1421 of gtk2/gtk2callback.inc $00000000007EF9DC line 1598 of gtk2/gtk2callback.inc $00007F6A13AB8C0F

Mattias

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]
.byte 2
.uleb128 .Ll3-.Ll2
.byte 14

.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.

[...] 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

On Fri, 21 Nov 2014 16:31:26 +0100 Reimar Grabowski 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

Mattias Gaertner wrote

On Fri, 21 Nov 2014 23:51:13 +0100 Mattias Gaertner 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
-------------- next part --------------
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));

That is a design decision. That is up to Joost and Martin to decide. You may want to create a bug report.

Mattias

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20141122/d8a9f982/attachment.html>

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

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

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

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

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.

:-) 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 's also the NextOnlyStopOnStartLine debugger-specific-option. You can try if that fixes your problem.

Regards,

Joost.

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

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.

Mattias

Mattias

More likely is that you've encountered one of the situations where "Step into" does not work. Normally it works?

Joost.

You are right. Sorry for the false alarm.
I will report, when I come back to that project.

Mattias

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.

Check if you have enabled 'Reset debugger after each run'. That crashes the new debugger. Disable it.

Mattias