Closed
Bug 355339
Opened 18 years ago
Closed 18 years ago
"Assertion failure: sprop->setter != js_watch_set" setting watch after unwatch
Categories
(Core :: JavaScript Engine, defect, P2)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
mozilla1.9alpha1
People
(Reporter: jruderman, Assigned: brendan)
References
Details
(4 keywords)
Attachments
(1 file)
1.18 KB,
patch
|
mrbkap
:
review+
jay
:
approval1.8.0.9+
jay
:
approval1.8.1.1+
|
Details | Diff | Splinter Review |
js> o = {}
[object Object]
js> o.watch("j", function(a,b,c) { print("*",a,b,c) })
js> o.unwatch("j")
js> o.watch("j", function(a,b,c) { print("*",a,b,c) })
Assertion failure: sprop->setter != js_watch_set, at jsdbgapi.c:541
Seems harmless in an opt jsshell.
Reporter | ||
Comment 1•18 years ago
|
||
I can still reproduce this bug.
Reporter | ||
Comment 2•18 years ago
|
||
I think I hit something similar to this with the fuzzer in bug 349611 today.
Assignee | ||
Comment 3•18 years ago
|
||
Updated•18 years ago
|
Attachment #246120 -
Flags: review?(mrbkap) → review+
Assignee | ||
Comment 4•18 years ago
|
||
This isn't just a bogus assertion. In an unpatched optimized shell, this modified version of the testcase:
o = {}
o.watch("j", function(a,b,c) { print("*",a,b,c) })
o.j = 1
o.unwatch("j")
o.j = 2
o.watch("j", function(a,b,c) { print("*",a,b,c) })
o.j = 3
produces this output (abridged):
* j undefined 1
* j 2 3
* j 2 undefined
. . .
* j 2 undefined
watch.js:7: InternalError: too much recursion
The fix is safe and pretty clearly correct. The saved wp->sprop was wrong before, it pointed to the sprop with the original getter and setter, not the one cloned from sprop but with js_watch_set as the setter. The mutated clone is the one to keep in wp->sprop, or else the DropWatchPoint code won't change the mapping in wp->object's scope back to the original sprop.
/be
Flags: blocking1.8.1.1?
Flags: blocking1.8.0.9?
OS: Mac OS X 10.4 → All
Priority: -- → P2
Hardware: Macintosh → All
Target Milestone: --- → mozilla1.9alpha
Assignee | ||
Updated•18 years ago
|
Attachment #246120 -
Flags: approval1.8.1.1?
Attachment #246120 -
Flags: approval1.8.0.9?
Assignee | ||
Comment 5•18 years ago
|
||
Fixed on the trunk:
Checking in jsdbgapi.c;
/cvsroot/mozilla/js/src/jsdbgapi.c,v <-- jsdbgapi.c
new revision: 3.73; previous revision: 3.72
done
/be
Comment 6•18 years ago
|
||
RCS file: /cvsroot/mozilla/js/tests/js1_5/Regress/regress-355339.js,v
done
Checking in regress-355339.js;
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-355339.js,v <-- regress-355339.js
initial revision: 1.1
done
Flags: in-testsuite+
Updated•18 years ago
|
Flags: blocking1.8.1.1?
Flags: blocking1.8.1.1+
Flags: blocking1.8.0.9?
Flags: blocking1.8.0.9+
Comment 7•18 years ago
|
||
Comment on attachment 246120 [details] [diff] [review]
fix
Approved for both branches. a=jay for drivers, please land on the 1.8.0 and 1.8.1 branches asap. Thanks!
Attachment #246120 -
Flags: approval1.8.1.1?
Attachment #246120 -
Flags: approval1.8.1.1+
Attachment #246120 -
Flags: approval1.8.0.9?
Attachment #246120 -
Flags: approval1.8.0.9+
Assignee | ||
Comment 8•18 years ago
|
||
Fixed on the 1.8 branch:
Checking in jsdbgapi.c;
/cvsroot/mozilla/js/src/jsdbgapi.c,v <-- jsdbgapi.c
new revision: 3.56.2.5; previous revision: 3.56.2.4
done
and the 1.8.0 branch:
Checking in jsdbgapi.c;
/cvsroot/mozilla/js/src/jsdbgapi.c,v <-- jsdbgapi.c
new revision: 3.56.2.1.4.2; previous revision: 3.56.2.1.4.1
done
/be
Keywords: fixed1.8.0.9,
fixed1.8.1.1
Comment 9•18 years ago
|
||
verified fixed 20061122 1.8.0.9 windows/linux/mac*, 1.8.1.1 windows/linux/mac*, 1.9 windows/linux
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•