Watched local scope variables display garbage data in Javascript Debugger

VERIFIED FIXED in mozilla1.9.1b4

Status

()

defect
P1
major
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: morac, Assigned: mrbkap)

Tracking

({fixed1.9.1, regression})

unspecified
mozilla1.9.1b4
Points:
---
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(3 attachments)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090416 Firefox/3.5b4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090417 Firefox/3.5b4pre

In the nightly trunk loads, attempting to add a watch for a local scope variable results in seemingly random data being displayed in the watch.  Basically the displayed variables appear to be mapped to some random area of memory.

Because of bug 488842, this effectively makes the Javascript Debugger useless for debugging in the trunk loads.

Reproducible: Always

Steps to Reproduce:
1. Open Javascript Debugger Window
2. Create a breakpoint in a function
3. Cause breakpoint to be hit
4. Add a watch for one of the local scope variables in that breakpoint

Actual Results:  

Garbage data displays in all local watched variables.

Expected Results:  

The correct data should display.
Here's a screen shot of two watched local variables while stopped at a break point in my add-on in Firefox 3.5b4pre (20090416).
Here's a screen shot of the same two watched local variables while stopped at the same break point in my add-on.  This is in the Minefield 20090416 nightly load. As you can see the variables are displaying seemingly random data.
Hi Michael, thanks for your report. Could you find out in which *trunk* build it was last working? (Could be that that was the one for the 15th, but I couldn't deduce this from your report)
Watches work in the 20090408 nightly trunk load and don't work in the 20090409 nightly trunk, so it broke in the 20090409 nightly trunk load.
Hmm, maybe bug 480765?
Bug 480765 supposedly landed on the 1.9.1 branch, but I'm not seeing the problem with the Firefox 3.5b4pre nightly loads so I don't think bug 480765 is the cause.
Also Bug 480765 landed on the trunk back in 20090314 so it's not bug 480765.

Actually the jsd files last changed on April 2nd, so I'm assuming the problem isn't being caused by a change JSD.  Maybe it was caused by a change in TraceMonkey?

I believe if the problem started in 20090409, then the changes must have been checked in on April 8th which would mean one of these two push logs for TraceMonkey merges into the trunk:

http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=907dbdbd084f
http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=92ec42507769


A number of these merged onto the 1.9.1 trunk today so if I see the problem on the 20090418 1.9.1 branch nightly, I'll know one of them caused it.
(In reply to comment #7)
> Also Bug 480765 landed on the trunk back in 20090314 so it's not bug 480765.
> 
> Actually the jsd files last changed on April 2nd, so I'm assuming the problem
> isn't being caused by a change JSD.  Maybe it was caused by a change in
> TraceMonkey?
> 
> I believe if the problem started in 20090409, then the changes must have been
> checked in on April 8th which would mean one of these two push logs for
> TraceMonkey merges into the trunk:
> 
> http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=907dbdbd084f
> http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=92ec42507769
> 
> 
> A number of these merged onto the 1.9.1 trunk today so if I see the problem on
> the 20090418 1.9.1 branch nightly, I'll know one of them caused it.

That sounds great, thanks a lot Michael. And yes, it's most likely a JS side change, as JSD is not changed so often... Does the same regression window apply for bug 488842 ? If so, please leave a comment to that effect there as well.
Keywords: regression
Bug 488842 broke back in June of 2008.  I'll post to bug 488842 once I narrow down an exact date.  As for this bug I think I've narrowed it down to one of these since if the other push caused the problem I would have seen it on the 20090408 load.

http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=92ec42507769

Unfortunately none the bugs that are listed in that set: Bug 487209, Bug 487538, Bug 487534 and Bug 487271; seem an obvious choice.

If it is a JS side change, should the bug still be against JSD?
Also have you been able to confirm this problem?
As I feared/expected this is now broken in Firefox 3.5b4pre as of the Gecko/20090418 1.9.1 branch load.
Flags: blocking1.9.1?
Thanks Michael (why don't you have canconfirm and editbugs already? I'll set 'em for your account). This will be fixed.

To the Robs: we need a better jsd owner and default assignee.

/be
Assignee: rginda → general
Status: UNCONFIRMED → ASSIGNED
Component: Venkman JS Debugger → JavaScript Engine
Ever confirmed: true
OS: Windows XP → All
Priority: -- → P1
Product: Other Applications → Core
QA Contact: venkman → general
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.1b4
Assignee: general → brendan
(In reply to comment #11)
> To the Robs: we need a better jsd owner and default assignee.
> 
> /be

The default assignee is nobody@ now... but yes, a better owner would be a Good Thing.
Assignee: brendan → mrbkap
Severity: normal → major
I'll mention that despite what I originally posted, I've found that what is displayed is not random as I get the same wrong display data every time I run.  I don't know where this data is coming from, but it's consistent.
This check got lost along the way.
Attachment #373746 - Flags: review?(brendan)
Attachment #373746 - Flags: review?(brendan) → review+
Comment on attachment 373746 [details] [diff] [review]
Restore missing check

Oops. Was that all that was wrong?

/be
http://hg.mozilla.org/mozilla-central/rev/8ecdcd32c27a and http://hg.mozilla.org/tracemonkey/rev/77a2e94b0262
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-tracemonkey
Flags: blocking1.9.1? → blocking1.9.1+
Verified fixed:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090527 Firefox/3.5pre (.NET CLR 3.5.30729)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090527 Firefox/3.5pre (.NET CLR 3.5.30729)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.