View Issue Details

IDProjectCategoryView StatusLast Update
0017148LazarusDebuggerpublic2011-12-01 11:25
ReporterColin_HaywoodAssigned ToMartin Friebe 
PrioritynormalSeverityminorReproducibilityrandom
Status closedResolutionfixed 
PlatformOStested on Windows Vista64 & XP32OS Version
Product Version0.9.28.2Product Buildbeta 
Target Version0.9.30Fixed in Version0.9.29 (SVN) 
Summary0017148: Register window not filled out when program starts
DescriptionThe "Registers" debug window only fills up with information if the window is opened after hitting a breakpoint. If the window is open to start with no information ever appears.

With the program specified in the "Steps to Reproduce" section it seemed to reliably behave this way; but with my main project it did not always work if the breakpoint was put in the subprocedure (the only reliable way to get the register info was to have the window closed, breakpoint the main program code, run the program to this breakpoint THEN open the window and continue).

AFAICR the debug windows all worked fine under 0.9.26.2.
Steps To ReproduceUse this simple program

program Project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes;

//{$IFDEF WINDOWS}{$R project1.rc}{$ENDIF}

procedure SomeProcedure;
  begin
    writeln('In SomeProcedure');
end;

begin
  writeln('In Main');
  SomeProcedure;
  Readln;
end.

Open the register window before starting the program. With a breakpoint at any (valid) point in the code run the program. The breakpoint will be hit but the register window will not be filled with information.

If on the other hand you have the register window closed, then start the program and when the breakpoint is reached open it, it will have info.
Additional InformationI also had some problems with F8-stepping through (Intel-syntax, using $ASMMODE INTEL) assembly language code when it would step first into some system code and then I had to hit F8 again to return to my actual program. In the assembler window (that popped up out of my control) some lines of the program source were replaced with rather odd assembler code (eg movl %edi, %edi) that looked nothing like the source I had written. Unfortunately this bug is somewhat tricky to reproduce.
TagsNo tags attached.
Fixed in Revision28138
LazTarget1.0
Widgetset
Attached Files

Activities

Martin Friebe

2010-11-08 01:20

manager   ~0042874

The registers should work in rev 28138 and up.

Please test and close if ok.

If the intel/f8 issue still exists, please open a separate report for this

Issue History

Date Modified Username Field Change
2010-08-10 19:02 Colin_Haywood New Issue
2010-08-10 19:02 Colin_Haywood Widgetset => Win32/Win64
2010-10-29 12:55 Vincent Snijders LazTarget => -
2010-10-29 12:55 Vincent Snijders Assigned To => Marc Weustink
2010-10-29 12:55 Vincent Snijders Status new => assigned
2010-10-29 12:56 Vincent Snijders Category IDE => Debugger
2010-11-08 01:16 Martin Friebe Assigned To Marc Weustink => Martin Friebe
2010-11-08 01:20 Martin Friebe Fixed in Revision => 28138
2010-11-08 01:20 Martin Friebe LazTarget - => 1.0
2010-11-08 01:20 Martin Friebe Widgetset Win32/Win64 =>
2010-11-08 01:20 Martin Friebe Status assigned => resolved
2010-11-08 01:20 Martin Friebe Fixed in Version => 0.9.29 (SVN)
2010-11-08 01:20 Martin Friebe Resolution open => fixed
2010-11-08 01:20 Martin Friebe Note Added: 0042874
2010-11-08 01:20 Martin Friebe Target Version => 0.9.30
2011-12-01 11:25 Marc Weustink Status resolved => closed