Root > Troubleshooting > Breakpoints


Previous pageReturn to chapter overviewNext page   

Sometimes breakpoints in your project are not working. This issue is not specific to EurekaLog (usually). This article contains several things which you should to try.


First, be sure to (re-)setup debugging options as explained here. Be sure to enable debug information and be sure not to have directives like {$D-} in your code.
Check file paths:
oBe sure that you don't have two different units with same name in different folders (i.e. new and old files). You may load wrong unit in editor, but debugger will operate on another unit.
oBe sure that output folder for units is listed as library search path (per-project setting).
oBe sure that your file is included in project and it will be compiled with the project:
Check search paths of the project;
Check used files (with explicit file paths) in .dpr/.dproj files (Project / View source).
Delete old files (*.dcu, *.obj, *.lib, *.tds, *.rsm, *.bpl, *.dcp, *.exe, *.dll) and build your project(s) (not just make/compile).
It's possible that you've opened file that do not belong to project. File may be already compiled or it may be not part of the project (think about exe/DLL).
It's possible that your project is DLL and DLL wasn't loaded by host process. Breakpoints will not work until DLL is loaded. Sometimes DLL may be not loaded at all.
It's possible that code with breakpoint isn't used in your project. For example, a unit can contain 3 functions. Functions #1 and #2 are called from the program, but function #3 is not. Thus, breakpoints in function #3 will not work. Similarly, optimized compiler may remove individual lines of code from the functions. For example, code line calculates value, but this value is not used anywhere. Such code will be omitted from final executable.
It's possible that your code is placed in run-time package (.bpl). Thus, rebuilding your project will not affect that unit. And that unit (in package) may be compiled without debug information. If this is the case - then you need to either rebuild package with debug information or remove package from being used in your project.
It's possible that debugger can not associate running program with your project. To avoid this:
oDo not rename application and DLLs. Name project files with desired names.
oDo not move application and DLLs to other folders. Setup proper output folder instead of moving files. This is especially true for DLLs and Win32 services.
oDo not run application (don't load DLLs) via alternative names. For example, the same folder can be accessed via different names (folder itself, hardlink, via mapped network share, via reparse point, subst-drive). So, if you can access the same file/folder with different names - be sure to use exact same name in all places. This is especially true for DLLs, because they are loaded by host process (which may be not controlled by you). You can use Process Monitor or similar tool to check file accesses.
oBe sure that all file paths contain only ASCII symbols (latin). Do not use local symbols with codes above 128.
oDo not alter date/time (date of creation or modification) of compiled files and .dcu/.obj/.lib files. Changing date/time may cause debugger to consider files being changed. "Changed" files requires recompile, thus they do not match each other. Sometimes date/time can be changed by anti-virus software or post-processing tools (like digital signing).
oDo not delete and do not move .dcu/.obj/.lib files. Be sure to setup unit output folder to the right place. Be sure that unit output folder is listed in library search paths. Try to place .dcu/.obj/.lib files in same folder as .exe/.dll/.bpl/.dcp files.
oBe sure that all files can be found. Specify search paths or include unit explicitly via "Project / Add to project" command.
oTry to enable TD32 debug information.
oAs extreme case - try to output all files in single folder. I.e. output .dcu/.obj/.lib/.exe/.dll/.bpl/.dcp files in folder with source files.

Send feedback... Build date: 2023-05-05
Last edited: 2023-03-07
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.

Permanent link to this article: