c:\ws\src\stream_base.cc:567: Assertion `(buf.base) == (buffer_.base)' failed.

[yongchuncao]

Version

v16.13.0

Platform

x64

Subsystem

No response

What steps will reproduce the bug?

No response

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

No response

What do you see instead?

C:\WINDOWS\system32\cmd.exe [29888]: c:\ws\src\stream_base.cc:567: Assertion `(buf.base) == (buffer_.base)' failed.
1: 00007FF6F293013F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+112495
2: 00007FF6F28BF396 DSA_meth_get_flags+65526
3: 00007FF6F28BF751 DSA_meth_get_flags+66481
4: 00007FF6F27DCEF5 v8::internal::wasm::WasmCode::code_comments_offset+23029
5: 00007FF6F27D7A79 v8::internal::wasm::WasmCode::code_comments_offset+1401
6: 00007FF6F2978876 uv_tty_set_vterm_state+8982
7: 00007FF6F298E87C uv_loop_init+924
8: 00007FF6F298EB8A uv_run+202
9: 00007FF6F295DC95 node::SpinEventLoop+309
10: 00007FF6F2877AC3 cppgc::internal::NormalPageSpace::linear_allocation_buffer+53827
11: 00007FF6F28F4FBD node::Start+221
12: 00007FF6F27188CC RC4_options+348108
13: 00007FF6F37708F8 v8::internal::compiler::RepresentationChanger::Uint32OverflowOperatorFor+14472
14: 00007FF9A72C7034 BaseThreadInitThunk+20
15: 00007FF9A9202651 RtlUserThreadStart+33

Additional information

This error was encountered when running the mocha test, and it only reported an error on some computers.

[iam-frankqiu]

Thank you for your reporting. could you please provide more info?

[yongchuncao]

@iam-frankqiu

The version of my windows system is 10.0.19042.1288.
I have project dependencies:

"dependencies": {
    "@cloudamqp/amqp-client": "^1.1.6",
    "@types/chai": "^4.2.21",
    "@types/mocha": "^9.0.0",
    "@types/pg": "^8.6.1",
    "ali-oss": "^6.16.0",
    "axios": "^0.21.1",
    "chai": "^4.3.4",
    "deep-equal-in-any-order": "^1.1.15",
    "express": "^4.17.1",
    "json-bigint": "^1.0.0",
    "md5": "^2.3.0",
    "mocha": "^8.3.2",
    "moment": "^2.29.1",
    "nodemailer": "^6.7.0",
    "pg": "^8.7.1",
    "postgres": "^1.0.2",
    "xlsx": "^0.17.3"
  }

The error is always thrown when running for 1 and a half minutes.
Sorry, I can only provide these, I hope I can help you.

[mayfield]

I can reproduce on a Windows 10 VM by toggling the link-state of the virtual network interface used by the QEMU/KVM VM. The logs will fill with typical network errors (handled) and then eventually this hard crash occurs.

I'm using the node bundled with Electron 22.0.0, v16.17.1. But survey of the CustomBufferJSListener::OnStreamRead history suggests it has been this way for some time.

Here is my usage of onread:

https://github.com/SauceLLC/sauce4zwift/blob/f2d529680080549faee362046016e58680725035/src/zwift.mjs#L925-L941

Other notes:

• Never seen on macOS or Linux
• Tested on Windows 10 VM (MSEDGEWIN10) (KVM/QEMU/virt-manager/e1000 NAT based virtual NIC)

Crash:

..\..\third_party\electron_node\src\stream_base.cc:590: Assertion `(buf.base) == (buffer_.base)' failed.
 1: 00007FF7EA50F706 node::Buffer::New+47862
 2: 00007FF7EA50F44C node::Buffer::New+47164
 3: 00007FF7EB1F5F0B node::CommonEnvironmentSetup::context+13035
 4: 00007FF7EABC522B uv_dlerror+638619
 5: 00007FF7EABC5A01 uv_dlerror+640625
 6: 00007FF7EAC24092 uv_tcp_getpeername+1474
 7: 00007FF7EA5237E3 uv_run+451
 8: 00007FF7E89594AC node::FreePlatform+21820
 9: 00007FF7EC2F4038 cppgc::internal::WriteBarrier::DijkstraMarkingBarrierRangeSlow+3391416
10: 00007FF7EC39AA1E cppgc::internal::WriteBarrier::DijkstraMarkingBarrierRangeSlow+4073886
11: 00007FF7EC300A2B cppgc::internal::WriteBarrier::DijkstraMarkingBarrierRangeSlow+3443115
12: 00007FF7E9F74755 node::GetEnvironmentIsolateData+9132213
13: 00007FF7EA53F1E5 uv_sleep+95285
14: 00007FF7E9F48C1E node::GetEnvironmentIsolateData+8953214
15: 00007FF7E97C2E02 node::GetEnvironmentIsolateData+1064802
16: 00007FF7E97C4B21 node::GetEnvironmentIsolateData+1072257
17: 00007FF7E97C0229 node::GetEnvironmentIsolateData+1053577
18: 00007FF7E8A6432F v8::metrics::LongTaskStats::LongTaskStats+519983
19: 00007FF7E8A659F0 v8::metrics::LongTaskStats::LongTaskStats+525808
20: 00007FF7E8A65398 v8::metrics::LongTaskStats::LongTaskStats+524184
21: 00007FF7E8A617B0 v8::metrics::LongTaskStats::LongTaskStats+508848
22: 00007FF7E8A618EF v8::metrics::LongTaskStats::LongTaskStats+509167
23: 00007FF7E87DD0D1 std::Cr::vector<v8::CpuProfileDeoptFrame,std::Cr::allocator<v8::CpuProfileDeoptFrame> >::vector<v8::CpuProfileDeoptFrame,std::Cr::allocator<v8::CpuProfileDeoptFrame> >+63809
24: 00007FF7EC6535C2 cppgc::internal::WriteBarrier::DijkstraMarkingBarrierRangeSlow+6927682
25: 00007FFDC8B87974 BaseThreadInitThunk+20
26: 00007FFDC9CCA2F1 RtlUserThreadStart+33

My user reports: SauceLLC/sauce4zwift#3

[mayfield]

This appears to be related to setKeepAlive(true, 15000) or at least I'm unable to reproduce without that.

Here is a reproduction recipe:

1. On remote host server run a TCP listener such as ncat a la.,

:; nc -v -l --no-shutdown 8001 
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Listening on :::8001
Ncat: Listening on 0.0.0.0:8001
Ncat: Connection from 192.168.122.55.
Ncat: Connection from 192.168.122.55:50436.

2. On the Windows machine run this code...

const net = require('node:net');

function onData(nread, buf) {
    console.info("onData", nread, buf && buf.slice(0, nread).toString());
}

async function test() {
    const conn = net.createConnection({
        host: 'server',
        port: 8001,
        timeout: 31000,
        onread: {
            buffer: Buffer.alloc(65536),
            callback: onData,
        }
    });

    conn.setKeepAlive(true, 15000);  // IF SET WILL CRASH NODE ON WIN10

    await new Promise((resolve, reject) => {
        conn.once('connect', resolve);
        conn.once('error', reject);
    });
    console.info("Connected");
    conn.on('close', ev => console.error("close", ev, conn));
    conn.on('timeout', ev => console.error("timeout", ev, conn));
    conn.on('error', ev => console.error("error", ev, conn));
}

test();

3. Create a network partition between the two. I.e. pull the cable, toggle link-state, etc.

4. Crash if setKeepAlive is used otherwise only a timeout event occurs (no crash)