Fixed
Status Update
No update yet.
Comments
sh...@gmail.com
This worked as expected in Chrome 131 (Chromium 131.0.6778.70 V8 V8 13.1.201.8), so the regression specifically happened in the 132 release.
More context (including a user comment that this works as expected in Safari and Firefox):https://git.sheetjs.com/sheetjs/sheetjs/issues/3273
More context (including a user comment that this works as expected in Safari and Firefox):
ka...@google.com
Updating observations
=================
Able to reproduce the issue on chrome version #132.0.6834.83 as provided in
Reproducible on:
-----------------------
132.0.6834.83 - Stable
133.0.6943.16 - Beta
134.0.6958.2 - Dev
134.0.6968.0 - Canary
Bisect Info:
------------------
Good: 132.0.6796.0
Bad : 132.0.6797.0
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/d83fe9f5b691384ea8eda6c7a0d9c121432e5fbc..633e739455b55a5555c3a0cf92e5370e8b9c95eb
Suspect 1:-https://chromium.googlesource.com/v8/v8.git/+/b63f8324e86885a1c5b446e78492249ffdac6f51
Suspect 2:-https://chromium.googlesource.com/v8/v8.git/+/9e5b9c25a43bcc446f2aaf57817e4e4d6d027079
Unable to identify the appropriate suspect from the above changelog due to lot of suspects. Looping Marja Hölttä@ and Stephen Roettge@ from the above suspects for futhur inputs and Requesting to help route the issue to the correct owner.
As issue got regressed in M132 chrome builds, hence adding RBS to it, feel free to remove if not the case.
Thanks..!
=================
Able to reproduce the issue on chrome version #132.0.6834.83 as provided in
Reproducible on:
-----------------------
132.0.6834.83 - Stable
133.0.6943.16 - Beta
134.0.6958.2 - Dev
134.0.6968.0 - Canary
Bisect Info:
------------------
Good: 132.0.6796.0
Bad : 132.0.6797.0
CHANGELOG URL:
Suspect 1:-
Suspect 2:-
Unable to identify the appropriate suspect from the above changelog due to lot of suspects. Looping Marja Hölttä@ and Stephen Roettge@ from the above suspects for futhur inputs and Requesting to help route the issue to the correct owner.
As issue got regressed in M132 chrome builds, hence adding RBS to it, feel free to remove if not the case.
Thanks..!
sr...@google.com
ma...@chromium.org
Yep, it's that commit (a good suspicion, kattupalli@!)
commit b63f8324e86885a1c5b446e78492249ffdac6f51
Author: Marja Hölttä <marja@chromium.org>
Date: Thu Oct 24 08:37:06 2024 +0200
Reland: [collections] Support big WeakMaps
The hashes stored in JSReceivers are maximally 20
bits. If a hash table is bigger than that, all
items get clumped in the beginning.
This CL distributes the probes more evenly in big
hash tables. It's still not optimal (there will be
empty space because of quadratic probing) but it's
better than the previous solution.
Side fix: "are we running out of capacity" computation
in RehashObjectHashTableAndGCIfNeeded was too pessimistic
(it added slack twice, first there and once in
ComputeCapacity).
Bug: 42207427,375033082
Change-Id: Ic53052421459165b4cdecc3052fb8bf480c9373d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5961516
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#96798}
pe...@google.com
This issue appears to be blocking an upcoming release and is therefore an Urgent Release Blocking Issue as per
If this is not a release blocking issue, please adjust the release block field. Adjusting the priority will have no affect, P0 will be re-applied whilever this is marked as a release blocking issue.
ma...@chromium.org
da...@google.com
Had a quick chat with
ka...@gmail.com
This seems also to affect iterating over a large object with a for .. in loop and is not depending on the object being returned from a function
The following code works (ie count1 === count2) for upper === 699000 but fails for upper === 699900 (ie count1 === 699900 but count2 === 0 on the first run and count2 === 848 on subsequent runs in the developer console)
let foo = {};
let upper = 699900;
for (let i = 0; i < upper; i++)
foo[`k_${i}`] = `v_${i}`;
let count1 = Object.keys(foo).length;
let count2 = 0;
for (let p in foo)
count2++;
console.log(count1, count2)
Environment: Version 132.0.6834.84 (Official Build) (64-bit) on Windows 11
ma...@chromium.org
pe...@google.com
M133 merge request created. Please update crbug/391291575 to have this merge reviewed.
*This merge request uses Chrome's new merge process. Find more information at
ju...@ai4plan.com
Do that mean that you guys do not have a single test that try to access a property of large object in your code base ? I would suggest to add one...
ap...@google.com
Project: v8/v8
Branch: chromium/6970
Author: Marja Hölttä <
Link:
Revert "Reland: [collections] Support big WeakMaps"
Expand for full commit details
Revert "Reland: [collections] Support big WeakMaps"
This reverts commit b63f8324e86885a1c5b446e78492249ffdac6f51.
Reason for revert: https://issues.chromium.org/u/1/issues/390568195
Original change's description:
> Reland: [collections] Support big WeakMaps
>
> The hashes stored in JSReceivers are maximally 20
> bits. If a hash table is bigger than that, all
> items get clumped in the beginning.
>
> This CL distributes the probes more evenly in big
> hash tables. It's still not optimal (there will be
> empty space because of quadratic probing) but it's
> better than the previous solution.
>
> Side fix: "are we running out of capacity" computation
> in RehashObjectHashTableAndGCIfNeeded was too pessimistic
> (it added slack twice, first there and once in
> ComputeCapacity).
>
> Bug: 42207427,375033082
> Change-Id: Ic53052421459165b4cdecc3052fb8bf480c9373d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5961516
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#96798}
Bug: 42207427,375033082,390568195
Change-Id: I94eccc338eac9491d5ed1bfdb63dbca99d348415
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6182368
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#98213}
(cherry picked from commit 7afac4e1f9ac8b36649bfc61728ee6d858a62c9f)
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6186010
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Lutz Vahl <vahl@chromium.org>
Reviewed-by: Lutz Vahl <vahl@chromium.org>
Commit-Queue: Lutz Vahl <vahl@chromium.org>
Files:
- M
src/builtins/builtins-collections-gen.cc - M
src/builtins/builtins-collections-gen.h - M
src/objects/hash-table.h - M
src/objects/objects.cc - D
test/mjsunit/es6/big-weakmap.js - M
test/mjsunit/mjsunit.status
Hash: f799cffda5a9578e559a7297b77796f3915baad0
Date: Tue Jan 21 00:46:20 2025
ap...@google.com
Project: v8/v8
Branch: chromium/6834_101
Author: Marja Hölttä <
Link:
Revert "Reland: [collections] Support big WeakMaps"
Expand for full commit details
Revert "Reland: [collections] Support big WeakMaps"
This reverts commit b63f8324e86885a1c5b446e78492249ffdac6f51.
Reason for revert: https://issues.chromium.org/u/1/issues/390568195
Original change's description:
> Reland: [collections] Support big WeakMaps
>
> The hashes stored in JSReceivers are maximally 20
> bits. If a hash table is bigger than that, all
> items get clumped in the beginning.
>
> This CL distributes the probes more evenly in big
> hash tables. It's still not optimal (there will be
> empty space because of quadratic probing) but it's
> better than the previous solution.
>
> Side fix: "are we running out of capacity" computation
> in RehashObjectHashTableAndGCIfNeeded was too pessimistic
> (it added slack twice, first there and once in
> ComputeCapacity).
>
> Bug: 42207427,375033082
> Change-Id: Ic53052421459165b4cdecc3052fb8bf480c9373d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5961516
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#96798}
Bug: 42207427,375033082,390568195
Change-Id: I94eccc338eac9491d5ed1bfdb63dbca99d348415
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6182368
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#98213}
(cherry picked from commit 7afac4e1f9ac8b36649bfc61728ee6d858a62c9f)
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6187521
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Lutz Vahl <vahl@chromium.org>
Reviewed-by: Lutz Vahl <vahl@chromium.org>
Commit-Queue: Lutz Vahl <vahl@chromium.org>
Files:
- M
src/builtins/builtins-collections-gen.cc - M
src/builtins/builtins-collections-gen.h - M
src/objects/hash-table.h - M
src/objects/objects.cc - D
test/mjsunit/es6/big-weakmap.js - M
test/mjsunit/mjsunit.status
Hash: 5b7523975ebcc89319148c4c76bef41fa85a7619
Date: Tue Jan 21 00:46:20 2025
go...@google.com
This is V8 so it will be applicable to Android & Chrome OS as well.
Any Android Webview specific impact?
Any Android Webview specific impact?
go...@google.com
Per chat with torne@, this looks pretty serious and seems like it's going to affect everything. OK to stay 10% for Webview and respin tomorrow along with clank.
go...@google.com
This also needs a merge to V8 M132 &M133 main branches.
Merge approved for M132 & M133, please see for branch details -https://chromiumdash.appspot.com/branches
Merge approved for M132 & M133, please see for branch details -
ly...@google.com
Reproduced on Pixel 7a / AP3A.241005.015.A2, Chrome version 134.0.6958.0
al...@google.com
Hi Krishna, how does this affect ChromeOS M132? We are testing a new version today: 132.0.6834.99 - build 16093.73.
DO you know at what version the regression started?
sr...@chromium.org
From comment above - #3
Bisect Info:
------------------
Good: 132.0.6796.0
Bad : 132.0.6797.0
its a regression in M132 , so we are blocking ramp up to 100% for desktop and android and taking in respin.,
The CL has not merged to M132 branch, V8 team has mentioned they will merge the change to m132 branch tonight, so if you have already cut RC, you would need to recut your RC build
Bisect Info:
------------------
Good: 132.0.6796.0
Bad : 132.0.6797.0
its a regression in M132 , so we are blocking ramp up to 100% for desktop and android and taking in respin.,
The CL has not merged to M132 branch, V8 team has mentioned they will merge the change to m132 branch tonight, so if you have already cut RC, you would need to recut your RC build
go...@google.com
Requesting to verify the fix on Android Canary #134.0.6971.2 once available and Stable RC #132.0.6834.122.
sr...@chromium.org
Incident for this issue - irm/i_Dj6ixBJGx7j91VVV8ktq
Please work on PM for this through the incident
Please work on PM for this through the incident
al...@google.com
WebView team:
I was able to reproduce the issue on Webview: 132.0.6797.0 via steps from
I have verified the fix on stable RC: 132.0.6834.122 and WebView Canary: 134.0.6971.2
device used: Pixel 8 Pro / UQ1A.240205.004
I was able to reproduce the issue on Webview: 132.0.6797.0 via steps from
I have verified the fix on stable RC: 132.0.6834.122 and WebView Canary: 134.0.6971.2
device used: Pixel 8 Pro / UQ1A.240205.004
ma...@chromium.org
We're now working on merging the fix to all possible Chrome versions.
sheetjs: Thanks for the repro, this bug was very quick to figure out based on the groundwork you did before filing this. We were able to get the fix to users much faster because this bug report was so clear. Kudos!
jo...@googlemail.com
I had the same issue in production. (see
console.log("start");
let tags = [];
let wr = 965536;
for (let i = 0; i <= wr; i++) {
tags["CS.FA01.ERRORS_Places.HT3001.STOE_Bit00_"+i] = {nr:i};
}
for (let i = 0; i <= wr; i++) {
let key = "CS.FA01.ERRORS_Places.HT3001.STOE_Bit00_"+i;
if (tags[key] == null)
{
let idx = Object.keys(tags).indexOf(key);
console.log("obj is null, " + idx);
}
}
console.log("end");
ap...@google.com
Project: v8/v8
Branch: refs/branch-heads/13.2
Author: Marja Hölttä <
Link:
[merged] Revert "Reland: [collections] Support big WeakMaps"
Expand for full commit details
[merged] Revert "Reland: [collections] Support big WeakMaps"
This reverts commit b63f8324e86885a1c5b446e78492249ffdac6f51.
Reason for revert: https://issues.chromium.org/u/1/issues/390568195
Original change's description:
> Reland: [collections] Support big WeakMaps
>
> The hashes stored in JSReceivers are maximally 20
> bits. If a hash table is bigger than that, all
> items get clumped in the beginning.
>
> This CL distributes the probes more evenly in big
> hash tables. It's still not optimal (there will be
> empty space because of quadratic probing) but it's
> better than the previous solution.
>
> Side fix: "are we running out of capacity" computation
> in RehashObjectHashTableAndGCIfNeeded was too pessimistic
> (it added slack twice, first there and once in
> ComputeCapacity).
>
> Bug: 42207427,375033082
> Change-Id: Ic53052421459165b4cdecc3052fb8bf480c9373d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5961516
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#96798}
(cherry picked from commit 7afac4e1f9ac8b36649bfc61728ee6d858a62c9f)
Bug: 42207427,375033082,390568195
Change-Id: I94eccc338eac9491d5ed1bfdb63dbca99d348415
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6182368
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Original-Commit-Position: refs/heads/main@{#98213}
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6187531
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/branch-heads/13.2@{#66}
Cr-Branched-From: 24068c59cedad9ee976ddc05431f5f497b1ebd71-refs/heads/13.2.152@{#1}
Cr-Branched-From: 6054ba94db0969220be4f94dc1677fc4696bdc4f-refs/heads/main@{#97085}
Files:
- M
src/builtins/builtins-collections-gen.cc - M
src/builtins/builtins-collections-gen.h - M
src/objects/hash-table.h - M
src/objects/objects.cc - D
test/mjsunit/es6/big-weakmap.js - M
test/mjsunit/mjsunit.status
Hash: 6009291949459c115d3038b2049707ebe31ea9dd
Date: Tue Jan 21 00:46:20 2025
ap...@google.com
Project: v8/v8
Branch: refs/branch-heads/13.3
Author: Marja Hölttä <
Link:
[merged] Revert "Reland: [collections] Support big WeakMaps"
Expand for full commit details
[merged] Revert "Reland: [collections] Support big WeakMaps"
This reverts commit b63f8324e86885a1c5b446e78492249ffdac6f51.
Reason for revert: https://issues.chromium.org/u/1/issues/390568195
Original change's description:
> Reland: [collections] Support big WeakMaps
>
> The hashes stored in JSReceivers are maximally 20
> bits. If a hash table is bigger than that, all
> items get clumped in the beginning.
>
> This CL distributes the probes more evenly in big
> hash tables. It's still not optimal (there will be
> empty space because of quadratic probing) but it's
> better than the previous solution.
>
> Side fix: "are we running out of capacity" computation
> in RehashObjectHashTableAndGCIfNeeded was too pessimistic
> (it added slack twice, first there and once in
> ComputeCapacity).
>
> Bug: 42207427,375033082
> Change-Id: Ic53052421459165b4cdecc3052fb8bf480c9373d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5961516
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#96798}
(cherry picked from commit 7afac4e1f9ac8b36649bfc61728ee6d858a62c9f)
Bug: 42207427,375033082,390568195
Change-Id: I94eccc338eac9491d5ed1bfdb63dbca99d348415
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6182368
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Original-Commit-Position: refs/heads/main@{#98213}
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6186578
Auto-Submit: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/branch-heads/13.3@{#28}
Cr-Branched-From: 41dacffe436aeb9311879cb07648f1e36609a804-refs/heads/13.3.415@{#1}
Cr-Branched-From: 3348638c0af67c885b30891a358c89a917ac9759-refs/heads/main@{#97937}
Files:
- M
src/builtins/builtins-collections-gen.cc - M
src/builtins/builtins-collections-gen.h - M
src/objects/hash-table.h - M
src/objects/objects.cc - D
test/mjsunit/es6/big-weakmap.js - M
test/mjsunit/mjsunit.status
Hash: 6a262f211235dfce024220c417f0e10066aef322
Date: Tue Jan 21 00:46:20 2025
ka...@google.com
Verified the fix on the latest canary M132#132.0.6834.110 using Win 11, Mac 14.7.2 and Linux debian as per
Observed Objects returned from functions are not losing properties
Hence, the fix is working as expected and adding verified labels
Attaching screenshots for reference
Thanks..!!
Observed Objects returned from functions are not losing properties
Hence, the fix is working as expected and adding verified labels
Attaching screenshots for reference
Thanks..!!
kr...@google.com
"Chrome on Android" - Verified on 132.0.6834.122 and it is working as expected
go...@google.com
sa...@google.com
Verified the fix on ash-chrome M132 Stable RC #132.0.6834.154/16093.78.0 on Pantheon(Nami - x86_64) device as per
Observed Objects returned from functions are not losing properties
Hence, the fix is working as expected and adding verified labels
Attaching screenshots for reference
Thanks..!!
Observed Objects returned from functions are not losing properties
Hence, the fix is working as expected and adding verified labels
Attaching screenshots for reference
Thanks..!!
ap...@google.com
Project: v8/v8
Branch: main
Author: Marja Hölttä <
Link:
[test] Add a regression test
Expand for full commit details
[test] Add a regression test
This test creates an object with 700 k properties, so it's a bit slow
and should only run in fast configurations.
Bug: 390568195
Change-Id: I8c391d6a5ebaae68abf9ef55a2bf4a8dd0de132b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6190893
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#98302}
Files:
- M
test/mjsunit/mjsunit.status - A
test/mjsunit/regress/regress-390568195.js - M
tools/clusterfuzz/js_fuzzer/exceptions.js
Hash: 8afc4bb6114b959f0ac400041a73c9dd0ada1e39
Date: Thu Jan 23 13:05:55 2025
ap...@google.com
Project: v8/v8
Branch: main
Author: Marja Hölttä <
Link:
[collections] Alternative fix for supporting big WeakMaps
Expand for full commit details
[collections] Alternative fix for supporting big WeakMaps
The hashes stored in JSReceivers are maximally 20
bits. If a hash table is bigger than that, all
items get clumped in the beginning.
This CL distributes the probes more evenly in big
hash tables. It's still not optimal (there will be
empty space because of quadratic probing) but it's
better than the previous solution.
Side fix: "are we running out of capacity" computation
in RehashObjectHashTableAndGCIfNeeded was too pessimistic
(it added slack twice, first there and once in
ComputeCapacity).
The previous version
https://chromium-review.googlesource.com/c/v8/v8/+/5961516
was applying the hash spreading logic to all HashTables,
while it's only intended for EphemeronHashTable. This CL
fixes that.
Bug: 42207427, 375033082, 390568195
Change-Id: I78dd3f904554fbbe224e4406e79ccb86e7cd7516
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6187094
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#98303}
Files:
- M
src/builtins/builtins-collections-gen.cc - M
src/builtins/builtins-collections-gen.h - M
src/codegen/code-stub-assembler.cc - M
src/objects/compilation-cache-table.h - M
src/objects/dictionary.h - M
src/objects/hash-table-inl.h - M
src/objects/hash-table.h - M
src/objects/objects-inl.h - M
src/objects/objects.cc - M
src/objects/string-set.h - A
test/mjsunit/es6/big-weakmap.js - M
test/mjsunit/mjsunit.status
Hash: 4665c7dd54c1019a035517706a44b28997ed90b9
Date: Fri Jan 24 11:22:48 2025
Description
Steps to reproduce the problem
Problem Description
The
make_objfunction returns a JavaScript object. The"!ref"property is assigned to the object.The first
console.logstatement shows that the value is 3.After calling the function, the second
console.logstatement inspects the same property. It isundefined.This worked in Chromium 129.0.6668.100
Additional Comments
Build which worked: Chromium 129.0.6668.100 V8 12.9.202.27
Build which is failing: Chromium 132.0.6834.83 V8 13.2.152.27
Summary
Objects returned from functions are losing properties
Additional Data
Category: JavaScript
Chrome Channel: Stable
Regression: Yes