[Lazarus] Need testers for the a new debugger

[C Western]

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