<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="Zarafa HTML builder 1.0">
<TITLE></TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT STYLE="font-family: courier" SIZE=2>
> On 19/07/14 22:26, Joost van der Sluis wrote:<br>
> > > > Do you get a message on the console like 'failed to write data at<br>
> > xxxxxx'?<br>
> > ><br>
> > > Just tried it again - it doesn't seem to be consistent. The specific was<br>
> > > stepping into a routine, and the problem seems to happen when stepping<br>
> > > "into" at the first begin. Trying it just now the debugger step into in<br>
> > > these circumstances - it now exits the routine. There are lots of<br>
> > > "Failed to read data at address $10B70F08C08347F8 from processid 11321.<br>
> > > Errcode: 5<br>
> > > Failed to read data at address $E8000000C766D388 from processid 11321.<br>
> > > Errcode: 5<br>
> > > Failed to read data at address $E8000000C766D388 from processid 11321.<br>
> > > Errcode: 5<br>
> > > Failed to read data at address $E8000000C766D388 from processid 11321.<br>
> > > Errcode: 5<br>
> > > Failed to read data at address $E8000000C766D388 from processid 11321.<br>
> > > Errcode: 5<br>
> > > Failed to read data at address $E8000000C766D388 from processid 11321.<br>
> > > Errcode: 5"<br>
> ><br>
> > Can you run Lazarus in a debugger (gdb, but in principle fpdebug is also<br>
> > possible ;) ) and set a breakpoint on fpdbglinuxclasses.pas:591. This is<br>
> > the line where the error above is printed. Then please try to reproduce<br>
> > the problem, and send me a backtrace when that breakpoint is hit.<br>
> <br>
> The behavior "failed to read" messages seem rather random. I think they <br>
> may only arise when I have the "locals" window open, in which case <br>
> presumably read failures are to be expected. A backtrace (below) doesn't <br>
> look that useful. The "step into" failing on a begin failure seems <br>
> consistent, though it certainly doesn't happen on every begin.<br>
<br>
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.<br>
<br>
You are probably right that it is something unrelated, such as the watches-window.<br>
<br>
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...<br>
<br>
Joost.</FONT>
</P>
</BODY></HTML>