Solved

Debugger not stopping at breakpoints in Delphi 7

Posted on 2014-11-21
9
284 Views
Last Modified: 2014-12-02
Hi, I'm working on a fairly small and uncomplicated project and when I try to debug and step through some code, some of the clear breakpoints I set get ignored. It's strange - *some* breakpoints I set get obeyed fine, but some other just don't. All the little dots are there next to each executable line, and they all seem to be in synch right down to the final "End." statement at the bottom.. but yet some breakpoints work and some don't... it's really maddening. Anyone ever wrestled with something like that before?

Thanks
    Shawn

P.S: It does this just for this particular project. When I work on my other projects, there's no problem with debugging.
0
Comment
Question by:shawn857
  • 4
  • 3
  • 2
9 Comments
 

Author Comment

by:shawn857
ID: 40461549
... can anyone help?

Thanks!
   Shawn
0
 
LVL 24

Expert Comment

by:jimyX
ID: 40461944
What settings are you enabling/disabling under:
Project -> Options -> Compiler Tab -> Debugging Box?

For that particular uncomplicated project.
0
 
LVL 24

Expert Comment

by:jimyX
ID: 40461949
Also note, sometime you need to Build your project "Project -> Build" in order to clear the old DCU's that were set for the debugger to use.
0
DevOps Toolchain Recommendations

Read this Gartner Research Note and discover how your IT organization can automate and optimize DevOps processes using a toolchain architecture.

 
LVL 26

Expert Comment

by:Sinisa Vuk
ID: 40463052
agree - always do build before get real debuging. Make sure that you're in debug mode as jimyX points, and make sure that optimization is disabled too.
0
 

Author Comment

by:shawn857
ID: 40463829
Thanks for the replies guys.

Jimy - I've attached screenshots of my Project|Options settings for both the Compiler tab and the Linker tab. Yes, I always use Project | Build.

Sinisa - I usually have Optimization checked, and debug has always worked fine in my other projects. I disabled it for now to try it, but still no difference.

I don't know if this would affect the debugger, but I do have these compiler switches set at the top of my main unit:

  {$F+} { Force FAR calls }
  {$P-} { Turn open parameters OFF }
  {$V-} { Turn OFF strict string parameter checking }


... then further down in the Implementation section, these:

{$R *.DFM}
{ $X+ }

Thanks!
   Shawn
Compiler-settings.JPG
Linker-settings.JPG
0
 
LVL 26

Expert Comment

by:Sinisa Vuk
ID: 40463915
none of them is a problem - maybe another switch somewhere else.
Look at this document and see for another hint we miss.

more on switches: Delphi_Compiler_Directives

how about another (newly created) project - can you debug it?
0
 

Author Comment

by:shawn857
ID: 40466181
Thanks Sinisa, I'll have a look at that document you mentioned in more detail soon, I've been very busy.

Looked at my project more closely tonight and noticed that in the main unit (3697 lines), debugging of all routines is successful up to line 1737. Then from line 1738 and onwards, debugging does not work anywhere. Isn't that strange?
   Also, right at that Line 1737 "border", a procedure from the non-debuggable side calls a procedure in the debuggable side... debug works when stepping through the procedure in the debuggable side.
   A basic outline:

procedure a;   // debug works in 1st line of procedure
begin
.
.
.
end; // a

procedure b;   // debug works in 1st line of procedure
begin
.
.
.
end; // b

procedure c;   // debug works in 1st line of procedure
begin
.
.
.
end; // c


procedure d;   // debug DOESN'T work in 1st line of procedure
begin
.
<calls procedure c from here, debug in procedure c works!>
.
end; // d


// nothing from this point downward in debuggable


What do you think guys? Maybe there are some hidden control chars or something messing up my unit half-way through or something??

Thanks!
   Shawn
0
 
LVL 26

Accepted Solution

by:
Sinisa Vuk earned 500 total points
ID: 40467631
Try to check Use debug DCUs in compiler settings and do full build. Your app may break or exit because of some internal exception to another place than you expect.
0
 

Author Comment

by:shawn857
ID: 40469907
Well, I solved this stumper. Stupidest problem I have ever had, and still don't know why it did this. What I did was cut out and pasted ALL my code from where the 1st procedure stopped working in debug (ie. "procedure d" in my example in my last post), saved that in a notepad file, commented out all declarations and references to any of this code I removed, then re-built. Then I re-introduced a few procedures at a time to my unit and uncommented out their declarations - always inserting them at the top of my unit and not the bottom. I'd test these additions in debug, then add a few more and repeat. Took some time, but finally I got the whole thing working. Very very stupid and unexplainable error! Please note that I didn't change my Project|Options settings in any way.

Thanks to all who tried to help!

Shawn
0

Featured Post

Are your AD admin tools letting you down?

Managing Active Directory can get complicated.  Often, the native tools for managing AD are just not up to the task.  The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A lot of questions regard threads in Delphi.   One of the more specific questions is how to show progress of the thread.   Updating a progressbar from inside a thread is a mistake. A solution to this would be to send a synchronized message to the…
The uses clause is one of those things that just tends to grow and grow. Most of the time this is in the main form, as it's from this form that all others are called. If you have a big application (including many forms), the uses clause in the in…
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …
Established in 1997, Technology Architects has become one of the most reputable technology solutions companies in the country. TA have been providing businesses with cost effective state-of-the-art solutions and unparalleled service that is designed…

809 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question