GPF error when using PCTools for Windows or Plug-In for Windows as the Windows shell.

Description

The Plug-In for Windows and PCTools for Windows Desktop shells do not properly resotore some software interrupts that Delphi uses for the debugger. This causes the debugger to GPF when the Program Pause command is issued.

Solution / workaround

No true solution is known for this problem. Currently, you must either not use the Pause command or change your shell (by modifying the SHELL= line in the SYSTEM.INI) and restart Windows before using the debugger.

Some properties are not correct in watch list and evaluator.

Description

Some properties do not seem to display their correct values in the watch list and evaluator. For example, create a project that has a listbox and a button. Set the listbox's Items property so that it contains several strings. Create an OnClick handler for the button that does the following:

value := ListBox1.Items.Count;

Now, set a breakpoint on this line of code. Run the project and click the button. Execution will stop at this line of code. Display the watch list and add "ListBox1.Items.Count" to the watches. It displays a value of zero (0). However, when you step through this line of the program, you will find that the variable value contains the correct count.

Solution / workaround

No true solution is known for this problem. The only work-around that I know of is to use an intermediate variable to determine values that do not display correctly in the watch list.

Under certain conditions, when tracing into a procedure, the debugger watch window seems to get confused about the storage locations of variables.

Description

Reported by David Hillman

Here is what appears to me to be a severe bug. I am running Delphi 2.01 on NT 4.0. The summary is: under certain conditions, using labels is probably one of them, if I trace into a procedure then the debugger can be misled to think that some of its variables are stored at different locations from where the compiler actually is storing them. Moreover, I can change where the debugger thinks these variables are located by writing data to my program variables. Also, if I mess around with the situation in certain ways I crash Delphi. Here are the details:

PROJECT FILE:

program Colors19;

{ This is an attempt to port colors19.pas to Delphi. }

uses Colors19MainUnit2 in 'Colors19MainUnit2.pas';

begin
  ColorsMain;

end.

UNIT FILE:

unit Colors19MainUnit2;

interface

uses SysUtils;

procedure ColorsMain;

implementation

type goodpermtype = array[0..5] of byte;

procedure proc1(var c, d: integer; var b: boolean; 
                var goodperm: goodpermtype);
var
  i: integer;
label
  line1;
begin
line1:
  for i := 0 to 5 do goodperm[i] := goodperm[i] + 1;
  i := integer(@goodperm);
end;

procedure ColorsMain;
var
  i, c, d: integer;
  b: boolean;
  goodperm: goodpermtype;
begin
  for i := 0 to 5 do goodperm[i] := i;
  proc1(c, d, b, goodperm);
end;

end.

I compile this with optimizations off (other settings do not seem to matter) and run to the procedure call proc1(c,d,b,goodperm). Then I trace into proc1 using F7. (This is important; if I run directly to the first line of proc1 the bug doesn't happen.) Then I look at the following watches:

goodperm
ColorsMain.goodperm
@goodperm
@ColorsMain.goodperm
@i

(using hex display)
At this point ColorsMain.goodperm=[0,1,2,3,4,5] but goodperm doesn't equal the same thing. Also, @goodperm does not equal @ColorsMain.goodperm. If I continue stepping through proc1, ColorsMain.goodperm becomes [1,2,3,4,5,6].
So the compiler knows where goodperm is; the debugger doesn't. This can also be seen by executing the next line: the variable i now contains the correct address of goodperm.

I have not gotten this bug to happen without having a label (hence the useless label; in my original 1,000-line program it wasn't useless). I can change the numbers and kinds of variables in the procedure call, but not everything works: for instance, I cannot take away an integer; I can take away the boolean and replace with an integer; I can add an integer. Maybe it would happen with any three or more var parameters before the var goodperm parameter; I haven't tried all of the possible permutations.

Next, I change byte to integer in the definition of goodpermtype. Now if I trace into the first line of proc1 the value of @goodperm is zero (nil). Then if I trace past the "for i:=0 to 5" line the value of @goodperm becomes 1. So apparently the debugger thinks the value of the address of goodperm is stored at @goodperm[0] in this example.

Solution / workaround

I do not believe that having optimizations on is a general workaround for this type of bug. If I remember correctly I managed to get it to happen in other examples with optimization on. In this example it doesn't, though.

Under certain conditions, trying to set a breakpoint gives 'Breakpoint is set on line that may have been removed by the optimizer or contains no debug information' error.

Description

Reported by Greg Maurer; additional information by Arjen Broeze

Under certain conditions, trying to set a breakpoint gives 'Breakpoint is set on line that may have been removed by the optimizer or contains no debug information' error.
There are two possible causes for this problem:

1. AutoSave desktop is turned on and the file you have open is used by your program but is not included in the project file and you have recently copied the project to a different directory.
2. You are trying to set a breakpoint on a statement that is split over multiple lines.

The first one is a little tricky. Suppose you have a project that has a Form1. This form uses a unit with the name Unit2, but you Unit2 is not included in your project file (.dpr). The last time you ran Delphi you had both Form1 and Unit2 open. After closing the project, you copied the entire project to a different location.
Now when you open the project from the new location, Delphi opens Form1 from that location (since it is included in the project file), but it opens Unit2 from the old location.
When you want to set a breakpoint somewhere in that unit, Delphi won't let you since it doesn't compile that version of Unit2, but the one in the directory where Form1 is. Especially on large projects that get moved around this is a problem that can easily arise.

Solution / workaround

The solutions for both causes of the problem are simple:

For the first case, either make sure that all the files your project needs are in the project file, or close all files in the IDE and then reopen them from the directory where your project resides.
For the second case: when you have split a statement over multiple lines, you can only set the breakpoint on the last line of that statement in the editor.

Delphi's debugger does not recognise lines which end with LF, instead of CR-LF

Description

Reported by Hans-Josef Salm; checked by Chris Rankin

The situation: I had a source file that had originated on a MAC under Think Pascal. As I now know, it had some lines only ending with $0A [LF] rather than the normal sequence $0D $0A [CR-LF].
Result: Syntax checker, debugger messed up their line count. In addition, the edit/search-function when searching only the source code of one file would give a weird error and occasionally blow the system.

Note from checker:
I was able to reproduce the error with the debugger, but not the error with the edit/search function. Interestingly enough, Delphi has no trouble saving, loading and compiling with LF-terminated lines. However I was unable to persuade the editor to replace the LFs with CR-LFs.

There is a limitation in the integrated debugger: It has no breakpoint indicators past the 32766th source code line.

Description

Reported by James Samples; confirmed by Markus Gölzner

(This was posted on borland.public.delphi.ide)
James Samples:
Writing away when I notice that the breakpoint indicators are not showing up any more. And I need 'em. They mysteriously end at line 32766 in the editor. Please do not tell me this is the limit of the integrated debugger.

Markus Gölzner:
Yes, there is a limit (in the compiler, linker, debugger or IDE). We encountered the same problem and opened a support incident with Borland Support Germany. They told us it is a bug and their developers are aware of the problem. Maybe D4 will solve this issue. Currently the only solution I know is to split such a big unit into smaller ones.