Issue with DLL debugging.

Issue with DLL debugging.

Using XE4, I'm building a DLL and a VCL application which consume the DLL. Everything works fine except that sometimes, the debugger doesn't stop on breakpoints (Blue dots are not showing). After a while, it works again without apparent reason.

I tried many things to make it works again once it is broken. I was not able to find out a reproductible way to have the blue dots back.

Sometimes, it is enough to delete the directory conatining all DCU (same dir for app et dll). Sometimes not. Sometimes, restarting the IDE solve the issue. Sometimes not. Sometimes, doing a "clean" on both project solve the issue. Sometimes not.

I don't clearly understand the underlaying mechanism and I cannot find a reproductible way to solve the issue.

I'm not alone. See Stackoverflow article: http://stackoverflow.com/questions/5679989/delphi-why-breakpoints-from-time-to-time-are-not-usable-green-highlighted-line

Any hint appreciated.
Update: I've just found one more way to get the breakpoints back (At least up to now, maybe they will go away later): I set the option "Include remote debug symbols" to true in the DLL project and recompiled. Now the breakpoints are honored and blue dots visible.

Comments

  1. Don't know if it is related here, but when using the remote debugger I couldn't make it work when somewhere in the uses appeared WinTypes and or WinProcs. In my case the culprit was QuickReport.

    ReplyDelete
  2. Thanks Uwe. My issue is not related to remote debugging altough it seems that including remote dubg symbols solved the issue (At least since I've found it one hour ago). And by the way, I never use WinTypes and WinProcs which are very old and useless by now.

    ReplyDelete
  3. As you've found setting "Include remote debug symbols" to true has allowed me to work around this problem in the past. (I was debugging locally). In my case the compiler output was being stored on a VirtualBox shared folder. So it appeared as a mapped network drive to the guest OS, which was running the IDE. In every case the dll was being loaded using LoadLibrary. This routinely occurred in D2007 and D2010 so my guess is it's been there a while.

    ReplyDelete

Post a Comment