Why the Delphi debugger might fail to stop at your breakpoint

There are a number of reasons Delphi’s debugger might fail to stop at a breakpoint you set. I’ve seen this issue mentioned time and again on the public newsgroups and I thought it might be worth posting a quick list off the top of my head:

  • The .pas file you’re debugging has is missing line feeds. Be sure that your file has correct CRLF characters at the end of each line.
  • You have compiler optimizations turned on. Occaisonally, compiler optimizations may cause your code to execute in an unexpected order. Be sure to turn optimizations off and stack frames on.
  • You’re looking at a source file that’s not actually compiled/linked into the active project. This can happen as a result of copying a file from one directory to another and your project desktop reopens the file from the old location. One quick way to tell is add a syntax error and compile the code, if it doesn’t stop on the error then you’re looking at the wrong file.
  • You turned off Debug Information and Local symbols options. Of course, these are a lot less likely but still possible.

Ok, that’s all for now. Let me know if you think of anything else and I’ll update the list.

12 thoughts on “Why the Delphi debugger might fail to stop at your breakpoint

  1. That first one is Delphi’s fault. If it is displayed correctly in the editor, it should Just Work.

  2. There is (was?) also a problem in XP and higher where when debugging a dll the debugger does not stop at the breakpoints.

  3. One more problems with breakpoints:
    If you have both the project and a package loaded, the following situation can happen:
    1) Build package and project
    1) You edit code of a file contained in the package
    2) You Compile the Project (which is using the edited file but not actually including it)
    If you’re unlucky enough, your project will not realize that the file has changed and just relink the old compiled stuff. (If you do the syntax error check supplied above, the code will fail to compile, when the bug is fixed, it will compile and link correctly).

  4. The ide/debugger could maybe warn the developer just when setting the breakpoint at the editor. Asking the developer "Breakpoint cannot be set due to several misconfiguration. Do you want to correct these problems to enable debug at this breakpoint?", the ide must automatically correct all the points you described above. That is, the ide could automatically uncheck compiler optimization, enable linker debug, local symbols, search current paths for duplicate .pas file with the breakpoint, etc, etc, and recompile the project again. It makes no sense developers should google to find your blog post to discover why breakpoints aren’t working fine.

  5. Something of a counter point to this problem is the debugger stopping where it *shouldn’t*. One is stepping through code with either F7 or F8 (I have been doing this long enough that my fingers are trained to "Classic IDE" and refuse to change) to code that is supposed to skip code that includes such things as Windows hook loops, message callbacks, etc. in units where I do have debug info turned off (I’m sure of this as I have deleted the .dcu and rebuilt it with the specified compiler options turned off).
    VERY frustrating!

  6. I have the same problem and its forcing me to migrate my code to another IDE such as VC++ and write all the codes again, but not suffer from some confusing debugger problems!

  7. Hossein,
    If you read through these items their not bugs in the product but rather things you may or may not have set correctly or settings you may not be aware of. VC++ will have very similar "problems" so I’d expect if you’re having issues with a CodeGear product you’ll likely run into a similar situation with any other IDE.

  8. Sorry Steve, but Hossein is right. I’ve never been so frustrated with a development tool and I’ve been writing code for > 15 years. What a piece of crap. The sad thing is Delphi is so close to being a really good product! Unfortunately it has some serious flaws the make it unusable for commercial development. Delphi bugs make me hate programming 🙁 I recommend you run away from Delphi as fast as you can!

  9. Two other reasons why breakpoints might fail:
    – someone put {$D-} in the code
    – Tools/debugging options/Integrated debugging is not checked
    That last one cost me over an hour in an inherited project ;-(

  10. As a precaution to bad things happening with the debugger, I make sure I make a backup not just of the code, but take a copy of the .res (resource) file and set it aside usually in a separate "hold" folder in the project. I fool with debug issues all the time, and sometimes really foul them up. When this happens, I just restore the .res file before I fooled around with things and debugging comes back to life as it was. But, if you take forms in and out or make changes, test to make sure things work, then make another copy of the .res file before tweaking the debugger or other settings too much. Of course, I always keep an archive of working build progress just in case I really foul things up and have to revert back and restore things to try over again. An ounce of prevention…

  11. Just as an additional note for those who might google and land on this page, I’ve just had some trouble with Delphi 2010. I just couldn’t get breakpoints to work at all. Essentially the new IDE had caught me out. In the Project Manager (the big list of files in the project on the right-hand side of the screen, typically) under Build Configurations, you’ll probably find a Debug node and a Release node. If you right click one, you can activate it. The Build Configuration option under Project Options does -not- determine the current configuration, although you’d be forgiven for assuming it did. In short – activate the debug node and you’re away.

Comments are closed.