I'm experiencing problems with debugging in Delphi 2009's IDE. Since having moved old projects that had been created using Delphi 7 to this version, all breakpoints except for those in one unit are neglected. I couldn't figure out which unit that is, but that seems to change from time to time.
Enabling debug DCU's overcomes this phenomena, but I don't want to step inside RTL/VCL units. Only those used by my project, like the Version 7 IDE did with standard settings.
Chances are when you first moved the project to D2009 you built your units without debug info. Now that those units have been created, they don't get rebuilt every time. What you are probably seeing is that the breakpoint only works in the unit you're currently editing and making changes to. This is consistent with the fact that the compiler knows to rebuild that unit (with the now properly set debug flags), and that unit only.
The solution is the make sure the Debug configuration is selected and then do a full build.
Delphi 2009 comes with different build configurations. Make sure you've got Debug build mode set, not Release mode, and that the debug compile option is turned on.
Related
With XE8 update 1, Win 7 64 bit and a single component added to an otherwise empty folder I get:
error: [dcc32 Fatal Error] F2039 could not create output file .\Win32\Debug\MountTest.
The test will compile and run fine the first time but XE8 has to be shut down and restarted to compile again. The component is a gauge from Mitov Software.
The component vendor say's that this is a known bug with no fix. If so its a showstopper and project end'r for me. Is it really the end of the line for Delphi?
I hope some one can pull this rabbit out of a hat somehow.
This is what I have done to isolate the problem.
Started with a failing application (will not compile a 2ed time)
Remove all external units used
Remove al references to those units
Remove all references in the 'Uses' clause
Comment code until it compiles
It should compile every time you hit run (no problem).Now add a blank form to the project. Don't do anything to the form just add it. Add it to your uses clause.
Its should compile every time you hit Run.
Now open the blank form and simply touch it so that it needs to be recompiled.
When you run the application its back to failing when you run it a second time.
Notice that happens when you simply add a form and 'touch' it. No code needed.
This problem is not something wrong with my code - it can't be. Its a bug in the UI - must be.
Coincidentally, I just fought with this issue yesterday testing some components I ported to XE8. The output file in my case is the project executable.
After spending several hours trying to figure out what was going on (including efforts to reconfigure my AV software, disabling it entirely, moving the project to a different location, etc.), I was able to solve the problem by disabling Castalia. If I run the IDE without Castalia, the problem does not occur. If I enable Castalia again, it starts happening again.
You can find instructions for disabling/enabling Castalia in How can I disable Castalia in XE8?
I'm removing the above content because the issue has reappeared (with Castalia disabled). Further investigation shows a couple of things:
The problem seems to be related to any sort of exception being raised in the debugger (even those that are handled in the code). Clicking either Break or Continue in the debugger exception dialog works as always. However, the next attempt to compile or build the application fails with the F2039 error. Deleting the executable in Windows Explorer allows compilation and running once, and then the error recurs.
Restarting the IDE fixes the issue, until the next debugger exception occurs.
Neither taskkill or a batch file with del worked in either a pre- or post-build event.
There is an open QC entry for it at Embarcadero which indicates that it was reported in XE7, XE7.1, and XE8, and is currently an open internal ticket. I can't find a way to add the information in the two points above to that open ticket in the new JIRA-based Quality Portal. Perhaps someone who has access and can do so will on my behalf (or at least add a link to this post).
It's not linked to a specific project. The original answer (as mentioned above) was related to a test app while porting some components to XE8 from an earlier version. When the problem reappeared for me, it was in a brand new project, totally unrelated, that does not use any non-standard components.
(I previously had access to EMBT QC, and had a few open tickets. The accounts appear to have not migrated to the new QP, and I can't locate any tickets there under my account.)
Found It.
I decided to start from scratch on my development system and uncovered the problem.
I installed Windows 10 on a virgin disk
Installed XE8 update 1
Installed MITIOV Instruments for XE 8 and tested them. All working find
Installed AsyncPro - Still working
Installed the JEDI Jcl - Fails
Remove JEDI Jcl - now works
Trash JEDI completly - Everything works fine
Something in the JEDI Jcl version 3.48 is causing the problem. I can code around the JEDI components I was using without to much trouble but its a shame.
How about automatically kill your "hang-up" application before build?
I also had this problem on Win 7 Pro 64 bit with XE8.
Removing JCL fixed the problem. If I was a betting man, I would look closer at the JCL Debug IDE extension.
Guy's..
There is no reason to upgrade to Delphi 10.1, because all previous versions are equipped with an older version of the Android SDK.
Now, how to solve this annoying issue:
Just find the map where the Android SDK is located.
See: Tools/Options/Delphi Options/SDK Manager/Android Location
Now run the ..\sdk\tools\android.bat as Admin
This will show the Andoid SDK Manager.
Next is to update to the newest Android SDK and SDK Tools.
If all completed, you don't have to upgrade to Delphi 10.1 or whatever "advised".
Restart Delphi and problem:= solved!
btw:
It took some effort to find out what's happening here, because the Eclipse compiler suffered the same issue as Delphi. Finally all was related to bugs in earlier versions of the Android SDK causing adb.exe to keep a filehandle held hostage.
Sometimes there are pieces of code where exceptions occur that you don't want to stop execution in the IDE (e.g. OLE exceptions when setting up a connection).
The trick is to place 2 breakpoints around this, with the 1st set to "Ignore subsequent exceptions" and the 2nd to "Handle subsequent exceptions".
This works fine when you are the only one working on the code, the breakpoint moves with the code.
However, when several developers update the same file and you import/export from/to version control (SVN in my case) the breakpoints can end up on the wrong lines and you have to reset them.
This is because these breakpoint settings are maintained locally in the IDE configuration.
Has anyone ever found a way to maintain these breakpoints among developers? How?
Using Delphi XE2 for W32 apps.
These breakpoints are stored in a DSK file - either that of the project or that of the project group, depending on what was open in the IDE. You may consider adding those files to the version control. However, this might have other significant drawbacks.
I'd like to debug Lazarus library code. In Delphi IDE I would simply check the Project Options -> Compiler -> Use Debug DCUs option on. Is there something similar in Lazarus?
Yes and no. It roughly works the same as in Delphi, you need two sets of the compiled units. (.o/.ppu), and some way to switch.
But because FPC/Lazarus are open source, only one set (the one without) is distributed. But you can craft the other byrecompile FPC and Lazarus with -gl. For tips on recompiling FPC/Lazarus see http://www.stack.nl/~marcov/buildfaq.pdf
(it is even possible to do combinations. I debug many of my applications with everything debug except systems and sysutils, so that I don't trace into each and every string and exception helper, a major annoyance on Delphi)
Currently the releases afaik don't distribute the duplicate sets, but this is more a release engineering problem. (specially since by using strip, the non-debug set can be probably crafted from the debug set)
BTW, it might be worth the trouble to ask on the Lazarus maillist if such way exists. Even if the release doesn't set it up, there might still be a possibility that the functionality exists.
Debug breakpoint's works fine in all other 38 units of my system. But, in my DataModule, that have +- 10.000 lines, delphi disables then after I launch by F9/F8/F7. In any part of source that unit, even on obrigatory steps like OnCreate, SQLConnection.Active:=true, etc.
Detail: works fine until +- 20 days ago.
I'm using D7 and have all sources of components also.
Thanks
Felipe
Try doing a full build (Shift+F9). If that does not work, then what happens if you simulate a breakpoint in code with the below?
asm int 3 end;
Check for multiple copies of your source file for the datamodule. Sometimes the code you think you're running isn't the code the compiler and debugger are seeing.
Next, make sure you haven't accidentally turned off debugging in your code with {$D-} or {$DEBUGINFO OFF}. This can turn off debugging info for a single unit.
Also, make sure you've turned on Integrated Debugging in Tools|Options|Debugger Options. I know you said you could debug other places, but it can't hurt to make sure that integrated debugging didn't get accidentally turned off somehow.
I discovered this problem. It's a weird behavior in Delphi7 that limits the number of fields in interface class section, between: type TDM=class(TDataModule) and private section. I deleted some fields (DataSet Fields (+-40 fields)) and degub runs again. I add these fields again, and debug not runs. I'm sure that's a limit, because doesn't mather which component fields I deleted. I tried with several fields, from different tables too, adding, testing and deleting. It's a shame, but is true...
Thanks for your help.
I have a vague memory that debugging very large files was buggy in old D7.
Try to break you big unit in several classes and se if you can debug outside your unit.
Another option could be to turn off debuginfo in your big file except the section you want to debug. It is worth a try.
There's a blog post from Steve Trefethen, a while back, explaining some possible reasons, although if you say you can debug other units, I doubt they'll apply.
We had the same issue with a large DataModule in Delphi 5 that wouldn't let us debug it, and kind of put it down to it being too large a file to debug and Delphi not liking it. When we moved to Delphi 2007, we could debug it again. Not sure why, nothing had changed (code wise).
Felipe, is the unit that will not allow you to debug in a dll that is being moved into or out of memory? I've found when debugging dll's that if I do something in the executable that executes code in another dll or unloads the dll that the problem unit is in - Delphi will disable all breakpoints. Usually a restart of Delphi and being sure to keep a single instance of the problem unit's dll in memory is the only solution for this problem.
I doubt size is the issue, as I have a 17k line unit that I debug regularly.
I'm building a project that uses the JVCL plugin system, which relies on runtime Delphi packages, and ever since I added it to my project, debugging has become a nightmare because I'm no longer able to step-trace into the source of any VCL or RTL units. They're all marked as gray dots in the debugger, (when the relevant functions appear at all in the call stack; sometimes I get very strange results,) and it's driving me crazy. Does anyone know how to get my debug DCU functionality back? (Aside from the obvious: rip out all the plugin-related code. That would work, but it wouldn't really help.)
Edit: Just to be clear, I can trace anything else in my project. JVCL code. Other 3rd party libraries. My own code. All of it shows up just fine in the debugger. Just not the Delphi RTL and VCL code--the stuff that the compiler option "use debug DCUs" is supposed to grant you access to.
This is working as designed.
When you are building with packages, you are executing the package code, and not using any DCU's. Therefore, the DCU's are compiled in, and you don't get access to the Debug DCU's.
You can either turn off packages altogether, or don't compile with the specific packages you want to debug. You can choose what packages should be used or not used, and the ones that aren't used will be "debuggable" with the Debug DCU's.
Packages are just DLLs. You have to include the debug info into those to be able to debug them, which is what you want to do. So you would need to have DEBUG packages for the VCL and RTL, not debug dcus. The debug dcus are not even needed anymore when you use prebuilt packages.
It could be the DCU's you have are out of date, so the debugger doesn't step into the code.
Usually deleting all the DCU's then doing a Build All will fix this.
You may need to delete DCU's in the search path too, just to be sure. Make a backup first of course...