1658546 - FireFox paused on breakpoint when there is no any breakpoint

Status: NEW

(DevTools :: Debugger, defect, P3)

Description

[Eugen Konkov]

Attachment: _.jpg

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

I open debugger panel (F12) and refresh the page.

Actual results:

Firefox pauses on breakpoint when there is no any breakpoint

Expected results:

FireFox should not stop on code lines without breakpoints.

How to workaround: put breakpoint and remove it. Then I can continues.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

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

Thanks for the report Eugen!

Is there any way how to reproduce the problem? Can you still see it on your machine.

We can't do much without reproducible test case.

Honza

Comment 3

[Eugen Konkov]

it looks like some memory leak. Its random.
At some point it stops on lines in files that I do not open.

I use http://tabulator.info/ library. and when I open dev.tools debugger starts to stop somewhere inside tabulator.js

Comment 4

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

Any chance you could share your web page?
Does it happen when you create a new Firefox profile? If yes, what's the difference between your old profile and new profile?

Honza

Comment 5

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

I am keeping this report open since I've seen that before.
We need STRs to make a progress on it.

Honza

Comment 6

[B.J. Herbison]

I've seen the problem. It appears to happen with these steps:

• Debug the code using breakpoints.
• Remove or disable the breakpoints.
• Change the code.
• Reload the web page in the current tab.

In some cases the debugger seems to break on the same line number as a previous breakpoint. It seems that some information about the disabling of the breakpoint is lost when the new code is loaded.

It's been in the back of my mind to come up with more details about when it happens, but when it happens I'm using thinking "just kill that breakpoint so I can find my own bug".

Comment 7

[mattheww]

I've been running into this as well lately, and I think I have steps to reproduce it. It might not be the exact same thing but it consistently produces phantom breakpoints.
1.

function beep() {
    return "beep";
}

function boop() {
    var temp = "boop";
    return temp;
}

console.log("🤖", beep(), boop());

2. Set a breakpoint on the body of beep (line 2).
3. Edit the js file and swap the names of the two functions - just lines 1 and 5, not the function bodies.
4. Reload the page and you should pause on line 2, where you set your breakpoint, but with no breakpoint visible.
   If you remove the second function or rename it to something else, the breakpoint shows up again.

It looks like the breakpoint still exists and is sent to the page as a pending breakpoint, then later syncBreakpoints() finds the function name previously associated with the breakpoint, sees that it can't break on the same line offset+column as before, assumes the breakpoint isn't valid at all, and exits without adding a breakpoint marker to the view.

Comment 8

[Hubert Boma Manilla (:bomsy)]

Thanks for the STR Matthew, this is super useful. I could reproduce it.

Any other found consistent STR's are welcome, as i think that there a many other scenarios that lead to these phantom breakpoints.

Comment 9

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

I can also reproduce it (using Win10, FxNightly), thank you.

Honza

Comment 10

[Francois-R.Boyer]

It looks like related to this bug: if I remove or add breakpoints, it is still breaking on the removed breakpoints and not on the new added ones. (I run FF 88.0 on Win 10.) If I close then reopen the Developer Tools window, it's now breaking on the correct breakpoints.

Comment 11

[c.frank]

This seems to be a very long-standing issue, and though I see it rather often, it is very difficult to come up with a reproducible test case. Is there anything Mozilla/Firefox could do to make this easier? I'd like to do something like this:

1. Reset my dev tools in a way that is guaranteed to destroy any existing breakpoints
2. Flip a switch for advanced breakpoint logging
3. Keep working normally until it shows up again
4. Go grab a log file from somewhere and paste it here, along with the file and line number that now contains the phantom breakpoint

Comment 12

[Peter Janes]

I see this quite often on pages where I have had a breakpoint set in a previous version of Firefox; I can't seem to reproduce it in a fresh profile. (It also doesn't happen in private windows in the affected profile.)

The behaviour is slightly different than what was reported in comment #7 (although I can't guarantee it's different): the unexpected breakpoint dialog occurs most often on operations that affect the displayed content of the page, e.g. a page reload, or if a div-based modal dialog is shown over the content.

(Currently running 94.0b9, but it's been happening since at least 90.)

Comment 13

[André Natal]

I'm also seeing this happening on latest Nightly 97.0a1 (2021-12-15) (64-bit) on OSX. Only way to fix was recreating the profile.

Comment 14

[zymptomlabs]

seeing this bug as well on Developer Version 96.0b10 (64-bit)

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:bomsy, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 17

[Mildred Ki'Lya]

Does someone knows where the breakpoints are stored in the profile? Being able to purge this could be very useful when we have this annoying bug.

Comment 18

[Hubert Boma Manilla (:bomsy)]

(In reply to Mildred Ki'Lya from comment #17)

Does someone knows where the breakpoints are stored in the profile? Being able to purge this could be very useful when we have this annoying bug.

Hi Mildred,
You can run this in the browser console to clear the breakpoints

await (async function () {
  var loader = Cu.import("resource://devtools/shared/loader/Loader.jsm", {});
  var asyncStorage = loader.require("devtools/shared/async-storage");
  await asyncStorage.setItem("debugger.pending-breakpoints", {});
  await asyncStorage.setItem("debugger.xhr-breakpoints", []);
})()

We are also doing some work so users can clear them here Bug 1742774

Thanks