Watched local scope variables display garbage data in Javascript Debugger

VERIFIED FIXED in mozilla1.9.1b4

Status

()

P1
major
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: morac, Assigned: mrbkap)

Tracking

({fixed1.9.1, regression})

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

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(3 attachments)

(Reporter)

Description

10 years ago
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.
(Reporter)

Comment 1

10 years ago
Created attachment 373315 [details]
Watch of local variable in Firefox 3.5b4pre load

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).
(Reporter)

Comment 2

10 years ago
Created attachment 373316 [details]
Watch of local variable in trunk load

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.

Comment 3

10 years ago
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)
(Reporter)

Comment 4

10 years ago
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.

Comment 5

10 years ago
Hmm, maybe bug 480765?
(Reporter)

Comment 6

10 years ago
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.
(Reporter)

Comment 7

10 years ago
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.

Comment 8

10 years ago
(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
(Reporter)

Comment 9

10 years ago
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?
(Reporter)

Comment 10

10 years ago
As I feared/expected this is now broken in Firefox 3.5b4pre as of the Gecko/20090418 1.9.1 branch load.

Updated

10 years ago
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

Comment 12

10 years ago
(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)

Updated

10 years ago
Assignee: brendan → mrbkap

Updated

10 years ago
Severity: normal → major
(Reporter)

Comment 13

10 years ago
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.
(Assignee)

Comment 14

10 years ago
Created attachment 373746 [details] [diff] [review]
Restore missing check

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
(Assignee)

Comment 16

10 years ago
http://hg.mozilla.org/mozilla-central/rev/8ecdcd32c27a and http://hg.mozilla.org/tracemonkey/rev/77a2e94b0262
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-tracemonkey

Updated

10 years ago
Flags: blocking1.9.1? → blocking1.9.1+
(Reporter)

Comment 19

10 years ago
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.