Sometimes when debugging, specifically when catching an exception and following through destructors called, Delphi steps through a lot of assembly code. Hit Shift+F8 appears to cause mayhem.
Can I tell the debugger to skip assembly code automatically?
In my experience, the vast majority of such assembly code is in VCL or RTL units.
If you compile with "Debug .dcu's" disabled then the debugger will not step through this code. However, it will also not step through any other VCL/RTL code either - assembler or Pascal. It will still step through any code that is not part of the VCL/RTL, assuming you have the Debug information option enabled for the project.
Whether turning off VCL/RTL debug units makes debugging any particular issue you may have easier or harder will of course depend on your particular circumstances, but usually what is going on inside the VCL/RTL code is of little consequence unless and until you have eliminated the possibility of some error in your own code and then need to investigate a potential bug in the VCL/RTL itself.
For myself, I have "Debug .dcus" turned OFF unless I need them ON.
Your mileage may vary.
If you see assembler code, you probably are in the Alt-F2 CPU view. Just close the CPU view (escape key on old Delphi, or close its tabs), and you'll continue stepping within pascal source code (e.g. press F7 or F8).
If you see assembler code in the middle of a .pas file (in an asm ... end block), then you can try going to the end of it (at end level) and press F4 (shift F8 is buggy). But be aware that it may quit not at the end but in an internal ret assembler op code. So my personal advice is, if you do not know about assembler, to display the Call Stack (this window displays the function calls that brought you to your current program location and the arguments passed to each function call) and double-click on the parent caller. This will be always safe.
For additional info about debugging, this e.g. this article.
You can use the {$D-} directive to switch off debugging for a block of code. I think this will allow you to achieve what you want.
Also - dont use shift F8 in assembly code, I believe it causes all sorts of trouble - better to place your cursor after the block and F4 down to that.
Related
I am trying to debug a dense piece of code with multiple function calls in single lines. I want to single step through all the code that I have written, but in doing that I keep finding myself in the supplied source code, including the assembler code.
This is happening at a client's site on his machine running XE5. It doesn't happen on my own code, running XE2 and XE4.
What is the magic setting that makes this work they way I want?
The best you can do is make sure that Debug DCUs is disabled in the project options. But even doing that sometimes is not sufficient to stop yourself landing in RTL code, in modern Delphi versions. I suspect that you have Debug DCUs disabled and are being caught out by this behaviour change.
The only thing you can do is get used to knowing when to use step out (F8) rather than step in (F7), and being able to escape from a function as quickly as possible. Usually that involves putting the cursor on the last line, running to cursor (F4), and stepping in again.
You might also be interested in the Selective Debugging tool by Uwe Raabe which allows you a fine grained selection for which DCUs are used with or without debug information.
I'm using Delphi XE and I've got a project group containing the main application and a DUnit test application. From time to time, I go to the DUnit test application to add some tests and run existing one.
Some test code generates exceptions which are handled by the application, but displayed multiple time by the Delphi Debugger as I'm used to running the test application using the F9 shortcut like I do with standard application: this is not very handy in that case.
I know about the SHIFT+CTRL+F9 shortcut to run without debugging and that's great when I remember to use it but I often find myself hitting F9, then grunting, then closing the test application, then hitting SHIFT+CTRL+F9. What a lost of time.
So my question: is there a better way ? Can I define some settings or use some expert to make that particular application run without debugging by default ? Surely I'm not the only one having this issue.
Thanks in advance.
Nope (at least not up until D2009). Run without debugging is an IDE thing. A comiler flag would not help as it is the IDE that hooks the exe, not the other way around. The only place where you could have such an option would be in the project settings. But having it could make the IDE slightly confusing as the normal distinction between Run and Run without debugging would be overruled. You would then need a third option I guess, "Run", "Run with debugging" and "Run without debugging" where the simple "Run" would take its cue from the project options.
Disable "notify on language exceptions".
Add the run-without-debugging icon to the toolbar. Your problem is you forget the hotkey, and click the icon. So remove the other icon, or move them both around, like this:
The bigger your application grows, I find, the slower the debugger startup gets. I run without debugging about 99% of the time now, because the startup time of my app goes from 2 seconds, to 2 minutes, because it uses a lot of runtime packages, and every BPL load in the debugger comes at a huge hit to my productivity. So long, slow painful experience has re-educated me to ask myself "Do I really need to debug?". If I don't, I click the nice green icon (in XE) that replaces the exclamation mark icon in older versions. (A smart UI improvement I think.). In previous delphi versions, the green play button meant "run with debugging".
Well kind of. You can use non-breaking breakpoints[McKeeth][Jensen] to ignore the exceptions you are forcing in your tests. The only way to save breakpoints I know of is to enable Tools > Options > Autosave > Project desktop.
I understand your problem, but personally I don't think it's that useful having an option to change the default behaviour of F9.
You have some test cases which are expected to raise exceptions. (NOTE: I'm actually thinking tests that check for particular exceptions when bad inputs are given. Not exceptions being 'handled' by application.) And I agree there is no point in being alerted to these in most circumstances. However, an exception in other test cases would be a problem that I'd like to be alerted to as quickly as possible.
So my preferred running mode is to usually be notified of exceptions. And have explicit code in certain test cases that explicitly disables exception notification only within the context of the tests that will trigger production code exceptions.
I have a technique that works very well for this.
In a test that's expected to raise exceptions I write the following code:
begin
TIDEDebugTools.DisableBreakOnExceptions;
try
//Test code ...
finally
TIDEDebugTools.EnableBreakOnExceptions;
end;
end;
I guess you want the source code for those 2 methods? :)
unit IDEDebugTools;
interface
type
TIDEDebugTools = class(TObject)
public
class procedure DisableBreakOnExceptions;
class procedure EnableBreakOnExceptions;
end;
implementation
{ TIDEDebugTools }
class procedure TIDEDebugTools.DisableBreakOnExceptions;
begin
end;
class procedure TIDEDebugTools.EnableBreakOnExceptions;
begin
end;
end.
Where's the rest you ask?
There isn't any - that's it!
... but there are a few instructions you need to follow:
Add a breakpoint to each of the method.
Edit the breakpoint-properties.
Select advanced options.
Turn off the "Break" option
And turn on the "Ignore subsequent exceptions" and "Handle subsequent exceptions" options for the appropriate respective method.
This is close to jpfollenius' idea for compiler directive options. It also addresses David's concern about how you enable those exceptions again. All you need to do is disable the breakpoints to get all exceptions reported again.
Additional thoughts:
You mention:
Some test code generates exceptions which are handled by the application.
If your application is handling all these exceptions, then:
Are your tests localised enough? If you're testing such large chunks of functionality, the tests are more like system tests - and can be very difficult to maintain.
Are you making too much use of exceptions for main-line business processing?
Is your application doing a whole lot of inappropriate exception swallowing?
Basically it seems fishy to me that your wording suggested "a bunch of exceptions you're not too concerned about because they're 'handled'". Many people make the mistake of thinking they're handling a exceptions when really they're just swallowing them and hiding the root problems.
Whenever I rebuild my application and try to step into a break-point the CPU window always appears. From what I understand the CPU window appears when DCU does not match up with the source file, however, in my case the DCU's are defintely being re-compiled and there are no old ones lying around or anything like that.
The strange thing here is if I close down the application and re-open the project, place the breakpoint and run it works fine. I can even modify files and just press F9 to run the project and it works fine....it only seems to be when I rebuild the project (via IDE Project menu or the project context menu) that this CPU window never breaks into the source (even though it can find it!).
I also noticed in the callstack a unit called Generics is always the top of the stack, never the unit my break point is in, this is no way related to where my break point is.
Any ideas?
Try checking your Delphi event log.
Sometimes Windows itself will write an OutputDebugString and then trigger a breakpoint when your application has done something very bad, e.g.:
HEAP[Project1.exe]: HEAP: Free Heap block 32959a8 modified at 32959c0 after it was freed
Windows has triggered a breakpoint in Project1.exe.
This may be due to a corruption of the heap, and indicates a bug in Project1.exe or any of the DLLs it has loaded.
The output window may have more diagnostic information
It can also be Application Verifier (if you're using it; if you're not you should) telling you about a problem.
Here I found suggestion to check Ignore non-user breakpoints in Debugger Options (D2009).
I am doing some refactoring of my Delphi project. I want to be able to make a change, then see all the places in the project that break due to that change. Similar to how Eclipse lists all the compile errors for a project (in Java).
In Delphi, I can make a change, then recompile my project, but the compiler stops when it finds the first Unit that does not compile. I have to fix that Unit, compile again, which will then show me the next error, etc etc.
I want to be able to see all the compile errors in the project at once. Then I can decide if the change is worth doing or not. For example, if the change will require hand fixing of 50 separate source files, it's not worth doing. But if it only breaks 2 files then that's an easy change to make.
Is there any way to do this in Delphi? Can I tell the compiler to keep going even after finding a Unit that does not compile?
I am using Delphi 2010
Delphi units, as a modularity feature, are conceptually at a similar level to Java jars or .NET assemblies; they compile to individual files. In neither Java nor .NET can you compile dependent modules when you have compile errors in a referenced module.
The reason they are more granular than .NET assemblies etc. owes to their history. They were designed in part around the segmented x86 architecture; the data associated with any one unit could not be any larger than 64KB. Similarly, units served as a natural division between near code and far code. If you're familiar with 16-bit x86, you'll know that pointers to far data required a value for the segment as well as the offset, while near data only needed an offset. Calling near code was also faster than calling far code. Programs were also smaller and less complex back then; the unit was a reasonable granularity of module for an entire subsystem's worth of behaviour. This is much less the case today.
There's no way to do that with the Delphi compiler, but if you're considering making a breaking change to some part of a unit's public interface, you can use the refactoring tools that come with the IDE to find all references to whatever it is you're about to change before you change it, which will give you the information you're looking for.
The Delphi compiler already tries to compile as much as it can.
Unfortunately, very often, an error is critical enough to prevent the compiler to move past the error as it cannot make an assumption as to what the code should be it if were compilable.
Moreover, very often, the errors a compiler can give after the 1st error has been encountered are not reliable and may even disappear after the 1st error has been fixed. (witnessed by all the red squiggly lines appearing and disappearing when you type)
What the compiler does however is to provide all the hints and warnings (which are called errors for some other compilers).
You can use Ctrl-Shift-Enter to see all occurances of the variable, property, method or wahtever is currently under the cursor. With that information you can decide to do your changes or not.
Alas, with the current version this feature doesn't work as reliable as it should.
Debug breakpoint's works fine in all other 38 units of my system. But, in my DataModule, that have +- 10.000 lines, delphi disables then after I launch by F9/F8/F7. In any part of source that unit, even on obrigatory steps like OnCreate, SQLConnection.Active:=true, etc.
Detail: works fine until +- 20 days ago.
I'm using D7 and have all sources of components also.
Thanks
Felipe
Try doing a full build (Shift+F9). If that does not work, then what happens if you simulate a breakpoint in code with the below?
asm int 3 end;
Check for multiple copies of your source file for the datamodule. Sometimes the code you think you're running isn't the code the compiler and debugger are seeing.
Next, make sure you haven't accidentally turned off debugging in your code with {$D-} or {$DEBUGINFO OFF}. This can turn off debugging info for a single unit.
Also, make sure you've turned on Integrated Debugging in Tools|Options|Debugger Options. I know you said you could debug other places, but it can't hurt to make sure that integrated debugging didn't get accidentally turned off somehow.
I discovered this problem. It's a weird behavior in Delphi7 that limits the number of fields in interface class section, between: type TDM=class(TDataModule) and private section. I deleted some fields (DataSet Fields (+-40 fields)) and degub runs again. I add these fields again, and debug not runs. I'm sure that's a limit, because doesn't mather which component fields I deleted. I tried with several fields, from different tables too, adding, testing and deleting. It's a shame, but is true...
Thanks for your help.
I have a vague memory that debugging very large files was buggy in old D7.
Try to break you big unit in several classes and se if you can debug outside your unit.
Another option could be to turn off debuginfo in your big file except the section you want to debug. It is worth a try.
There's a blog post from Steve Trefethen, a while back, explaining some possible reasons, although if you say you can debug other units, I doubt they'll apply.
We had the same issue with a large DataModule in Delphi 5 that wouldn't let us debug it, and kind of put it down to it being too large a file to debug and Delphi not liking it. When we moved to Delphi 2007, we could debug it again. Not sure why, nothing had changed (code wise).
Felipe, is the unit that will not allow you to debug in a dll that is being moved into or out of memory? I've found when debugging dll's that if I do something in the executable that executes code in another dll or unloads the dll that the problem unit is in - Delphi will disable all breakpoints. Usually a restart of Delphi and being sure to keep a single instance of the problem unit's dll in memory is the only solution for this problem.
I doubt size is the issue, as I have a 17k line unit that I debug regularly.