The non-debuggable unit

The non-debuggable unit

I have a unit that now refuses to have blue dots when compiling.  Doesn’t matter if it is in debug or release mode.  

– It is referenced in .dpr file

– I’ve searched all paths for stray .DCUs and found none

– I’ve have deleted .dcr, .local and .identcache files 

– I’ve done Clean and Build, and still no blue dots and breakpoints

Once running, I can set breakpoints, but some lines will not accept them (such as in multiline statements)


26 thoughts on “The non-debuggable unit

  1. You sure the code is actually in the binary? If the linker decides that it’s not needed you don’t see the blue dots. Any include file that might specify {$DEBUGINFO OFF}?

    Also non windows linebreaks might cause the editor to be wrong about the indicators. I can reproduce this when I change the EOL to Old MAC format (only CR) using Notepad++.

  2. I sometimes get that issue also. The only way I found to clean it is to do a clean for both release and debug, then CloseAll, then quit the IDE, restart the IDE and rebuild. Usually the blue dots are coming back at the right place.

    Sometimes I have a similar error: the blue dots are out of sync with the source code, prohibiting to put breakpoint to some lines. It can be see that this out of sync starts at a given point in the source. I then move that part of the code before everything and usually it works. I never had time to find out what the compiler issue there is. And it is almost impossible to reproduce.

    One more note about the above: just after compilation, the blue dots are at the right place but as soon as you debug, they are out of sync.

  3. Since it contains the core objects, I am pretty sure it’s in there.  Nothing would work if it’s not in there.  That said – the types are mostly abstract classes or classes with abstract methods, i.e. never instantiated.  Still, it used to have blue dots.

    Another unit had DEBUGINFO OFF, but it was commented out. That unit shows blue dots.

    The file was in ANSI format.  Tried saving it as UTF8.  Will that fix linebreaks?

    No packages.

    Testing François’ trick.

  4. Lars Fosdal As to line breaks, open the file in Notepad++, set the line breaks to Linux style, then back to Windows, and save. No need to look for them.

    I did have an experience in the past, however, where the problem was triggered by the existence in the source of a zero byte. Had to fix that with a hex editor. It did not bother the compiler, but it did confuse the IDE parser.

  5. There are numerous methods that deal with the generic types which have implementation parts.  The classes themselves are always inherited or used with a type argument.

    It’s in one of these 

    The Structure view is littered with silly errors related to “not containing” free, classname, qualifiedclassname, classtype, etc. – but that should be irrelevant.

  6. I sometimes managed to shoot myself in the foot, when I had the (same) unit open than the one that I intended to debug, but from a different path in the file system. Delphi would allow me to set break points and everything, but I would never arrive there, since I was looking at the wrong, although identical file.

    Could this be the case?

  7. I see this problem all the time in XE4. The fix is always to close the project then re-open it. I get the feeling it’s related to the out of memory issues Delphi has with large projects.

    Have you tried adding a deliberate error to the unit? If it doesn’t compile you can be 100% sure that you are using the correct file.

    You can also try my Unit Dependency Scanner ( It will tell you if you have any duplicate unit names during the scanning process.

  8. Checked .dpr and .dproj references.  All point to the correct file.  A deliberate error causes the expected compilation stop.  No duplicate unit references.  I am stumped.

    As Asbjørn Heid mentions – perhaps this is Generics related?

  9. I can trace into the unit, and as mentioned in the OP, I can set breakpoints too, once running – but they may appear as invalid, especially on multi-line statements – so it appears to be purely visual.

  10. In my case it is absolutely generics related, and it only affects certain classes within a unit. Other classes/code get the blue dots just fine.

    I can’t recall right now what triggered it for me, but I do recall changing how I used generics for the class in question and that made the blue dots come back. When I made a new class with the original design in terms of generics use, it didn’t get the blue dots.

    I’ll try to dig up the code and see what it was.

  11. Asbjørn Heid I have that problem sometimes aswell. Mostly with generic methods (you know where the T is on the method itself). Also while debugging you end up in code that is definetely not executed in that call. But that is XE, in later versions that got fixed as far as I could see (still using XE in production).

  12. My XE5 just stopped being able to set breakpoints inside of RTL/VCL units. I can step into them by setting a breakpoint in my own code and F7. I then see the blue dots in the unit i step into. Yes, use debug dcus is checked in the active configuration. WTF is this sh*t?! 🙁