Version
v26.0.0
Platform
Linux eric-cornelissen-Latitude-7640 6.17.0-29-generic #29~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon May 11 10:30:58 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
node -e 'globalThis.sessionStorage.setItem.length;globalThis.Storage.prototype.length'
or
echo 'globalThis.sessionStorage.setItem.length;globalThis.Storage.prototype.length' >minimal_repro.js
node minimal_repro.js
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior? Why is that the expected behavior?
No segfault, for this particular program not output.
What do you see instead?
$ node -e 'globalThis.sessionStorage.setItem.length;globalThis.Storage.prototype.length'
[1] 42883 segmentation fault (core dumped) node -e
or
$ echo 'globalThis.sessionStorage.setItem.length;globalThis.Storage.prototype.length' >minimal_repro.js
$ node minimal_repro.js
[1] 44038 segmentation fault (core dumped) node minimal_repro.js
Additional information
I initially found this (and my previous bug report) using this script: https://github.com/ericcornelissen/pp-runtime-gadgets/blob/e2db81d895df5255628451ae0dac77fda2cd4e79/iterate/main.js (with the commented code in https://github.com/ericcornelissen/pp-runtime-gadgets/blob/e2db81d895df5255628451ae0dac77fda2cd4e79/iterate/keys.js uncommented). The report here is a minimal reproduction.
Running just globalThis.Storage.prototype.length doesn't cause a crash, reversing the access order also does not. It could be that another pair of accesses causes a segfault too, I haven't tested that.
In case it's helpful, here's the gdb output of running minimal_repro.js:
$ gdb --args node minimal_repro.js
GNU gdb (Ubuntu 15.1-1ubuntu1~24.04.1) 15.1
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from node...
(gdb) run
Starting program: /home/eric-cornelissen/.nvm/versions/node/v26.0.0/bin/node minimal_repro.js
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff77ff6c0 (LWP 45648)]
[New Thread 0x7ffff6ffe6c0 (LWP 45649)]
[New Thread 0x7ffff67fd6c0 (LWP 45650)]
[New Thread 0x7ffff5ffc6c0 (LWP 45651)]
[New Thread 0x7ffff57fb6c0 (LWP 45652)]
[New Thread 0x7ffff4ffa6c0 (LWP 45653)]
Thread 1 "node-MainThread" received signal SIGSEGV, Segmentation fault.
0x0000000002174730 in sqlite3LockAndPrepare ()
(gdb) bt
#0 0x0000000002174730 in sqlite3LockAndPrepare ()
#1 0x0000000002165d4c in sqlite3_prepare_v2 ()
#2 0x0000000000b435e8 in node::webstorage::Storage::Length() ()
#3 0x0000000000b44e04 in node::webstorage::StorageLengthGetter(v8::FunctionCallbackInfo<v8::Value> const&) ()
#4 0x00007fffe7dcfae9 in ?? ()
#5 0x0000000000000000 in ?? ()
Version
v26.0.0
Platform
Subsystem
No response
What steps will reproduce the bug?
or
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior? Why is that the expected behavior?
No segfault, for this particular program not output.
What do you see instead?
or
Additional information
I initially found this (and my previous bug report) using this script: https://github.com/ericcornelissen/pp-runtime-gadgets/blob/e2db81d895df5255628451ae0dac77fda2cd4e79/iterate/main.js (with the commented code in https://github.com/ericcornelissen/pp-runtime-gadgets/blob/e2db81d895df5255628451ae0dac77fda2cd4e79/iterate/keys.js uncommented). The report here is a minimal reproduction.
Running just
globalThis.Storage.prototype.lengthdoesn't cause a crash, reversing the access order also does not. It could be that another pair of accesses causes a segfault too, I haven't tested that.In case it's helpful, here's the gdb output of running
minimal_repro.js: