Assertion failure: !lookup(aLookup).found(), at mozilla/HashTable.h:2172 with setWatchtowerCallback
Categories
(Core :: JavaScript Engine, defect, P1)
Tracking
()
People
(Reporter: decoder, Unassigned)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: assertion, regression, testcase, Whiteboard: [bugmon:update,bisected,confirmed])
Attachments
(2 files)
The following testcase crashes on mozilla-central revision 20221011-5cbd3d92a78c (debug build, run with --fuzzing-safe --cpu-count=2 --ion-offthread-compile=off):
test = function(a,b) {
try {
testBasic(a);
testBasic(b);
} catch(exc) {}
}
setWatchtowerCallback(function(kind, object) {
test(object, o33);
});
testBasic();
function testBasic() {
o33 = testBasic;
addWatchtowerTarget(o33);
o33.y81 = 2;
}
Backtrace:
received signal SIGSEGV, Segmentation fault.
#0 0x0000555556fe464d in js::PropMapTable::init(JSContext*, js::LinkedPropMap*) ()
#1 0x0000555556fe5391 in js::LinkedPropMap::createTable(JSContext*) ()
#2 0x0000555556df8fb7 in js::PropMap::lookup(JSContext*, unsigned int, JS::PropertyKey, unsigned int*) ()
#3 0x000055555781331a in js::jit::SetNativeDataPropertyPure(JSContext*, JSObject*, js::PropertyName*, JS::Value*) ()
#4 0x00001b6621d6550b in ?? ()
[...]
#16 0x0000000000000000 in ?? ()
rax 0x55555584c7ad 93824995346349
rbx 0x0 0
rcx 0x5555582f47a8 93825040074664
rdx 0x0 0
rsi 0x7ffff7105770 140737338431344
rdi 0x7ffff7104540 140737338426688
rbp 0x7fffffe0e1b0 140737486315952
rsp 0x7fffffe0e170 140737486315888
r8 0x7ffff7105770 140737338431344
r9 0x7ffff7f99800 140737353717760
r10 0x0 0
r11 0x0 0
r12 0x0 0
r13 0x7ffff6006a60 140737320610400
r14 0x1acf3675fb38 29477274254136
r15 0x7ffff6006a80 140737320610432
rip 0x555556fe464d <js::PropMapTable::init(JSContext*, js::LinkedPropMap*)+1453>
=> 0x555556fe464d <_ZN2js12PropMapTable4initEP9JSContextPNS_13LinkedPropMapE+1453>: movl $0x87c,0x0
0x555556fe4658 <_ZN2js12PropMapTable4initEP9JSContextPNS_13LinkedPropMapE+1464>: callq 0x555556c3b370 <abort>
Not sure if this is s-s, it could also just be a problem with the watchtower helper functions, but marking s-s until triaged to be sure.
Reporter | ||
Comment 1•2 years ago
|
||
Reporter | ||
Comment 2•2 years ago
|
||
Updated•2 years ago
|
Comment 3•2 years ago
|
||
Bugmon Analysis
Verified bug as reproducible on mozilla-central 20221011093208-5cbd3d92a78c.
The bug appears to have been introduced in the following build range:
Start: dd643f695943a4285476f93e279d4ad8870ddf4b (20220128125906)
End: 6b946c5f5eb8e91395cd70da43319cb7b1bd2cc7 (20220128130720)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=dd643f695943a4285476f93e279d4ad8870ddf4b&tochange=6b946c5f5eb8e91395cd70da43319cb7b1bd2cc7
Updated•2 years ago
|
Comment 4•2 years ago
|
||
This is another problem with the watchtower testing function: when adding a property we invoke the callback, but the callback can end up adding a property with that same name and then we add it twice, breaking invariants.
To fix this and bug 1782495, I'll probably have to move this away from a callback and use a log-based system. Running arbitrary JS code just doesn't work well with fuzzing.
Simpler test:
let o = {};
addWatchtowerTarget(o);
let count = 0;
setWatchtowerCallback(function(kind, object) {
if (count++ < 20) {
o.foo = 2;
}
});
o.foo = 1;
assertEq(o.foo, 1);
Comment 5•2 years ago
|
||
Setting Regressed by
field after analyzing regression range found by bugmon in comment #3.
Comment 6•2 years ago
|
||
Set release status flags based on info from the regressing bug 1750962
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 8•2 years ago
|
||
No valid actions for resolution (DUPLICATE).
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.
Description
•