|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||||||||
|
|||||||||||||||||
|
|||||||||||||||||
|
|||||||||||||||||
|
|||||||||||||||||
|
|
||||||||
|
|||||||||
|
|
|
Delphi DocumentationSupport |
|
 DELPHI DEVELOPER SUPPORT
Areas of concentration under: debugger
Area: debugger\breakpoints Problem: Debugging an app remotely, the point of execution will stop at the main begin of the program as if it had a breakpoint. Selecting run also will not advance to the breakpoints. [Automation Breaker] Automation doesn't proceed when it is not advancing as expected. Suite can't ignore the problem and proceed as it won't know this bug from any potential bugs. Area: debugger\breakpoints Problem: source breakpoints in a dynamically loaded dll don't break after the dll has been loaded and unloaded Area: debugger\breakpoints Problem: If you set a breakpoint and then delete a line above it so the line with the breakpoint moves up in the editor, the breakpoint glyph and highlight disappear but the breakpoint is still set. Steps: Create a default app with a TButton on the form. Override the OnClick event to have the code: procedure TForm1.Button1Click(Sender: TObject); begin Caption := 'test'; end; Set a breakpoint on the Caption line. Put the cursor on the blank line above it and hit the delete key to remove the blank line. Notice the breakpoint glyph and highlight disappear. View| Debug Windows| Breakpoints and you still see the breakpoint set. Run the app and click the button and you will stop at the breakpoint. Area: debugger\breakpoints Problem: Breakpoint tracking not quite working when moving the line associated with the breakpoint. Glyph and red highlight on a different line from the source code and where the real breakpoint is set. Steps: Create a default app with a TButton on the form. Override the OnClick event to have the code: procedure TForm1.Button1Click(Sender: TObject); begin Caption := 'test'; end; Set a breakpoint on the Caption line. Put the cursor on the beginning of the line and hit the enter key to move the Caption line down. Notice the breakpoint glyph and highlight stay above the Caption line. View| Debug Windows| Breakpoints and you will see the breakpoint set on the line where the Caption source currently is. Run the app and click the button and you will stop at the Caption line and it will have the red highlight and glyph but so does the line above it. Now try to delete the breakpoint above Caption line and notice have to click on the gutter glyph twice to get it to go away. Area: debugger\breakpoints Problem: After a module load breakpoint is triggered, the CPU view is brought up despite the presence of source code. Area: debugger\breakpoints Problem: Run to cursor does not find proper source when attempted from the initialization section of a DLL. Area: debugger\breakpoints Problem: Breakpoint not properly setting on source line within a "With ... do" statement block when there is only one statement within the block. Breakpoint is setting on the "With" statement line, instead of on the "apparent" source line. The breakpoint which highlights the "Edit1.Text" line isn't being honored. Moving the breakpoint to the "With" statement stops execution, but the highlighted line is not the expected source line. If there is more than one line within the "With" block, the blue dots appear in front of the source lines correctly and the breakpoints on those lines work properly. Steps:
Code example:
Create new project.
Place a TEdit onto the form.
Create the following procedure and call it from
within the FormCreate event.
procedure UpdateEdit(Sender: TObject);
begin
with Form1 // blue dot here
do
begin
Edit1.Text := IntToStr(Edit1.Left);
// no dot on above line
// and breakpoint doesn't stop execution on the
above line
end;
end;
Area: debugger\breakpoints Problem: Can't set a break point on line #32768 or higher in a huge unit. Well, you can set it, but it's treated as invalid and will never cause a break. Steps: 1. File | New Application 2. Drop a TButton on the form. 3. Add an OnClick handler for Button1 and make it do a ShowMessage. 4. Insert enough empty lines before the OnClick event handler so that the ShowMessage is on a line number higher than 32768. 5. Set a breakpoint on the ShowMessage. 6. Hit F9 to run. 7. You'll see the breakpoint get invalidated and it will never trigger a break. Area: debugger\call stack Problem: When an exception is encountered in a system DLL, the call stack is completely empty. Steps:
Start Delphi
Drop a button and add the following in the OnClick
handler:
GetMenuString(handle, 1, nil, 10, 20);
Run and click the button.
You get the exception dialog
View|Debug windows|Call stack
Note the stack is empty
In Delphi3, TForm1.Button1Click was shown on the
stack
Area: debugger\call stack Problem: Area: debugger\cpu Problem: When using Goto Address in the disassembly pane and entering eip, you are actually taken to one byte past the current eip. Using "Goto Current EIP" menu item works correctly Steps: File| New Application F8 three times. View| Debug windows| CPU Select an address below the current eip. Ctrl+ G to bring up the Goto address dialog. Enter eip and click OK. Compare the address you are at in the disassembly pane with the EIP register in the register pane, they are not the same. Area: debugger\cpu Problem:
It appears to be impossible to enter the literal dollar
sign ('$') as the value of a byte in the memory pane
of the CPU view.
Steps:
1. Start debugging an app
2. In the CPU view, click on a memory location.
3. Type the dollar key ($). This pops up the "Enter
New Value" dialog box, and places the $ into the
box. Press enter.
Since $ evaluates to nothing, this puts a zero in the
memory cell.
4. Type the $ with single quotes around it. ('$').
This should evaluate to a character expression, but
this also puts a zero in the memory cell. Again not
what I want, and this is a bug because the
expression is valid and should evaluate to a
character.
5. Note that if you type other characters like A or B,
step 3 works OK. Also, if you type a string like ABC,
this also inserts the literal string 'abc' into memory in
three consecutive bytes.
Area: debugger\cpu Problem: asm AAD end; shows up as aad 0x0a in the CPU window similar bug with AAM Steps: Create a program with asm aad aam end; and run to the aad line and view the CPU. Area: debugger\cpu Problem: The CPU window doesn't properly handle multi-line statements. If you code like this: asm rep stosb the CPU window will only show the REP line. Steps: Create a program with: var i1, i2: integer; begin i1 := 1; i2:= 2; asm mov eax, i1 lea edi, i2 mov ecx, 4 rep stosb end; Set a breakpoint and look in the CPU View. Area: debugger\cpu Problem: Debugger CPU view does not display the symbol for the destination of a call instruction when that destination is an imported symbol. However, it seems to know what the symbol is, since if you single-step through the call and arrive at the import thunk, the debugger will show the symbol at the address of the thunk. Steps:
1. Make a program that calls the MessageBeep API
function, like this:
procedure TForm1.Button1Click(Sender: TObject);
begin
MessageBeep($ffffffff);
end;
2. Set a breakpoint on the call, and run to that
point.
3. View|Debug|CPU. See the disassembly,
push $ff
call -$0003e7b
This should be displayed as:
call MessageBeep
4. Note that if you single-step into the call thunk,
the symbol will be correctly displayed:
MessageBeep:
jmp dword ptd [$0043f474]
Area: debugger\evaluator Problem: Watch modifiers no longer work In a debugging session, you could watch an integer expression and add ,x to it to get a hexadecimal view. So 16,x would evaluate to 10 This no longer works Steps: Start debugging a program by stepping into it Add a watch on 16,x Delphi 4 produces 16 Delphi 3 would produce 10 Area: debugger\evaluator Problem: When an exception is encountered in a system DLL, the call stack is completely empty. In Delphi3, the last user function was displayed on the stack. Area: debugger\evaluator Problem: The debugger fails to handle the Int64 to Double typecast correctly, and in doing so corrupts memory and prevents further compilations from taking place in the IDE. The Evaluator is returning an incorrect date but I do not see the internal error or any other problems. Also it does give the correct date with DateToStr(Now) Area: debugger\evaluator Problem: Apparently in Delphi 3, you could evaluate symbolic constants even when you were not debugging as long as the project had been compiled. This no longer works in Delphi 4. Steps:
Start Delphi
Project|View source
Add the following code above the main program
block
const
foo = 10;
Project|Compile
Run|Evaluate foo
In Delphi3, this would give you 10, now you get
undefined symbol.
Area: debugger\evaluator Problem: Debugger Evaluate gives "Expression illegal in evaluator" error for an otherwise perfectly legal use of AS. Steps: 1. Make a blank form with a Button and a Edit control. 2. For the button's OnClick handler use this: procedure TForm1.Button1Click(Sender: TObject); var p: TControl; begin Edit1.Text := 'hi there'; p := Edit1; p.Visible := True; (p as TEdit).Visible := True; end; Note that the p.Visible and (p as TEdit).Visible code compiles correctly. 3. Run to the line p.Visible := True, so p has a reasonable value. 4. Run|Evaluate the following expressions: a) p b) p as TControl c) p as TEdit d) p as TWinControl The first two of these evaluate properly. The last two ought to work (and indeed do compile and run if you write the code into the OnClick event), but give the "Expression illegal" error. Area: debugger\evaluator Problem: The evaluator incorrectly displays the value of register variables in this case. Steps: 1. New app 2. create a method on form (e.g. FormCreate) 3. Write this code: var Result: DWORD; begin Result := $4004E50; if Result = 0 then Beep; end; 4. Set a breakpoint on the "if Result..." line, run to breakpoint 5. Evaluate Result,x and see that the value is correct. 6. Evaluate LongRec(Result).Lo,x - the result may or may not be correct 7. Evaluate Result,x again, the result is definitely incorrect. Area: debugger\evaluator Problem: The Evaluate/Modify dialog does not apply formatting when re-evaluating expressions after being modified. Steps: Drop a button on a form and have its OnClick method read as follows. var VComp; procedure Use(var X); begin end; procedure Form1.Button1Click(Sender: TObject); begin VComp := 0; Use(VComp); //Set Breakpoint here! end; Set the breakpoint, run and click the button. Evaluate VComp,f18 and modify it to be -9.22337203685477580e+18. Notice that when you press RETURN, the result box now displays only -9.2233720369e+18. As if the format specifier f11 were being used. Area: debugger\evaluator view Problem: The Evaluate / Modify dialog is too small for the controls. The last combo box is cut off Steps: * In Code Editor, right click and select Evalute / Modify Area: debugger\event log view Problem: Address Breakpoints are being logged as Data Breakpoint in the event log. Steps: F8 a default app to step it. View| Debug Windows| CPU. Set an address breakpoint. F9 to run to the address breakpoint. View| Debug Windows| Event Log and look for an address breakpoint message. Notice you find a data breakpoint instead. Area: debugger\exceptions Problem: debugger doesn't stop at the source code line and displays a general exception windows (with checkbox to pop the CPU window) on a variety of delphi (or BDE) generated exceptions. Steps:
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics,
Controls, Forms, Dialogs,
ComCtrls;
type
TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.DFM}
procedure TForm1.FormCreate(Sender: TObject);
begin
StrToInt('abc'); // line is not highlighted
end;
end.
Area: debugger\exceptions Problem: The debugger no longer stops on the line that raises an exception where in Delphi 3 it did, it stops on the line after. Steps:
1. File | New Application
2. Drop a button on form1
3. On the button click write the following:
raise exception.create('bogus');
4. Run | Run
5. Press button1
// Notice where the excution point in the editor is,
it's _after_ the line of code that raised the
exception. In D3 the current execution point was
on the exception.
Area: debugger\execution Problem: The debugger is not locating the right line of code on a raised exception. Area: debugger\execution Problem: Under Win95, the debugger is frequently unable to perform a program reset after an access violation has occured. Once this situation has been encountered, it no longer possible to debug the application in the IDE and very often is is not even possible to kill the IDE process using PVIEW. Steps: Run the attached application and click the button. Note the AV in BDE. Program Reset. Note the same AV occurs again. Wait awhile and you will get timeout error dialog. Choose Abort. Now try to run and you will get an assertion failure. Test under Delphi 3 or under NT and the program reset works fine Area: debugger\execution Problem: With Integrated debugging on there is a noticable delay in running and stopping an app. On a 166 with 128 Meg memnory running NT4 SP3 it takes 12-14 seconds for an application to start and about the same time for control to return to the IDE when closing the application. Turning Integrated debugging off makes an instant start and an instant stop. Steps: 1. Take a resonable size application. 2. Turn intergated debugging on 3. Run and take a note of the time between the end of linkinbg and the application running. 4. Stop the app and note the time between closing the app and control returning to the IDE. 5. Repeat steps 3 and 4 with Integrated debuggoing turned OFF. Substantial difference. Area: debugger\execution Problem: if you specify an output directory and do not use a full path, the debugger can not find the exe. Steps: Create a new empty directory c:\temp\bug Create an empty subdirectory c:\temp\bug\bin Launch D4 - This creates a new empty application Save the project and the unit in c:\temp\bug In project/options, set output directory to "bin" Press F9 Notice the error that it can't find the bin\project1.exe but it is there. Area: debugger\execution Problem: IDE does not always set itself as the foreground window when debugging events (such as dialogs) demand this. Result: When the program is halted, the user is not notified while Delphi is waiting for response. Area: debugger\inspector Problem: The Eval (?) buttons are not working for the dynamic properties. The value is not being shown so all you see is the getter and setter function names. Steps: With a default app set a breakpoint on the Application.Run line in the project source file. F9 to run to that line. Put the cursor on Form1 in the line above Application.Run. Alt+ F5 to bring up an inspector on Form1. Click on the Properties tab and scroll until you find Caption. Click on it so you see the ? button. Now click the ? button and notice you do not get the value of caption. The only change is a space added to the begging of the text. Area: debugger\inspector Problem: Debug Inspector drop down list: Selecting the empty item on the drop down list will give list index out of bound (0) error ! Steps: - File | New Application - F8 - Run | Inspector - Type "Application" as expressoin, click OK // On the Inspector - Open the drop down box on the inspector - Select the empty item // List index out of bound (0) Workaround: This does not prevent Delphi from functioning correctly outside of the error message. Area: debugger\inspector Problem: Unable to change the value of a variant from an inspector. Steps: Select File|New Application. Drop a button on the form and have its OnClick method read as follows. procedure TForm1.Button1Click(Sender: TObject); var V: Variant; begin V := 'hello'; Caption := V; //Set Breakpoint here! end; Set the breakpoint, run the app and select the button. When stopped at the breakpoint, inspect "V". Any attempt to change the value of "V" will result in the error "Cannot change value." Area: debugger\inspector Problem: In the properties page of the inspector, you can not subinpsect or descend. You also can not subinspect or descend any data memebers that are not pointers. Steps: With a default app run to the line Application.Run. Run| Inspect Form1. Click the properties tab. Right click on any property and notice inspect and descend are disabled. However from the Run| Inspect menu you can enter Form1.Caption, for example, and it brings up a valid inspector. Now click on the Data tab and notice the only data member that has the menus enabled is the FActionLists which is a pointer. Area: debugger\inspector Problem: Inspecting a highlighted block displays erroneous results. Steps: With a new application, drop a button on a form and use the following for its OnClick event. procedure TForm1.Button1Click(Sender: TObject); type TStuff = (a, b, c); var Stuff: TStuff; begin Stuff := a; ShowMessage(IntToStr(Ord(Stuff))); end; Set a breakpoint on the line with "ShowMessage", run and click the form's button. Highlight as a block "Stuff := a;" and select Run|Inspect. You will see the line entered as the expression in the Inspect dialog. If you hit Ok, the debug inspector will display "Stuff := a;: TStuff ebx" as the expression and "Stuff := a;" in the data area. Area: debugger\interaction with ide Problem: When an exception is raised, the message pops up, but after pressing Ok, the editor no longer takes you to the line of code that caused the exception. Worked in D3. Area: debugger\interaction with ide Problem: Can not save a data breakpoint. You will get an error: Format '%,' invalid or incompatible with argument. Area: debugger\interaction with ide Problem: Can not save a Module Load breakpoint. You will get an error: Format '%,' invalid or incompatible with argument. Area: debugger\interaction with ide Problem: The IDE currently has a delay problem when tabbing to files open in the editor. After compiling a project, if you switch editor tabs the IDE can take up to several seconds to actually switch tabs. The problem seems to occur most frequently when switching between a file that is part of the project being compiled and an unassociated file. Steps: 1. File | New application 2. Open a .pas file that is not in the current project. 3. In the editor switch tabs back to unit1.pas from the current new project 4. Project | Compile 5. In the editor switch tabs to the file that is not part of the project. // Notice that there is a delay in displaying the file. Once you have viewed the file switching between files causes no delay. The delay occurs after each compile. Area: debugger\interaction with ide Problem: I've noticed that, while stepping through a unit's initialization section, often the "line about to be executed" pointer often points at the "end.". But the end. statement does not have a little blue dot indicating that code was generated for that line. Furthermore you cannot set a breakpoint on that line even though there is code there. Steps:
New app. Write the following.
var
X : integer;
implementation
{$R *.DFM}
initialization // gets a blue dot
X := 10; // gets a blue dot
end. // does not get a dot, but there is code
here.
Area: debugger\interaction with ide Problem: This is a suggestion for a feature. It would be nice if I could click on a line and a window would pop up with the values of variables needed to get me to that line. For example if I would only get to a line if variable A is set to zero it would be nice if a window would show me that. Often in programming there are multiple variable which have to be set to specific values for a line to be executed. When I am debugging I would like to know what those are and have to look back. That can be difficult and time consuming when there are thousands of lines of code. Area: debugger\kernel Problem: If when running a client Corba application which is talking to a Corba Server within debuger, if applying an update fails for some reason, and you then close the application and rerun it, you get an exception in BorDBK40.dll Area: debugger\module view Problem: After setting and hitting a data breakpoint the module view gets messed up and can cause access violations. Steps: With a default app, F8 on NT Run| Add Breakpoint| Data Breakpoint and enter Form1 View| Debug Windows| Modules. F9 to run to the data breakpoint. Run| Program Reset and notice in the module view it still shows a process even though none is stopped in the debugger. F8 to start a new debug session. In the module view click to the left of a module to try to set a module load breakpoint and you will either get a list index out of bounds or an access violation. At one point the IDE hung. Area: debugger\module view Problem: Using the Run| Add Breakpoint| Module Load Breakpoint, you do not see the module listed in the module view with the red dot until after you start your debug session. Steps: View| Debug Windows| Modules Run| Add Breakpoint| Module Load Breakpoint Enter user32.dll and click OK Notice the modules pane is empty. You should see user32.dll with a red dot in front and have it indicate that it is not loaded. F8 and look in the Module View again and now you see it listed. Area: debugger\module view Problem: Modules window does not have a close box in the upper-left corner. Steps: 1. Open Modules window. 2. Try to close it by dbl-clicking in the upper-left corner of the window. Can't do it, because there is no close icon. Area: debugger\module view Problem: On Win95 the debugger does not stop if a module load breakpoint is set on user32.dll. Steps: On Win95 with a default app: Run| Add Breakpoint| Module Load Breakpoint and enter user32.dll. View| Debug Windows| Modules and check that the breakpoint is set. F9. You should be stopped in the cpu view but the app runs instead. Area: debugger\multi-process Problem: Area: debugger\remote debugging Problem: borrdbg.exe is creates a new log file everytime it is ran. We need to change it so it always uses the same file and overwrites it each time. Area: debugger\remote debugging Problem: If you terminate the Remote Debugger while debugging a project, the IDE hangs. Steps: Setup remote debugging. Start debugging a project Terminate the remote debugger. //hang. Area: debugger\remote debugging Problem: Remote debugger install The "borderline" (lines of stars) for the title of the readme appears too short for the title in the install (but looks OK if read in notepad). This is a fixed length vs variable length issue. I'm not sure if it can be fixed. Perhaps in the future we should try to use a character other than *. Area: debugger\stepping Problem: Stepping in the debugger is acting like Run not step. Area: debugger\stepping Problem: Following steps will cause AV in Coride40.bpl Steps: - File | New Application - F8 to step over - Run | Parmeter : Click Load button // Error message will say : Could not find program '' - Click OK - F8 again // AV in address 200AB35A in module CorIde40.bpl. Read of address 0000007D Area: debugger\stepping Problem: Customer Quote" The System.dcu file in the SLIB directory does not contain stack frames for the procedures that are implemented in BASM. The documentation says that all files (and all procedures in those files) in the SLIB directory are compiled with stack frames Pease add conditional compiles to include the stack frames to the BASM procedures and functions - this will make it a lot easier for third-party tools suppliers. " Area: debugger\watches Problem: Loss of functionality between D3-D4. Basic function watches in D4 no longer work instead they display "Inaccessible value". Steps: 1. File | New Application 2. Add a TButton to Form1 3. Run | Run (in the debugger) 4. Pause the application 5. Add a watch on Form1.Button1.Canfocus // Notice that this cannot be evaluated. This used to work in D3. Area: debugger\watches Problem: If the watch window is open but covered up by another winodw, using Ctrl+ F5 to add a new watch does not bring the watch window to the front. It is easy to think the command didn't work and to try it a couple if times. When you finally use a command to view the watch window you notice you have multiple watches for the same thing. Steps: With a default app, View| Debug Windows| Watches. Now give the code editor focus so it covers up the watch window. Click in the editor on Form1 so the cursor is there. Ctrl+ F5 and notice it appears as if nothing happened. If the user forgot they had the watch window open they would just think the command didn't work and would try it again. You have to use the menu or command key to be able to see the watch window at this point.
NOTE: These listings are for informational use only. It is not intended for use when calling Borland's Developer Support Department. If you have any suggestions or complaints about these 'Delphi Enhancements and Fixes' pages, please contact the Delphi Administrator. This e-mail address is not intended for support issues. |
|
||
|
|
|
|||
|
|||||
|
|
||||
 |
|||||
|
|||||
| Made in Borland® Copyright© 1994-2003 Borland Software Corporation. All rights reserved. Report Piracy, Legal Notices, Privacy Policy Last Modified Thursday, 22-Mar-2001 18:57:04 EST |
|||||
