1172876 - Debugger: Breakpoints are not hit / only hit partially

Status: RESOLVED WORKSFORME

(DevTools :: Debugger, defect)

Description

[Nico Schmoigl]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150525141253

Steps to reproduce:

1. Open http://htmlpreview.github.io/?https://github.com/eaglerainbow/openui5/blob/88f08ebd50e67f962f85ce90cdd4c149ce4bf6ba/tests/firefoxtest.html in a new tab.
2. Open the debugger console
3. Search (via CTRL-p) for "firefoxtest.html" to get the corresponding wysiwyg view. If it cannot be reached, reload the page (this is not the bug I am reporting ,-) )
4. Observe that there are three console.log statements in the HTML. They will be executed sequently (upon completion of AJAX requests, which BTW fail due to cross-site access, but this is not the cause of the problem)
5. Put breakpoints on all three console.log statements, i.e. line 26, 37, 44.
6. DO NOT reload now!
7. Press the (left) "Push me" button on the screen.
8. Observe that your breakpoints have not been reached
9. Check the JS console: all three console statements have been reached (they produced some output).
10. Reload the page. Clean the console.
11. Verify that the breakpoints did not get lost.
12. Click on the "Push me" button again.
13. Observe that the breakpoint for "Second OData Model is available" will be hit (in some cases for me, also the breakpoint for the First Odata Model was hit), but the other breakpoints are not.
14. Check again the JS console: All three entries are hit again.

Running Firefox 38.0.5 x32 on w7 x86

NB: Though running on a wysiwig file only, I also experienced the same issue multiple times on standard JS files (which are <script>-tag loaded).


Actual results:

see 8. and 13.


Expected results:

8. All three breakpoints are hit once they are approached, i.e. the breakpoint is hit, before the output to the console is triggered.
13. All three breakpoints are hit once they are approached.

Comment 1

[Nico Schmoigl]

Update:
* I deactivated all my addons (incl. ADB Helper 0.7.4) - no difference for me (switching them on again afterwards).
* Currently, only the breakpoint at line 37 is hit. If I remove that breakpoint @ line 37, the breakpoint at line 44 is hit. Adding another breakpoint in line 45 and pressing F8 (continue) once line 44 is hit, leads to the result that the breakpoint @ line 45 is also hit, but the breakpoint at line 26 (which is logically after line 45) is not.

Comment 2

[Nico Schmoigl]

Attachment: File used in test case

Downloaded version of the file on github which is being used in the test case; issue there is also reproducable (but allows bypassing the entire dynamic loading).

