Delphi：为什么断点有时不可用（IDE 上的绿色突出显示线）？
有时我会失去 Delphi 中的断点功能。
我认为这是 Delphi 2009 的问题，但现在我在 Delphi XE 中也有它。
在 Delphi 2009 中，通过删除 .dproj 文件，我使断点再次起作用。
在 Delphi XE 中，我无法使断点出现。我已经应用了所有修补程序的更新 1。
有人有解决办法吗？
From time to time I lose breakpoint functionality in Delphi.
I thought this to be a Delphi 2009 issue but now I have also it in Delphi XE.
In Delphi 2009 by deleting .dproj file I made the breakpoints work again.
In Delphi XE I am not able to make breakopints appear. I have update 1 with all hotfixes applied.
Does anyone have a solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（21）
文件中不存在调试信息。
确保您使用的是调试配置。 （
Project Manager树，展开Build Configurations，确保Debug为粗体。如果不是，请右键单击Debug并从上下文菜单中选择激活。）然后确保您对项目进行构建，而不仅仅是编译。如果仍然不起作用，请从 IDE 主菜单转到
Project->Options，单击Delphi Compiler下的Compiling，然后检查窗口右半部分的调试部分。确保调试信息和本地符号都被选中。如果您尝试跟踪 VCL 自己的源代码，还请选中Use debug .dcus（您需要将其关闭并在完成后立即对项目进行完整构建） ，因为当你正常调试时它会变得很烦人）。同样，您需要构建而不是编译。如果上述所有方法都失败，另一种可能性是您在代码编辑器中打开的代码单元与编译器看到的代码单元不同。确保计算机上编译器可能首先找到的位置没有该文件的多个副本。如果您不确定，请删除具有该单元名称的 .dcu 文件，然后构建项目，并查看新创建的 .dcu 是否位于您期望的位置。
Debug info isn't present in the file.
Make sure that you're using the Debug configuration. (
Project Managertree, expandBuild Configurations, make sureDebugis bold. If it's not, right clickDebugand chooseActivatefrom the context menu.) Make sure you then do a Build of your project, not just a Compile.If that still doesn't work, go to
Project->Optionsfrom the IDE's main menu, click onCompilingunderDelphi Compiler, and check theDebuggingsection on the right half of the window. Make sure thatDebug InformationandLocal Symbolsare both checked. If you're trying to trace into the VCL's own source, also checkUse debug .dcus(you'll want to turn this off and do a full build of your project as soon as you're done, as it gets annoying when you're debugging normally). Again, you'll want to build and not compile.If all of the above fails, another possibility is that the code unit you have open in the Code Editor isn't the same one being seen by the compiler. Make sure you don't have multiple copies of the file on your computer in a location that the compiler might find first. If you're not sure, delete the .dcu files with that unit name and then do a build of your project, and see if the newly created .dcu is in the location you'd expect.
我找到了更好的方法。
在项目管理器树中，右键单击项目并从弹出菜单中选择“清理”。
断点神奇地重新出现，这是一种非常快速的方法。
I found a better way.
From the Project Manager tree, right click on the project and choose "Clean" from the popupmenu.
The breakpoints reappear magically and it is a very fast method.
我怀疑当您完成发布构建并禁用调试时会发生这种情况。然后切换回调试配置并进行编译而不是构建。无法设置断点的文件与禁用调试的编译生成的 DCU 相对应。
只需进行构建来重新生成所有 DCU 文件即可使断点再次起作用。
I suspect this happens when you have done a release build, with debug disabled. Then you switch back to debug configuration and do a compile rather than a build. The files where you can't set breakpoints correspond to those with DCUs produced by a compile with debug disabled.
Simply doing a build to re-generate all DCU files will make your breakpoints work again.
这是代码与断点标记未对齐的另一个原因（装订线中的蓝色/红色“药丸”）。
编辑器可识别三种不同的行结尾：
其中，
CRLF是编辑器中的默认值。然而，编译器似乎并不将
CR only视为行结尾，仅将CRLF和LF only视为行结尾。因此，如果您的源文件恰好有一个或多个仅 CR，“蓝色药丸”将从源文件中偏移。您可能从互联网上获得了带有
CR onlyEOL（行尾）字符的源文件。我记得 MAC 操作系统仅使用 CR 作为 EOL。要验证文件中的 EOL，您可以在编辑器中打开 EOL 的显示
（工具 - 选项 - 编辑器选项 - 源选项 - 显示换行符）。这些符号看起来很奇怪（见下图），但 C 位于 L 之上（CRLF），C 位于 R 之上（CR），L 位于 F 之上（LF）。
下图显示了正常的 EOL (
CRLF) 和我在一个行中强制CR only和LF only为另一行后的 EOLS。十六进制编辑器。如上所述，CR only使断点标记从源代码中偏移。正常
CRLFEOL：一行
仅 CR，一行仅 LF：修复
要将所有 EOL 重置为
CRLF，请取消选中编辑器选项中的保留行结束符（工具 - 选项 - 编辑器选项） ，
进行一些简单的更改，以便将文件标记为已修改，关闭文件，将更改保存到 XYZ.pas？ 是，然后重新打开。
现在所有行结尾都是 CRLF。重建项目，所有断点球将位于正确的位置。
Here's one more reason to misaligned code vs breakpoint markers (blue/red "pill" in the gutter).
The editor recognices three different line endings,
Of these,
CRLFis the default in the editor.The compiler however, doesn't seem to consider
CR onlyas a line ending, onlyCRLFandLF only. Thus if your source file happens to have one or moreCR only, the "blue pills" will be offset from the source.You might have got source files with
CR onlyEOL (end of line) character from e.g. the internet. I recall MAC OS usedCR onlyas EOL.To verify the EOL's in your file, you can turn on the displaying of EOL's in the editor
( Tools - Options - Editor options - Source options - Show line breaks).The symbols look weird (see images below), but are just C on top of L for CRLF, C on top of R for CR and L on top of F for LF.
The following images show the normal EOL's (
CRLF) and the EOLS's after I forcedCR onlyfor one line andLF onlyfor another line in a hex editor. As said above, it is theCR onlythat offsets the break point markers from the source code.Normal
CRLFEOL's:One line with
CR onlyand one withLF only:Fix
To reset all EOL's to
CRLF, untickPreserve line endsinEditor Options( Tools - Options - Editor options),make a trivial change, so that the file is marked as modified, close the file, save changes to XYZ.pas? YES, and reopen.
Now all line endings are CRLF. Rebuilt the project and all the breakpoint balls will be in the correct locations.
打开远程调试符号对我来说是这样（没有其他效果）。项目>>选项>链接并选中包括远程调试符号。
Turning on remote debugging symbols did it for me (nothing else worked). Project > Options > Linking and check Include remote debug symbols.
我的XE4也有同样的问题。这就是我几个小时前发现这篇文章的原因。上述解决方案都不适合我。到目前为止，对我来说正确的解决方案是添加“远程调试符号”选项。奇怪，因为我不使用远程调试。不管怎样，现在看起来还不错。
I had the same problem with XE4. This is why I found this article a couple of hours ago. None of the above solutions worked for me. The correct solution for me - up to now - was to add "remote debug symbols" option. Strange because I don't use remote debugging. Anyway it looks OK now.
这是一个错误，重新启动 Delphi 将解决您的问题。
It is a bug, restarting Delphi will fix your problem.
尝试对本地 PC 进行远程调试。
为什么它有效：（来源）
当然，您必须首先将项目的“链接”选项“映射文件”配置为“详细”才能生成*.rsm 文件。有关如何开始使用的信息，请参阅远程调试概述。
Try remote debugging to your local PC.
Why it works: (source)
Of course, you must first configure your project's "Linking" option "Map file" to "Detailed" to generate the *.rsm file. See Overview of Remote Debugging for how to get started.
我通过确保“调试”设置为“本地”解决了我的问题：
I solved my issue by making sure Debug was set to Local:
我遇到了一个相关的问题：我丢失了特定文件中的断点，但其他文件都很好。发生的情况是，我已重命名该文件，但我不知道旧文件的 DCU 仍在使用，因为它在某处的“uses”子句中被引用。
解决方案是手动删除所有 DCU（执行“清理”是不够的，因为 DCU 代表的旧文件不再在项目中）并重建。您将收到一个编译错误，显示错误的“uses”子句。
I had a related problem: I lost the breakpoints in a particular file, but the other files were fine. What had happened was that I had renamed that file, but unknown to me the DCU for the old file was still being used because it was being referenced in a "uses" clause somewhere.
The solution is to manually delete all the DCUs (doing a "clean" is not enough because the old file represented by the DCU is no longer in the project) and rebuild. You will get a compile error showing the bad "uses" clauses.
断点不起作用的另一个原因可能是（通常用 delphi5 进行测试）：
一个单元中的程序太多。
解决方案是将程序移至另一个单元
Another reason for not working breakpoint could be (often tested with delphi5):
Too many procedures in a unit.
The solution is to move procedures to another unit
虽然这是一个老问题，但我可以确认这仍然是当前版本的 Delphi 10.3 Rio 中的问题。
上面关于行结尾的答案
https://stackoverflow.com/a/53360447/6445054
解决了我的问题导入了一些非常旧的 Delphi 代码，其中有 CR 行结尾
在一些地方，当我开始移动代码时，调试就完全中断了。
在里约，打开行结尾的选项略有变化，现在是
（工具 - 选项 - 编辑器 - 源代码 - 显示换行符）。
Although this is an old question I can confirm that this is still an issue in the current version of Delphi 10.3 Rio.
The answer above regarding line endings
https://stackoverflow.com/a/53360447/6445054
Solved the issue for me I had imported some very old Delphi code which had CR line endings
in a couple of places, as soon as I started moving code around the debugging broke completely.
The option to turn line endings on has moved slightly in Rio it's now
( Tools - Options - Editor - Source - Show line breaks).
在delphi 7 中，设置断点似乎存在一个真正的错误。
我有一个单元，其中许多文本都定义在
在接口部分，其中记录类型有一些 AnsiString 项。
在实施部分有一些程序。
在某些特定情况下，当我在程序中的任何位置设置断点时，delphi 不会停在此处！
备注：所有调试选项均已正确设置（对于 F7 会导致 delphi 在程序的“开始”处停止，整个单元中都可见蓝点，执行应用程序时线条保持红色）以及具有相应 PAS 文件的所有 DCU在我对整个项目进行完整构建之前，它们已从我的所有磁盘和所有文件夹中删除。因此，任何地方都不应存在任何 wold 文件。
为了测试，我将 PAS 重命名为另一个名称，以前从未使用过，并且肯定在任何磁盘上都没有其他地方，然后调整所有源并重新编译，只是为了确保 delphi 和我正在查看相同的 PAS 文件 - 但断点也没用。
但又发生了一件非常奇怪的事情：文本 consts (!) 在我的可执行文件中发生了变化（不是在 exe 文件中，但显然在内存中）！在程序启动期间检查这些文本的正确性，有时它会抱怨错误！消息框中文本的显示表明，该文本中的单个字符被更改，该字符被定义为 const。为了测试，我尝试在代码中为 const 分配一些内容，但是，正如预期的那样，编译器抱怨，因此它不可能是导致文本更改的普通分配。一定是指针错误。诡异的。
因此，接下来进行了数小时的测试，寻找任何可能设置了错误指针的源代码，该指针稍后可能会导致文本常量发生更改。我将消息框放入我能够编辑的单元初始化链中第一个单元的初始化部分，但更改的字符已经在那里了！那么，必须在我的应用程序启动期间很早就进行更改！
最后我发现，出现在我的文本中的字符始终是 $CC - 这正是 INT 3 的汇编代码，delphi 用于设置断点的代码。当将该单元内的断点向上或向下移动一行时，更改的字符的位置也会向左或向右移动一些字符！错误移动的字符数恰好与相关行所需的汇编器编码字节的估计量相关。在彼此靠近的行中设置两个断点，突然两个字符发生变化！当从该单元删除所有断点时，文本保持不变！
所以只有一个结论：delphi 本身在尝试设置断点时正在更改文本，但未能这样做。我无法摆脱这个错误。关于重新同步delphi的源代码和目标代码文件的内部簿记的提示都没有帮助我！
由于相关单元主要由多个 {$IFDEF} 之间的 {$I} 行组成，用于包含一些不同但很长的 pascal 文本，我认为 delphi 在包含太长或条件编译器指令的评估方面存在问题。因此，我删除了包含内容并将源文本立即放入单元中，并删除了 {$IFDEF} - 编译时没有错误，但设置断点也更改了我的文本常量，而不是停止执行。都一样！
我现在通过将单元分成两个单元来解决这个问题，一个单元仅在其界面部分中保存文本常量，第二个单元用于保存过程。现在，在不更改任何编译器或链接器设置的情况下，所有断点都按预期工作，并且文本不再更改！
因此，如果断点对您不起作用，尽管您确定它们应该起作用，但可能是 delphi 造成的，并且未能在正确的位置设置断点。如果只是更改一些文本，也许永远不会引起您的注意。拆分单元帮助了我，也许这也对你有帮助。
In delphi 7 there seems to be a real bug on setting breakpoints.
I had a unit where many texts are definied in a
in interface section, where record-type has some AnsiString items.
In the implementation section there are some procedures.
In some particular cases, when I set a breakpoint anywhere within a procedure, delphi does not stop at it!
Remarks: all options for debugging are set properly (as for F7 causes delphi stop at the "begin" of the program, blue dots are visible in the whole unit the line stays red while executing the app) and all DCUs that have according PAS files were deleted from all of my disks and within all folders, before I did a complete build on the whole project. So no wold files should hang around anywhere.
For testing, I renamed the PAS to another name, never ever used before, and surely nowhere else on any disk, then adapted all sources and recompiled, just to be sure that delphi and I are looking at the same PAS file - but the breakpoints did not work either.
But there another, very weird thing happened: the text consts (!) changed within my executable (not within exe file, but obviously within memory)! Those texts were checked for correctness during program start, and sometimes it complained about errors! Display of the texts in a messagebox showed, that there was changed a sinlge character within that texts, that are defined as const. For test, I tried to assign something to that consts within my code, but, as expected, compiler complained, so it cannot be an ordinary assignment that causes the change of the text. Must be a wrong pointer. Weird.
So, hours of testing followed, looking for any source code that might have set up a wrong pointer that later could cause that change in a text const. I placed the messagebox into the initialization section of the first unit within the chain of unit initialization I was able to edit, but the changed char was already there! Must be changed very early during startup of my application, then!
Finally I figured out, that the char that appeared in my texts always was an $CC - which exactly is the assembler code for INT 3, the code that delphi is using for setting a breakpoint. And when moving a breakpoint within that unit a line up or down, the position of the changed character also moves some chars left or right! And the number of characters the wrong one moved just correlated with the estimated amount of assembler coded bytes the concerned lines needed. Setting two breakpoint in lines near each other, suddenly two characters changed! When removing all breakpoints from that unit, the text remained unchanged!
So there's only one conclusion: delphi itself is changing that texts when trying to set a breakpoint and fails to do so. I was unable to get rid of this bug. None of the tips about re-synching delphi's internal bookkeeping of source and object code files did help me out!
As the concerned unit mainly consisted of {$I} lines between multiple {$IFDEF}s, for including some different, but long pascal texts, I considered delphi having problems on too long inclusions or on evaluation of conditional compiler directives. So I removed the includes and put the source text immediately into the unit, and removed the {$IFDEF}s - which compiled without errors, but setting breakpoints also changed my text constants, instead of stopping execution. All the same!
I solved this for now by splitting the unit into two units, one holding just the text consts in it's interface part, and a second one to hold the procedures. And now, without changing any compiler nor linker settings, all breakpoints do work like expected and not text is changed any more!
So, if breakpoints do not work for you, while you are sure they should, possibly delphi is the culprit and fails to set the breakpoints at the correct place. In case of it is changing just some texts, maybe that never gets to your attention. Splitting the unit helped me out, maybe that helps you, too.
如果您尝试在其中设置断点的文件是 DLL 的一部分，则需要通过在项目管理器中双击该 DLL 使其变为粗体来激活该 DLL，然后构建它。然后，蓝色圆圈将显示在允许您设置断点的行旁边。
If the file you're trying to set breakpoints in is part of a DLL, you need to make that DLL active by double-clicking on it in Project Manager so it turns bold, and then build it. Then the blue circles will show up next to lines where you're allowed to set breakpoints.
刚刚遇到了这个问题 - 在 D11 中打开一个旧的 .dproj （大概来自 XE10）。
编译工作正常，调试点（球）在那里。
然而，在运行时，调试点消失了，并且设置的任何断点都变成了绿色。
在走了许多死胡同之后，我创建了一个新的 .dproj，手动重新输入所有设置，瞧 - 调试又回来了！
我比较了 .dproj 文件，发现问题出在旧 .dproj 中的此设置：
删除它后，旧 .dproj 也按预期工作。快乐的日子:)
如果有人能阐明这个设置最初是从哪里来的，那就太好了..更有经验的人善意地向我解释说，“项目”->“选项”中的此屏幕驱动调试器符号的加载 - 特别是“加载所有符号”复选框。
Just had a run-in with this problem - opening an old .dproj (presumably from XE10) in D11.
Compile worked fine, the debug dots (balls) were there.
However upon run, the debug dots disappeared and any breakpoints set, turned green.
After following many a blind alley, I created a new .dproj, re-entered all the settings by hand an voila - debugging was back !
I compared the .dproj files and turns out the problem was this setting in old .dproj:
Upon removing it, old .dproj works as expected as well. Happy days :)
If anyone could shed the light on where did this setting come in the first place that would be great ..Someone more experienced just kindly explained to me that this screen in Project->Options drives the loading of debugger symbols - specifically the Load all symbols checkbox..
就我而言，我在一个单元中设置断点，该单元在 IDE 中打开时并不属于当前活动项目的一部分。此类断点也显示为绿色。 IOW 我根本就没有在正确的页面上。
（我在尝试了上述所有方法后发现了这一点。）
In my case, I was setting breakpoints in a unit that whilst open in the IDE was not part of the currently active project. Such breakpoints also show as green. IOW I was not on the right page at all.
(I discovered this after trying all of the above .)
如果项目组使用包 (BPL)，请确保其中没有任何有关隐式导入单元的编译器警告。如果这些存在，您将只能通过 CPU 调试窗口单步执行代码。
If the project group uses packages (BPLs) ensure that none of them have any compiler warnings regarding implicitly imported units. If these exist you will only be able to step through the code via the CPU debug window.
回答有点晚了，但我也偶然发现了这个问题。
如果我使用调试配置在项目管理器中激活 MyPackage.bpl（粗体），然后编译它，我可以看到 IDE 注册了调试信息（编辑器左侧的蓝点）。
但是当我激活 MainProject.exe（使用 MyPackage.bpl 的那个）时，那些蓝点就会消失，表明调试信息不再存在。经过一番绞尽脑汁后，我意识到我确实在 MyPackage.bpl 的发布配置上设置了依赖项（右键单击 MainProject.exe -> 依赖项），而不是在调试配置上设置了依赖项。
每次我编译 MyProject.exe 时，它都会链接到发布配置，而不是调试配置！
所以检查你的依赖配置！
Bit late answer but I stumbled on this problem too.
If I activated the MyPackage.bpl (bold) in the project manager with the debug configuration, then compiled it, I could see the IDE registered the debug information (blue dots on left of editor).
But when I activated my MainProject.exe (the one using MyPackage.bpl), those blue dots would disappear, indicating that the debug information is no longer present. After some head scratching, I realized that I did set up a dependency (right click on MainProject.exe -> Dependencies) on the Release configuration of MyPackage.bpl and not on the Debug configuration.
Each time I compiled MyProject.exe, it would link with the Release configuration, not the debug configuration!
So check your dependency configurations!
我在 Delphi Compile 下检查了 MSBuild（我们执行 MS Builds）。这导致断点无法工作。未经检查，它可以工作。
I had MSBuild checked under Delphi Compile (we do MS Builds). That was preventing breakpoints from working. Unchecked and it works.
通过使用 F9 运行应用程序，断点将按预期工作。我正在使用 XE4，我不知道这是否会“修复”Delphi 的早期版本。
By using F9 to run the app, breakpoints will work as expected. I am using XE4 and I do not know if this will "fix" prior versions of Delphi.
由于这是我在新笔记本电脑上新安装 Delpi XE 时遇到此问题时找到的关于此问题的最佳资源，因此我将仅添加 Delphi XE 的另一个可能的答案。
如果您使用两个显示器设置并且代码编辑器窗口位于第二个显示器上，则不会显示工具提示。如果编辑器窗口位于主监视器上，则工作正常。非常令人沮丧。可能是驱动问题。
Since this is the best resource I found on this issue when encountering this problem with a new install of Delpi XE on a new laptop, I will just add in one more possible answer for Delphi XE.
If you are using a two monitor setup and the code editor window is on the 2nd monitor, the tooltips will not show. Works fine if the editor window is on the primary monitor. Very frustrating. May be a driver issue.