912924 - The debugger doesn't always stop at some breakpoints

Status: RESOLVED WORKSFORME

(DevTools :: Debugger, defect, P2)

Description

[dade]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20130904030204

Steps to reproduce:

I use firefox nightly on a mac os 10.8.4. I also tried with aurora on a clean profile. Stable version of firefox do not show this problem.

The firefox devtools debugger does not stop at breakpoints i set in my code, not all of them. I found the problem while developing a page that includes facebook js library and i was not able to make it happen without it.

I created a simple jsfiddle to reproduce it:
http://jsfiddle.net/davibe/BsrKz/19/

You just have to open the firefox devtool debugger, refresh the page, and set breakpoints as explained in the code.



Actual results:

What happens is that the first two breakpoints work fine, the others do not. Also it's not possible to step into the function at the second breakpoint.

Also nothe that the code is executed even when breakpoints are not hit.


Expected results:

The execution should stop at all breakpoints.

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I'm not hitting those breakpoints, nor getting any of those logs in the console, are you sure that the code is being run? I added an alert before the debugger statement and it isn't being alerted either.

Comment 2

[dade]

Yes i'm sure. Open the debugger tab, then refresh the page. The script executes on load that's why you need to reload the page.

Wait for it to break at "debugger;" instruction then manually the add breakpoints on the proper lines as explained by the comments. Then hit "continue" and see what happens.

Comment 3

[dade]

Attachment: debugger breakpoints

I added a screenshot to show how breakpoints should be placed and also to show that the code actually runs after a refresh on page load (see that it first breaks at "debugger;" instruction)

Comment 4

[Panos Astithas (he/him) [:past] (please ni?)]

I get the following in the console:

DBG-SERVER: Got an exception during TA__pauseAndRespond: can't access dead object:
TA__paused@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:1689
TA__pauseAndRespond@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:697
BA_hit@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:3262
log@http://fiddle.jshell.net/davibe/BsrKz/19/show/:32
@http://fiddle.jshell.net/davibe/BsrKz/19/show/:44
r/u.__wrapper@http://connect.facebook.net/en_US/all.js?_=1379507290107:78
g.prototype.inform@http://connect.facebook.net/en_US/all.js?_=1379507290107:41
ea/ha@http://connect.facebook.net/en_US/all.js?_=1379507290107:74
ba/<@http://connect.facebook.net/en_US/all.js?_=1379507290107:74
ca/ja<.redirect_uri<@http://connect.facebook.net/en_US/all.js?_=1379507290107:74
la@http://connect.facebook.net/en_US/all.js?_=1379507290107:73
.init/<@http://connect.facebook.net/en_US/all.js?_=1379507290107:72
h/<@http://connect.facebook.net/en_US/all.js?_=1379507290107:47
h/<@http://connect.facebook.net/en_US/all.js?_=1379507290107:47

We probably should be updating the thread actor's reference to the window global on navigation.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: Ignore dead wrappers when clearing DOM event breakpoints

So this patch fixes the problem, even though I haven't quite figured out why the debuggee is being garbage-collected. It may have the same root cause as bug 900045, which we haven't understood yet, but since the STR in this bug use Facebook Connect, I don't know how to write a test case.

Comment 6

[Panos Astithas (he/him) [:past] (please ni?)]

I managed to get a reduced web page reproducing this problem, so I'll create a test for it.

Comment 7

[Panos Astithas (he/him) [:past] (please ni?)]

So I can no longer reproduce the problem in my reduced test case with the latest nightly and the STR from comment 0 now don't even pause on the debugger statement. *sigh*

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

I've gone back at cset 54f0359f93bf which was a day before my comment 4 and I still get different results. I'm beginning to consider alien abduction.

Comment 9

[Codacoder]

I see this a lot (carefully chosen words) on Win7.

@Panos: do you think this is related to Bug 901930 ?

Comment 10

[Panos Astithas (he/him) [:past] (please ni?)]

I'm not sure, but I am going to get back at this bug soon to figure out what is going on.

Comment 11

[Codacoder]

Would a DMD build help (see what was provided to me under Bug 936784)? Since I can't provide a URL or repeatable STR, I'll carry out that sort of test with a suitable build, it it helps.

Comment 12

[Panos Astithas (he/him) [:past] (please ni?)]

Tried to reproduce again today, but was blocked by bug 960513 and bug 960514.

Comment 13

[Panos Astithas (he/him) [:past] (please ni?)]

Besides bug 960514, which doesn't affect nightlies (or optimized builds), I can no longer reproduce the bug using the STR in comment 0. dade, can you please try to reproduce it yourself using the latest Nightly?

Comment 14

[Panos Astithas (he/him) [:past] (please ni?)]

Closing per comment 13. Feel free to reopen if you are able to reproduce it.