Wit this file (stored locally - no HTTP involved) the following result of the test case above is observable:
* Setting all three break points
* Breakpoint at "First OData Model is available" is hit
* Breakpoint at "Second OData Model is available" is NOT hit (but was printed to the console even before "First OData Model is available"
* Breakpoint at "Both have been resolved" is hit.

Comment 3

[Nico Schmoigl]

Better URL for step 1: http://eaglerainbow.github.io/openui5/tests/firefoxtest.html

Comment 4

[Hallvord R. M. Steen [:hallvors]]

Something to do with promises? (TC uses jQuery deferred). I recall there was some discussion of breakpoints and promises a little while ago..

Comment 5

[James Long (:jlongster)]

This bugs needs to be re-verified. We simplified (in a good way) how breakpoints are set so it should be more robust now. I cannot reproduce the original behavior myself with the attached page. If nobody verifies this in a while, we should close this bug as fixed.

Comment 6

[Hallvord R. M. Steen [:hallvors]]

I've reproduced in a fresh Nightly build. I think it is the mentioned promises issue: setting breakpoints on lines 26, 37 and 44 (inline script) and clicking the "Push me" button in the page, it never stopped on line 44 even though console output confirms that line runs. Although right now the debugger automatically moves the breakpoint I try to set on line 44 to line 47 - not sure why it thinks line 44 can't hold a breakpoint..?

Comment 7

[James Long (:jlongster)]

If there is something about promises being run, it's not a breakpoint bug. The problem is that unfortunately sometimes promises may be resolved even though the debugger is paused. So what's actually happening is the debugger is breaking in both places but only the first place wins out.

There is a bug on file about this and it's high priority to fix. I don't have it on-hand and the person who would know is not online.

Comment 8

[James Long (:jlongster)]

(In reply to Hallvord R. M. Steen [:hallvors] from comment #6)
>  I try to set on line 44 to line
> 47 - not sure why it thinks line 44 can't hold a breakpoint..?

If you can reproduce that, can you please make a video? That really should not happen anymore.

Comment 9

[Nico Schmoigl]

I just repeated the steps as described in my original bug report (using URL http://eaglerainbow.github.io/openui5/tests/firefoxtest.html) with the newest nightly version (48.0a1, 2016-03-25 on x32). Situation still is mainly the same as in comment #1:

If all three breakpoints are set, the breapoint @ line 44 is not considered (but the console output is provided). If you continue in this situation, the breakpoint @ line 26 is also hit.

If you remove the breakpoint @ line 37, then suddenly the breakpoint @ line 44 is reached (as well as the breakpoint in line 26 later on). 

I cannot observe the situation any longer, that setting a breakpoint at line 44 would let it jump to line 47. 

In reply to comment #7:
> The problem is that unfortunately sometimes promises may be resolved even 
> though the debugger is paused. So what's actually happening is the debugger 
> is breaking in both places but only the first place wins out.

That is a very unfortunate behaviour - especially, if someone is debugging a time-critical issue (or the bug depends on the sequence of roundtrips), you most likely want to see, which one comes first. If then one or the other of the two breakpoint fail, you exactly miss the important point. 
I could imagine that this is also the case here:
What the JS coding mainly does is to trigger two HTTP roundtrips to a backend. Once the corresponding jquery Promise of the corresponding request is resolved, it prints out a console log entry to state so. Finally, the breakpoint @ line 26 is the AND aggregation of these two resolutions: once both promises are rsolved, also that promise is resolved, and a corresponding log message is written to the console. 

Therefore, this bug report may be a duplicate to the one, which you, James, mentioned. If someone could pass me the number of the bugzilla, I'd have a look, if it matches.

Comment 10

[James Long (:jlongster)]

(In reply to Nico Schmoigl from comment #9)
> 
> In reply to comment #7:
> > The problem is that unfortunately sometimes promises may be resolved even 
> > though the debugger is paused. So what's actually happening is the debugger 
> > is breaking in both places but only the first place wins out.
> 
> That is a very unfortunate behaviour - especially, if someone is debugging a
> time-critical issue (or the bug depends on the sequence of roundtrips), ...

It's extremely unfortunate and we are treating it as a serious issue. It requires a complex fix but I think we have plans to fix it in the next few months. The bug is bug 1145201

Comment 11

[Nico Schmoigl]

> It's extremely unfortunate and we are treating it as a serious issue. It
> requires a complex fix but I think we have plans to fix it in the next few
> months. The bug is bug 1145201

I had a look at the bug - yes, that is very ugly. I think that my problem here is related, but is not 100% covered by bug 1145201: Playing around with setting breakpoints in various lines of both promises at https://bug1145201.bmoattachments.org/attachment.cgi?id=8597556, I was not able to reproduce this issue so far. However, the concurrent (and thus implicit) execution of code in a single-threaded language like JS, even if the debugger has paused the execution, would at least explain partially, why in my case the log record on the JS console is written at all. I could imagine that missing the breakpoint might just be a side effect, which will be gone, once bug 1145201 is fixed.

That is why I would like to suggest
* marking this bug as being dependent on bug 1145201 and waiting until the latter it is fixed,
* thereafter validating if this issue here still occurs.

Comment 12

[James Long (:jlongster)]

Sounds good to me. I will ping my coworker next week to see where we stand on that bug

Comment 13

[Hallvord R. M. Steen [:hallvors]]

I can verify that the "can't set breakpoint on line 44" problem is gone in current nightlies. The issue this report is about is still present, but hopefully when bug 1145201 gets fixed this will start working too and we can just resolve it as a duplicate at that point.

Comment 14

[Nico Schmoigl]

agreed and confirmed: "can't set breakpoint on line 44" is gone with current nightly. Other issue with not hitting the breakpoint that was set is still in there (see bug #1445201)

Comment 15

[Jason Laster [:jlast]]

Honza, could you look into this?

Comment 16

[Jan Honza Odvarko [:Honza] (always need-info? me)]

This is fixed in the latest Debugger version, closing.
Honza