When I Am Running My Project In Local Machine With Breakpoints It Works Well .But When I Remove Breakpoint I Am Not Getting Out Perfectly Why

Question

1.20/5 (3 votes)

See more:

When i am running my project in local machine with breakpoints it works well .but when i remove break point i am not getting out perfectly why

Posted 26-Oct-14 23:05pm

Praveenkumar l

Add a Solution

Comments

Eduard Keilholz 27-Oct-14 5:16am

I guess you have some threading or async stuff going on which need some sort of synchronization somewhere? Please post a piece of code we can dig in to in order to help you. Basicly your question now is, "my car engine doesn't run, what's wrong", million answers...

Sergey Alexandrovich Kryukov 27-Oct-14 6:38am

I agree; this is the most likely reason. That's why I put my answer, please see.
Of course, solving the problem needs comprehensive information on the case...
—SA

Robert Welliever 27-Oct-14 5:56am

Yah, please specify. Nothing should happen when you remove a breakpoint except the breakpoint will disappear and then the code won't break there again. Removing a breakpoint won't step you out of the code if you're actively debugging.

Sergey Alexandrovich Kryukov 27-Oct-14 6:37am

"Nothing should happen" is correct not in 100% of cases. There is such factor as timing. Moreover, in my experience, this (race condition) explains most of such cases. Please see my answer. It does not solve the problem, of course, but this is the first thing to analyze.
—SA

Robert Welliever 27-Oct-14 6:50am

Race conditions? WTF? What do you think happens when you click a breakpoint to turn it off? What cases are you talking about when turning off a breakpoint does something except turn off the breakpoint?

Sergey Alexandrovich Kryukov 27-Oct-14 6:52am

Oh, no. If this is how you understand the question, it could be just due to some unclear phrasing.
I believe the problem is: with breakpoints OP gets the different behavior. Look at the first comment, by Eduard Keilholz, who understood the problem the same way...
—SA

Robert Welliever 27-Oct-14 7:10am

It is EXTREMELY rare that programmers use multi-threading under ASP for a variety of reasons (I'm guessing you aren't a web programmer). That makes no sense to look for that first. Based on how the initial question is worded, it sounds more like he/she was debugging and couldn't step out of the server code, which is going to be just unfamiliarity with debugging under ASP.

Sergey Alexandrovich Kryukov 27-Oct-14 7:20am

I agree, agree, but there is no such thing as miracle. What else could you suggest? I know a number of cases when "Web programmers" tried to use multithreading, which is technically possible, but — agree with you — makes little to no sense. Frankly, I did not even look at that "ASP.NET" tag.

However, I do have a different suggestion: wrong, inaccurate observations by OP. It happens all the time. Unfamiliarity with debugging under ASP.NET could be the factor, right. :-)

Thanks goodness, I am not a "Web programmer". I just advice/consult a lot on Web programming. Probably you think that it could not be possible, I don't know. But I have an advice for you: don't jump to conclusion. This is a way to make big mistakes. :-)

—SA

Robert Welliever 27-Oct-14 7:44am

Jumping to conclusions is appropriate when those conclusions are correct. However, after reading your solution below it seems you might take your own advice. :)

Sergey Alexandrovich Kryukov 27-Oct-14 8:23am

Good idea, about taking the advice. I do take my own advice, and of course do some mistakes. Would you tell me where I'm wrong? If you are talking about my assumption about race condition, I never stated that I'm 100% sure about it. Sorry if it wasn't clear. If this is something else, please let me know.

As the the statement about appropriate jumping, there is one flaw: how do you know what is correct and what not? :-)

Cheers,
—SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2014-10-27T00:34:00

It's pretty much pointless to try to "fix" anything without seeing the code, but I can give you one idea.

There are cases when you really can expect different behavior when you execute code step-by-step or use break points, under the debugger. Why? For example, because such factor as timing can be important. But if you don't expect such effect, the mere fact that you have different results under the debugger is a clear indication of incorrectness of your code. One probably explanation is the same very timing, incorrect dependency on the time of execution, which can be revealed in case of any kind of parallelism. Such phenomena are known under the name "race condition": http://en.wikipedia.org/wiki/Race_condition[^].

This is the fist thing to think about.

—SA