About/Contact

Steve Trefethen

Steve Trefethen is a Director of Engineering at Reply. Contact me

View my LinkedIn profile


Powered by discountASP.NET
referal ID: sdtref
Why recommend discountASP.NET?
$720 in referrals so far!


Calendar

<<  February 2012  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
2728291234
567891011

View posts in large calendar

Disclaimer

The posts on this weblog are provided AS IS with no warranties, and confer no rights. The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.



Why the Delphi debugger might fail to stop at your breakpoint

January 16 2007 5:37AM
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.
FacebookDel.icio.usDigg It!

Tags:

Comments (12) -

1/16/2007 5:27:00 PM #

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

duser

1/16/2007 7:28:32 PM #

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

Lars

1/17/2007 10:29:18 AM #

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).

Daniel

1/17/2007 10:50:24 AM #

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.

Me

1/18/2007 10:29:36 PM #

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!

Fred

5/21/2007 1:42:53 PM #

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!

Hossein

5/21/2007 9:45:19 PM #

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.

Steve Trefethen

6/25/2008 11:52:10 PM #

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 Frown  I recommend you run away from Delphi as fast as you can!

Josh

6/26/2008 8:39:31 PM #

Josh,
  FWIW, I disagree.

Steve Trefethen

8/21/2008 8:22:37 AM #

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 ;-(

Bye
jan

Jan Doggen

10/16/2008 4:16:30 PM #

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...

Scott

Scott Ottesen

3/16/2010 9:24:38 AM #

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.

Phil Hackett United Kingdom

Add comment




  Country flag
biuquote
  • Comment
  • Preview
Loading