|
Problem:
I can not debug my application/DLL. All breakpoints are non-functional.
Reason:
There may be several possible reasons for this. This issue is not specific to EurekaLog.
Solution:
- 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:
- Be 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.
- Be sure that output folder for units is listed as library search path (per-project setting).
- Be 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:
- Do not rename application and DLLs. Name project files with desired names.
- Do 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.
- Do 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.
- Be sure that all file paths contain only ASCII symbols (latin). Do not use local symbols with codes above 128.
- Do 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).
- Do 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.
- Be sure that all files can be found. Specify search paths or include unit explicitly via "Project / Add to project" command.
- Try to enable TD32 debug information.
- As 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.
See also:
| 