profile
viewpoint
Ben Noordhuis bnoordhuis IBM The Netherlands

bnoordhuis/bspc 21

Quake 3 BSP-to-AAS compiler

bnoordhuis/amazing-graceful-fs 4

Like graceful-fs, but without eval() hacks and polyfills.

bnoordhuis/chicken-core 4

http://call-cc.org/

bnoordhuis/axis2-c 3

Apache Axis2/C is a Web services engine implemented in the C programming language.

bnoordhuis/chamfilter 3

block China and other South Asian countries at the firewall level

bnoordhuis/entityplus 3

just another quake 3 mod

bnoordhuis/c-ares 2

c-ares is a C library that performs DNS requests and name resolves asynchronously.

issue commentlibuv/libuv

Release proposal: v1.39.0

Okay, that seems harmless enough, although I can't really evaluate the windows changes.

cjihrig

comment created time in 2 hours

Pull request review commentlibuv/libuv

fs: clobber req->path on uv_fs_mkstemp() error

 TEST_IMPL(fs_mkstemp) {   int r;   int fd;   const char path_template[] = "test_file_XXXXXX";+  const char test_file[] = "test_file";

Okay, I guess I don't understand why this is hoisted into a variable then, if it's a semantically null change.

tjarlama

comment created time in 2 hours

issue commentlibuv/libuv

ci,macos: flaky process_title_threadsafe test

#2946

bnoordhuis

comment created time in 3 hours

PR opened libuv/libuv

Reviewers
test: fix thread race in process_title_threadsafe

Libuv calls uv__process_title_cleanup() on shutdown, which raced with one of the threads from the test that calls uv_get_process_title() in an infinite loop. Change the test to properly shut down the thread before exiting.

Refs: https://github.com/libuv/libuv/pull/2853#issuecomment-665259082 CI: https://ci.nodejs.org/job/libuv-test-commit/1978/

+13 -2

0 comment

1 changed file

pr created time in 3 hours

create barnchbnoordhuis/libuv

branch : fix-test-thread-race

created branch time in 3 hours

Pull request review commentlibuv/libuv

fs: clobber req->path on uv_fs_mkstemp() error

 TEST_IMPL(fs_mkstemp) {   int r;   int fd;   const char path_template[] = "test_file_XXXXXX";+  const char test_file[] = "test_file";
  char test_file[] = "test_file";

A const char array is immutable and may be in read-only memory.

tjarlama

comment created time in 3 hours

Pull request review commentlibuv/libuv

fs: clobber req->path on uv_fs_mkstemp() error

 TEST_IMPL(fs_mkstemp) {   ASSERT(strcmp(mkstemp_req1.path, mkstemp_req2.path) != 0);    /* invalid template returns EINVAL */-  ASSERT(uv_fs_mkstemp(NULL, &mkstemp_req3, "test_file", NULL) == UV_EINVAL);+  ASSERT(uv_fs_mkstemp(NULL, &mkstemp_req3, test_file, NULL) == UV_EINVAL);++  /* Make sure that path is empty string */+  ASSERT(strlen(mkstemp_req3.path) == 0);

Can you use the new-style macros?

  ASSERT_EQ(UV_EINVAL, uv_fs_mkstemp(NULL, &mkstemp_req3, test_file, NULL));

  /* Make sure that path is empty string */
  ASSERT_EQ(0, strlen(mkstemp_req3.path));
tjarlama

comment created time in 3 hours

Pull request review commentlibuv/libuv

fs: clobber req->path on uv_fs_mkstemp() error

 void fs__mktemp(uv_fs_t* req, uv__fs_mktemp_func func) {   unsigned int tries, i;   size_t len;   uint64_t v;+  char *path = req->path;
  char* path;

  path = req->path;
tjarlama

comment created time in 3 hours

Pull request review commentlibuv/libuv

win,fs: avoid implicit access to _doserrno

 #define SET_REQ_RESULT(req, result_value)                                   \   do {                                                                      \     req->result = (result_value);                                           \-    if (req->result == -1) {                                                \-      req->sys_errno_ = _doserrno;                                          \-      req->result = uv_translate_sys_error(req->sys_errno_);                \-    }                                                                       \+    assert(req->result != -1);                                              \

Hm, at least fs__mktemp() appears to be calling SET_REQ_RESULT(req, -1)...

vtjnash

comment created time in 3 hours

PR closed libuv/libuv

darwin: use IOKit for uv_cpu_info

This switches uv_cpu_info from using sysctlbyname to using IOKit to get the speed of the processors. macOS on ARM does not currently have the hw.cpufrequency sysctl. We are able to reliable get the clock frequency on all architectures by using IOKit.

Fixes: https://github.com/libuv/libuv/issues/2911

+157 -4

2 comments

2 changed files

evanlucas

pr closed time in 4 hours

pull request commentlibuv/libuv

darwin: use IOKit for uv_cpu_info

Landed in 87f07651, thanks Evan!

evanlucas

comment created time in 4 hours

push eventlibuv/libuv

Evan Lucas

commit sha 87f076515937345fda1a1dbc598f34e65e1b81c7

darwin: use IOKit for uv_cpu_info This switches uv_cpu_info from using sysctlbyname to using IOKit to get the speed of the processors. macOS on ARM does not currently have the hw.cpufrequency sysctl. We are able to reliable get the clock frequency on all architectures by using IOKit. Fixes: https://github.com/libuv/libuv/issues/2911 PR-URL: https://github.com/libuv/libuv/pull/2914 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>

view details

push time in 4 hours

issue closedlibuv/libuv

uv_cpu_info fails on Darwin ARM64

Darwin ARM64 appears to be missing the hw.cpufrequency sysctl, causing uv_cpu_info to fail. I'm thinking this might just be an oversight, so I've submitted a ticket with Apple (FB7917120), but I figured it would be worth filing an issue here as well to track the issue.

closed time in 4 hours

Keno

issue closedlibuv/libuv

seccomp may prevent call to disallowed x86 system call 345 on Android

Hello,

When I call uv_udp_send will get an error. but it working on macOS and iOS.

Android version: 10 Libuv version: 1.38.1

uv_udp_send(req->send_udp, req->socket, req->buf, 1, NULL, send_cb);
 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
 Build fingerprint: 'google/sdk_gphone_x86/generic_x86:10/dev-keys'
 Revision: '0'
 ABI: 'x86'
 Timestamp: 2020-08-04 21:49:02+0800
 pid: 3789, tid: 3907, name: Thread-19  >>> com.example <<<
 uid: 10174
 signal 31 (SIGSYS), code 1 (SYS_SECCOMP), fault addr --------
 Cause: seccomp prevented call to disallowed x86 system call 345
     eax 00000159  ebx 0000006c  ecx 00000000  edx 00000000
     edi f3c29c34  esi 00000000
     ebp 2c689d2d  esp c3adc7f8  eip f66f8b79
 backtrace:
       #00 pc 00000b79  [vdso] (__kernel_vsyscall+9)
       #01 pc 00092328  /apex/com.android.runtime/lib/bionic/libc.so (syscall+40) (BuildId: 471745f0fbbcedb3db1553d5bd6fcd8b)
       #02 pc 0001f3fe  hide-kaEPJawgZH70dU5LAQ0T4A==/lib/x86/libuv.so (BuildId: cda0c7b1ca29b912b7a85c2642d8c1408e2d5eb5)
       #03 pc 0001bc3a  hide-kaEPJawgZH70dU5LAQ0T4A==/lib/x86/libuv.so (BuildId: cda0c7b1ca29b912b7a85c2642d8c1408e2d5eb5)
       #04 pc 0011c4b0  /apex/com.android.runtime/lib/bionic/libc.so (pthread_once+96) (BuildId: 471745f0fbbcedb3db1553d5bd6fcd8b)
       #05 pc 00019683  hide-kaEPJawgZH70dU5LAQ0T4A==/lib/x86/libuv.so (uv_once+35) (BuildId: cda0c7b1ca29b912b7a85c2642d8c1408e2d5eb5)
       #06 pc 0001a87f  hide-kaEPJawgZH70dU5LAQ0T4A==/lib/x86/libuv.so (BuildId: cda0c7b1ca29b912b7a85c2642d8c1408e2d5eb5)
       #07 pc 0001a6f1  hide-kaEPJawgZH70dU5LAQ0T4A==/lib/x86/libuv.so (BuildId: cda0c7b1ca29b912b7a85c2642d8c1408e2d5eb5)
       #08 pc 0000baa1  hide-kaEPJawgZH70dU5LAQ0T4A==/lib/x86/libuv.so (uv_udp_send+145) (BuildId: cda0c7b1ca29b912b7a85c2642d8c1408e2d5eb5)

closed time in 4 hours

caobug

issue commentlibuv/libuv

seccomp may prevent call to disallowed x86 system call 345 on Android

Duplicate of #2923

caobug

comment created time in 4 hours

issue commentlibuv/libuv

Release proposal: v1.39.0

Is #2725 really ready for release? It's a new API and those should ideally receive at least two sign-offs from maintainers.

Although it received three, it looks like two of them are from March, for an old incarnation of the PR.

cjihrig

comment created time in 4 hours

issue closednodejs/node

Parse Error: Invalid header value char

I send a request to https://gateway.ancestry.com/tree/trees/listtrees and fails with Parse Error: Invalid header value char.

const https = require('https')

const options = {
  hostname: 'gateway.ancestry.com',
  port: 443,
  path: '/tree/trees/listtrees',
  method: 'GET',
  headers: {
    Authorization:
      'Bearer DR~us-east-1~b3b258e8bbddb92f94d85b89bd68bce1d4d5fe33e877d3610f713xx8e5dd3844',
    Accept: 'application/json',
    'Content-Type': 'application/json',
  },
}

const req = https.request(options, (response) => {
  console.log(`statusCode: ${response.statusCode}`)

  response.on('data', (data) => {
    process.stdout.write(data)
  })
})

req.on('error', (err) => {
  console.error(err)
})

req.end()

Response:

Error: Parse Error: Invalid header value char
    at TLSSocket.socketOnData (_http_client.js:469:22)
    at TLSSocket.emit (events.js:315:20)
    at addChunk (_stream_readable.js:295:12)
    at readableAddChunk (_stream_readable.js:271:9)
    at TLSSocket.Readable.push (_stream_readable.js:212:10)
    at TLSWrap.onStreamRead (internal/stream_base_commons.js:186:23) {
  bytesParsed: 451,
  code: 'HPE_INVALID_HEADER_TOKEN',
  reason: 'Invalid header value char',
  rawPacket: <Buffer 48 54 54 50 2f 31 2e 31 20 34 30 31 20 55 6e 61 75 74 68 6f 72 69 7a 65 64 0d 0a 44 61 74 65 3a 20 54 75 65 2c 20 30 34 20 41 75 67 20 32 30 32 30 20 ... 645 more bytes>

The response looks:

curl -I "https://gateway.ancestry.com/tree/trees/listtrees" \
     -H 'Accept: application/json' \
     -H 'Content-Type: application/json' \
     -H 'Authorization: Bearer DR~us-east-1~b3b258e8bbddb92f94d85b89bd68bce1d4d5fe33e877d3610f713xx8e5dd3844'
HTTP/2 404
date: Tue, 04 Aug 2020 11:23:53 GMT
set-cookie: nlbi_1598068=q9zjHGLO7guXmNdNti1J4QAAAABULlhQpT00kfdB5RrPUKok; path=/
set-cookie: incap_ses_1080_1598068=HquXCNzFrE4pzCxmbO78DkhFKV8AAAAAZchZ8vOL8Rqwq/RNPwaGPg==; path=/
x-cdn: Incapsula
x-iinfo: 0-29635-29636 NNNN CT(99 99 0) RT(1596540232159 0) q(0 0 2 -1) r(3 3) U5

The issue is the same as here https://github.com/request/request/issues/3187 and probably https://github.com/nodejs/node/issues/27711.

Node.js version: v12.18.3, v13.14.0, v14.7.0 OS: OS X 10.14.6

closed time in 4 hours

meap

issue commentnodejs/node

Parse Error: Invalid header value char

Try passing --http1.1 to curl, then you'll see what the problem is:

$ curl --http1.1 -I "https://gateway.ancestry.com/tree/trees/listtrees" -H 'Accept: application/json' -H 'Content-Type: application/json' -H 'Authorization: Bearer DR~us-east-1~b3b258e8bbddb92f94d85b89bd68bce1d4d5fe33e877d3610f713xx8e5dd3844'
HTTP/1.1 404 Not Found
Date: Tue, 04 Aug 2020 18:52:03 GMT
Connection: keep-alive
Set-Cookie: nlbi_1598068=VMfQeN0UWX4l0gbDti1J4QAAAAAjX7foIqYcF4GdSj/zHP4C; path=/
Set-Cookie: incap_ses_247_1598068=dMLqa7n/Zg7wKjBJQYVtA1OuKV8AAAAA7utIjvIETWiSDw3VHn2MMQ==; path=/
Set-Cookie: ___utmvmzVuKszaB=WuMpRdHYAXQ; path=/; Max-Age=900
Set-Cookie: ___utmvazVuKszaB=JXsNHEu; path=/; Max-Age=900
Set-Cookie: ___utmvbzVuKszaB=YZw
    XoMOMalm: AtL; path=/; Max-Age=900
X-CDN: Incapsula
X-Iinfo: 8-1824852-1824854 NNNN CT(103 198 0) RT(1596567122677 40) q(0 0 3 -1) r(4 4) U5

That XoMOMalm header is the problem, header names are not allowed to have leading (or trailing) whitespace. I guess it's supposed to be part of the preceding Set-Cookie header because it varies with each request.

I'm going to close this out because node's parser is right to reject it but as a workaround try require('http2').

meap

comment created time in 4 hours

issue commentnodejs/node

Pausing readline pauses SIGINTs

the ^C seems to be handled, but by node instead of bubbling through the readline event

I'd say that's the expected behavior, given that the readline instance is paused. I'd find it surprising if it did emit an event.

because its not in raw mode, stdin gets echoed back to the terminal while its paused

That can be fixed by just flipping the ISIG bit with a call to tcsetattr(). Libuv only knows how to switch from fully cooked to fully raw mode but node can be cleverer about that.

devsnek

comment created time in 4 hours

issue commentnodejs/help

Crypto.createDecipheriv() using aes-256-cbc on an encrypted XML document

aes-256-cbc is a block cipher and 85,228 is not a multiple of the block size (16) so node/openssl is right to complain. Calling decipher.setAutoPadding(false) before the first decipher.update() call should fix it.

Bytegardener

comment created time in 16 hours

issue commentnodejs/node

dns.resolveSoa returns EBADRESP if hostname has a CNAME record

Thanks for the bug report. At first glance this appears to be a bug in our response parsing logic.

<hr>

https://github.com/nodejs/node/blob/74df7496ff6d899e4b8ceed9505a641e79ad6366/src/cares_wrap.cc#L1078-L1080

@addaleax @XadillaX Maybe not the root cause but those bounds checks look like UB to me.

Pointers in C and C++ are allowed to point one element past the end of an array and no more. The check should look like this:

diff --git a/src/cares_wrap.cc b/src/cares_wrap.cc
index 73a0ac6b33..778e0821d7 100644
--- a/src/cares_wrap.cc
+++ b/src/cares_wrap.cc
@@ -1075,7 +1075,7 @@ int ParseSoaReply(Environment* env,
     return status == ARES_EBADNAME ? ARES_EBADRESP : status;
   }
 
-  if (ptr + temp_len + NS_QFIXEDSZ > buf + len) {
+  if (temp_len > LONG_MAX - NS_QFIXEDSZ || temp_len + NS_QFIXEDSZ > len) {
     return ARES_EBADRESP;
   }
   ptr += temp_len + NS_QFIXEDSZ;
jlchristi

comment created time in 16 hours

issue commentnodejs/node

Pausing readline pauses SIGINTs

Does making.pause() and .resume() call this._setRawMode(on) with on=false and on=true respectively work?

(TBD how to interact with the SIGCONT handler.)

devsnek

comment created time in 16 hours

issue commentlibuv/libuv

One of tests fails (not ok 275 - tcp_connect_timeout) on Ubuntu 20.04

That test connects to 8.8.8.8:9999, an address that's normally unreachable and times out after a while. However, if you have something in your network topology (firewall, router, etc.) that cuts the TCP handshake short, the test fails.

You can check with nc 8.8.8.8 9999 - it should time out but only after several minutes have passed.

vvidovic

comment created time in 2 days

issue commentnodejs/help

Please help me, I am a mechanical Engineer

You're probably going to have more luck reporting this over at https://npm.community/. npm is bundled with node.js but it's not maintained by us, it's a separate project.

dhruvashvi

comment created time in 2 days

issue closednodejs/node

Unexpected instanceof behaviour when different filename letter cases are used

<!-- Thank you for reporting an issue.

This issue tracker is for bugs and issues found within Node.js core. If you require more general support please file an issue on our help repo. https://github.com/nodejs/help

Please fill in as much of the template below as you're able.

Version: output of node -v Platform: output of uname -a (UNIX), or version and 32 or 64-bit (Windows) Subsystem: if known, please specify affected core module name -->

  • Version: 14.7.0
  • Platform: Darwin Kernel Version 19.4.0
  • Subsystem:

What steps will reproduce the bug?

I have created an example repo to demonstrate the issue https://github.com/APshenkin/instanceof-failure

instanceof check fail if you create class instance in one file, where it was imported in lowercase and check in other file, where it was imported with a capital letter.

<!-- Enter details about your bug, preferably a simple code snippet that can be run using node directly without installing third-party dependencies. -->

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

100% on Mac OS

What is the expected behavior?

instanceof should return true and don't depends on file names

<!-- If possible please provide textual output instead of screenshots. -->

What do you see instead?

instanceof return false <!-- If possible please provide textual output instead of screenshots. -->

Additional information

<!-- Tell us anything else you think we should know. -->

closed time in 3 days

APshenkin

issue commentnodejs/node

Unexpected instanceof behaviour when different filename letter cases are used

Thanks for the bug report but that's expected and documented behavior. Some file systems are case insensitive, HFS+ and APFS are examples.

From doc/api/modules.md:

[..] on case-insensitive file systems or operating systems, different resolved filenames can point to the same file, but the cache will still treat them as different modules and will reload the file multiple times. For example, require('./foo') and require('./FOO') return two different objects, irrespective of whether or not ./foo and ./FOO are the same file.

APshenkin

comment created time in 3 days

issue commentnodejs/help

Object.getOwnPropertyNames when called on context does not return properties with enumerable=false in vm.runInContext / vm.runInNewContext

It's an artifact of history more than anything else. :-)

The original vm module worked by copying the properties from the sandbox object in and out of the VM context on every call, in a manner that mirrors how for/in iterates over an object's enumerable properties from both the object itself and its prototype chain.

Changing that behavior after 10 years is unlikely to happen, the risk of breaking existing code is too great.

KyranRana

comment created time in 3 days

issue commentnodejs/help

Can't kill node process - Error: listen EADDRINUSE: address already in use /tmp/echo.sock

The error here means /tmp/echo.sock already exists. Just fs.unlinkSync() it and try again.

davecarela

comment created time in 3 days

issue commentnodejs/help

Long Build Times on WSL 2 Normal?

How many CPUs do you see in /proc/cpuinfo? If it's only one, then 15-20 minutes is about par for the course.

arminlinzbauer

comment created time in 3 days

issue commentnodejs/node

node v12.18.3 doesn't work with npm v6.9.2 and below

@AdirAmsalem The stack trace points to a polyfill in one of npm's modules, that's not something node can fix. You can see for yourself:

https://github.com/nodejs/node/blob/e3e0927bb93ed92bcdfe81e7ad9af3d78ccc74fb/deps/npm/node_modules/graceful-fs/polyfills.js#L281-L299

I have no reason to believe changes between Node.js v12.18.2 and v12.18.3 are responsible.

AdirAmsalem

comment created time in 4 days

issue closednodejs/node

Error "Cannot read property 'resolve' of undefined"

  • Version: 14.6.0
  • Platform: Windows 10 (64 bits)

What steps will reproduce the bug?

When I try to install anything with npm i amodule, there is the error.

What do you see instead?

This.

Additional information

My version of NPM is 6.14.6.

closed time in 4 days

lulu5239

issue commentnodejs/node

Error "Cannot read property 'resolve' of undefined"

As this is clearly an issue with npm, not node, you should report it over at https://npm.community/. Node.js bundles npm but doesn't maintain it, it's a separate project.

lulu5239

comment created time in 4 days

issue closednodejs/node

crash - node_http_parser.cc:713 - assertion failed

  • Version: v14.6.0

  • Platform: Darwin MacBook-Pro.local 19.5.0 Darwin Kernel Version 19.5.0: Thu Apr 30 18:25:59 PDT 2020; root:xnu-6153.121.1~7/RELEASE_X86_64 x86_64

What steps will reproduce the bug?

Unknown. It used to be a random crash in production (1..10 times a day) but somehow I managed to make it permanent :) Even if i stash all the changes, crash is still there.

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

Every time after system starts up.

What do you see instead?

/usr/local/bin/node[40344]: ../src/node_http_parser.cc:713:Local<v8::Value> node::(anonymous namespace)::Parser::Execute(const char *, size_t): Assertion `(execute_depth_) == (0)' failed.
 1: 0x1012b7fd5 node::Abort() (.cold.1) [/usr/local/bin/node]
 2: 0x1000a3fa9 node::Abort() [/usr/local/bin/node]
 3: 0x1000a3e11 node::Assert(node::AssertionInfo const&) [/usr/local/bin/node]
 4: 0x1000c1900 node::(anonymous namespace)::Parser::Execute(char const*, unsigned long) [/usr/local/bin/node]
 5: 0x1000c1126 node::(anonymous namespace)::Parser::OnStreamRead(long, uv_buf_t const&) [/usr/local/bin/node]
 6: 0x1001bb14c node::TLSWrap::ClearOut() [/usr/local/bin/node]
 7: 0x1001bce80 node::TLSWrap::DoWrite(node::WriteWrap*, uv_buf_t*, unsigned long, uv_stream_s*) [/usr/local/bin/node]
 8: 0x1000ca0ff node::StreamBase::Write(uv_buf_t*, unsigned long, uv_stream_s*, v8::Local<v8::Object>) [/usr/local/bin/node]
 9: 0x1001595ed int node::StreamBase::WriteString<(node::encoding)1>(v8::FunctionCallbackInfo<v8::Value> const&) [/usr/local/bin/node]
10: 0x100157d4d void node::StreamBase::JSMethod<&(int node::StreamBase::WriteString<(node::encoding)1>(v8::FunctionCallbackInfo<v8::Value> const&))>(v8::FunctionCallbackInfo<v8::Value> const&) [/usr/local/bin/node]
11: 0x100256d48 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/usr/local/bin/node]
12: 0x1002562dc v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/usr/local/bin/node]
13: 0x100255a02 v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/usr/local/bin/node]
14: 0x100a4fbd9 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/usr/local/bin/node]

Additional information

Tried with 12.x (current LTS) and 14.x - works exactly the same.

closed time in 4 days

cal6

issue commentnodejs/node

crash - node_http_parser.cc:713 - assertion failed

I'm going to close this out due to lack of follow-up. If your node binary is provided by e.g. homebrew, please try the official binaries from https://nodejs.org/ instead.

cal6

comment created time in 4 days

issue closednodejs/node

Crash: Scavenger::Process, V8_Fatal unreachable code

  • Version: 12.13.0, 12.18.0 and 14.5.0
  • Platform: Linux, macOS
  • Subsystem: V8 ?

What steps will reproduce the bug?

This crash has been occurring rarely for multiple people on multiple machines when running https://github.com/parcel-bundler/parcel (on internal project and very rarely when running the test suite).

I know this is a long shot and hard to diagnose from the stack trace. But maybe someone has suggestions on how to better debug this.

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

Happens at least once a day when continuously building a project with Parcel in a loop on a dedicated machine (Linux).

I don't know if this could be related, but the crash possibly occurs less frequently when running Parcel with child-process-based workers instead of worker-threads.

What is the expected behavior?

Doesn't crash

What do you see instead?

Node 12.18.0 on Linux

Screen Shot 2020-06-11 at 10 28 17 AM

Node 14.5.0 on macOS:

#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0x700008cd1a00
 1: 0x1000df830 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/usr/local/Cellar/node/14.5.0/bin/node]
 2: 0x100a49dc1 V8_Fatal(char const*, ...) [/usr/local/Cellar/node/14.5.0/bin/node]
 3: 0x1003013dd v8::internal::Scavenger::Process(v8::internal::OneshotBarrier*) [/usr/local/Cellar/node/14.5.0/bin/node]
 4: 0x100304079 v8::internal::ScavengingTask::ProcessItems() [/usr/local/Cellar/node/14.5.0/bin/node]
 5: 0x100303e79 v8::internal::ScavengingTask::RunInParallel(v8::internal::ItemParallelJob::Task::Runner) [/usr/local/Cellar/node/14.5.0/bin/node]
 6: 0x1002c40f2 v8::internal::ItemParallelJob::Task::RunInternal() [/usr/local/Cellar/node/14.5.0/bin/node]
 7: 0x1000dce2e node::(anonymous namespace)::PlatformWorkerThread(void*) [/usr/local/Cellar/node/14.5.0/bin/node]
 8: 0x7fff6d66f109 _pthread_start [/usr/lib/system/libsystem_pthread.dylib]
 9: 0x7fff6d66ab8b thread_start [/usr/lib/system/libsystem_pthread.dylib]

Additional information

closed time in 4 days

mischnic

issue commentnodejs/node

Crash: Scavenger::Process, V8_Fatal unreachable code

I'm going to close this out for now but let me know when you have more to report and I'll reopen.

mischnic

comment created time in 4 days

issue commentnodejs/node

v14.6.0 dll build error

I'm fairly sure other people build the DLL without problems (it might even be tested by our CI, I'm not sure) so it's probably an issue local to your system.

I don't have concrete suggestions on how to fix it. You'll probably have to go over the *.gyp and *.gypi files and judiciously add/update link sections. There are quite a few build files but node.gyp/node.gypi and the V8 *.gyp files are the most relevant ones.

Reveares

comment created time in 4 days

issue closednodejs/node

node v12.18.3 doesn't work with npm v6.9.2 and below

  • Version: 12.18.3
  • Platform: (Mac) Darwin 18.7.0 Darwin Kernel Version 18.7.0; root:xnu-4903.278.12~1/RELEASE_X86_64 x86_64

What steps will reproduce the bug?

Running the following throws an error:

nvm use 12.18.3
npm i -g npm@6.9.2
npm init -y
npm i

Running the same with node 12.18.2 and npm 6.9.2 works as expected (older node versions are ok). Running the same with node 12.18.3 and npm 6.10.0 works as expected (newer npm versions are ok).

What is the expected behavior?

npm install should work.

What do you see instead?

npm ERR! cb.apply is not a function

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/xxx/.npm/_logs/2020-07-23T06_52_11_776Z-debug.log

Error log content:

0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   '/Users/xxx/.fnm/node-versions/v12.18.3/installation/bin/node',
1 verbose cli   '/var/folders/1z/j6cyfm4s2s5g4q76cb751rbm7y4sls/T/fnm-shell-478737/bin/npm',
1 verbose cli   'i'
1 verbose cli ]
2 info using npm@6.9.2
3 info using node@v12.18.3
4 verbose npm-session b6874fdb389e0e22
5 silly install runPreinstallTopLevelLifecycles
6 silly preinstall node-test@1.0.0
7 info lifecycle node-test@1.0.0~preinstall: node-test@1.0.0
8 silly install loadCurrentTree
9 silly install readLocalPackageData
10 verbose stack TypeError: cb.apply is not a function
10 verbose stack     at /Users/xxx/.fnm/node-versions/v12.18.3/installation/lib/node_modules/npm/node_modules/graceful-fs/polyfills.js:285:20
10 verbose stack     at FSReqCallback.oncomplete (fs.js:169:5)
11 verbose cwd /Users/xxx/Personal/node-test
12 verbose Darwin 18.7.0
13 verbose argv "/Users/xxx/.fnm/node-versions/v12.18.3/installation/bin/node" "/var/folders/1z/j6cyfm4s2s5g4q76cb751rbm7y4sls/T/fnm-shell-478737/bin/npm" "i"
14 verbose node v12.18.3
15 verbose npm  v6.9.2
16 error cb.apply is not a function
17 verbose exit [ 1, true ]
  • As can be seen in the logs I'm using fnm instead of nvm but that's the same.

Additional information

Might be related to the version of graceful-fs.

The following issue mentions a similar problem with regards to graceful-fs - https://github.com/jprichardson/node-fs-extra/issues/703

npm v6.10.0 and above use graceful-fs v4.2.0, while npm v6.9.2 uses graceful-fs v4.1.15. v6.10.0 Changelog - commit e36b3c320

closed time in 4 days

AdirAmsalem

issue commentnodejs/node

node v12.18.3 doesn't work with npm v6.9.2 and below

I'm afraid this is not the right place to report issues with npm, that's https://npm.community/c/bugs. Node.js bundles npm but doesn't maintain it. I'll close this out.

AdirAmsalem

comment created time in 4 days

issue closednodejs/node

net doesn't seem to be able to handle zone IDs in IPv6 literals in some cases

<!-- Thank you for reporting an issue.

This issue tracker is for bugs and issues found within Node.js core. If you require more general support please file an issue on our help repo. https://github.com/nodejs/help

Please fill in as much of the template below as you're able.

Version: output of node -v Platform: output of uname -a (UNIX), or version and 32 or 64-bit (Windows) Subsystem: if known, please specify affected core module name -->

  • Version: v12.16.1
  • Platform: OpenBSD bastille 6.7 GENERIC.MP#303 amd64
  • Subsystem: net

What steps will reproduce the bug?

<!-- Enter details about your bug, preferably a simple code snippet that can be run using node directly without installing third-party dependencies. -->

As per RFC 6874, IPv6 literals may include a zone ID, which determines the scope ID of the IPv6 address. The problem appears if a zone ID is included with an IPv6 literal passed to net.Server#listen and net.createConnection, but ipv6Only is unset in net.Server#listen's options:

'use strict';

const net = require('net');

const options = {
    host:     '::1%lo0',
    port:     8000,
//  ipv6Only: true,
};

const server = net.createServer(connection => {
    console.log(`Connected to: [${connection.remoteAddress}]:${connection.remotePort}`);
    connection.end();
}).listen(options);

const client = net.createConnection(options);
client.on('end', () => {
    server.close();
});

Change lo0 to whatever the name of the loopback interface is if it's different on your system.

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

I would expect this to be reproducible every time, on any system.

What is the expected behavior?

This should output something along the lines of Connected to: [::1]:8000.

<!-- If possible please provide textual output instead of screenshots. -->

What do you see instead?

An exception gets thrown:

bastille% node test.js
events.js:288
      throw er; // Unhandled 'error' event
      ^

Error: listen EINVAL: invalid argument ::1%lo0:8000
    at Server.setupListenHandle [as _listen2] (net.js:1292:21)
    at listenInCluster (net.js:1357:12)
    at doListen (net.js:1496:7)
    at processTicksAndRejections (internal/process/task_queues.js:85:21)
Emitted 'error' event on Server instance at:
    at emitErrorNT (net.js:1336:8)
    at processTicksAndRejections (internal/process/task_queues.js:84:21) {
  code: 'EINVAL',
  errno: 'EINVAL',
  syscall: 'listen',
  address: '::1%lo0',
  port: 8000
}

Additional information

If lookup is set to dns.resolve in the options passed to net.Server#listen or net.createConnection, an internal error of some sort appears instead:

dns.js:262
    throw new ERR_INVALID_ARG_TYPE('rrtype', 'string', rrtype);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "rrtype" argument must be of type string. Received an instance of Object
    at Resolver.resolve (dns.js:262:11)
    at net.js:1039:5
    at defaultTriggerAsyncIdScope (internal/async_hooks.js:311:12)
    at lookupAndConnect (net.js:1038:3)
    at Socket.connect (net.js:972:5)
    at Object.connect (net.js:182:17)
    at Object.<anonymous> (/home/morfent/test.js:18:20)
    at Module._compile (internal/modules/cjs/loader.js:1158:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1178:10)
    at Module.load (internal/modules/cjs/loader.js:1002:32) {
  code: 'ERR_INVALID_ARG_TYPE'
}

closed time in 4 days

Kaiepi

issue commentnodejs/node

net doesn't seem to be able to handle zone IDs in IPv6 literals in some cases

I'm going to close this out but you're of course welcome to send a pull request to make things better on openbsd. Thanks for taking the time to put together your bug report.

Kaiepi

comment created time in 4 days

issue closednodejs/node

Porting over the Web Audio API

As of now, it is very difficult to play audio in Node.js. Most solutions suggested on the Stackoverflow question require using native modules and have all broken in one way or another. Community implementations of the Web Audio API have made good progress but are incomplete and buggy. My experience using web-audio-api has not been good.

Node.js should port over the Web Audio API present in browsers so that the same functionality can be achieved on the client-end, or at the very least provide middleware for piping audio streams to hardware, like speaker.

closed time in 4 days

Richienb

issue commentnodejs/node

Porting over the Web Audio API

It's been a couple of days and no one else chimed in so I'm taking the liberty of closing this out. Thanks anyway for taking the time to file your feature request.

Richienb

comment created time in 4 days

issue commentlibuv/libuv

100% CPU + Socket idling in CLOSE_WAIT state

To be clear: UV_DISCONNECT is reported opportunistically, as an optimization; that's why I wrote "e.g.", as in: for example.

When the socket is closed by the peer, you'll get some event (unless you've cleared the event mask, of course.)

If it's UV_READABLE and you try to read, you'll receive an ECONNRESET error.

It's also possible your callback is invoked with status < 0, to indicate an error, such as UV_EBADF.

If you handle all that correctly and properly close the uv_poll_t but you still see sockets ending up in CLOSE_WAIT state, then I'm happy to take a look, but I'll need an easy way to reproduce.

CurlyMoo

comment created time in 6 days

Pull request review commentdenoland/rusty_v8

Allow managing V8 heap limits

 use std::sync::Mutex;  use rusty_v8 as v8; // TODO(piscisaureus): Ideally there would be no need to import this trait.+use std::ffi::c_void;
use std::ffi::c_void;
// TODO(piscisaureus): Ideally there would be no need to import this trait.

Otherwise the comment no longer makes sense.

mraerino

comment created time in 6 days

Pull request review commentdenoland/rusty_v8

Allow managing V8 heap limits

 fn module_snapshot() {     }   } }++struct TestHeapLimitState {+  near_limit_callback_called: bool,

Consider making this an integral type so you can count the calls.

mraerino

comment created time in 6 days

issue commentnodejs/help

Can Node.js's clustering feature leverage multiple CPUs? (referring to multi socket systems, not cores)

Would this return 32?

Yes, it should. If /proc/cpuinfo prints 32 cpus, then so will os.cpus().

enviziion

comment created time in 6 days

issue commentnodejs/help

fs.renameSync() incorrect working

I've moved this to nodejs/help because this is unlikely to be an issue with Node.js itself. Next time, please fill out the issue template.

odfrontendeveloper

comment created time in 6 days

issue commentlibuv/libuv

100% CPU + Socket idling in CLOSE_WAIT state

CLOSE_WAIT is not an unexpected TCP state. 9 out of 10 times it means you need to close the socket.

Since you're using uv_poll_t, that means its callback should have been invoked with e.g. UV_DISCONNECT as one of the events.

I'm fairly sure of that because of this:

pevents = 5, events = 0, fd = 20

pevents are the pending events (EPOLLIN + EPOLLOUT), events that libuv has seen and recorded.

The events = 0 means the handle is stopped, either due to someone calling uv_poll_stop() / uv_poll_start() with an empty event mask, or because libuv saw an error event for the handle.

I can see how a busy loop could develop if you don't close the handle and the kernel keeps reporting error events for the socket.

Libuv could unregister the socket from the epoll set to work around that. Untested, but this patch might help:

diff --git a/src/unix/linux-core.c b/src/unix/linux-core.c
index 92a66ebf..9c353c3c 100644
--- a/src/unix/linux-core.c
+++ b/src/unix/linux-core.c
@@ -417,9 +417,11 @@ void uv__io_poll(uv_loop_t* loop, int timeout) {
        * needs to remember the error/hangup event.  We should get that for
        * free when we switch over to edge-triggered I/O.
        */
-      if (pe->events == POLLERR || pe->events == POLLHUP)
+      if (pe->events == POLLERR || pe->events == POLLHUP) {
         pe->events |=
           w->pevents & (POLLIN | POLLOUT | UV__POLLRDHUP | UV__POLLPRI);
+        epoll_ctl(loop->backend_fd, EPOLL_CTL_DEL, fd, pe);
+      }
 
       if (pe->events != 0) {
         /* Run signal watchers last.  This also affects child process watchers
CurlyMoo

comment created time in 6 days

issue closednodejs/node

Script in NODE_OPTIONS --require not executed in Node before reinstall

<!-- Thank you for reporting an issue.

This issue tracker is for bugs and issues found within Node.js core. If you require more general support please file an issue on our help repo. https://github.com/nodejs/help

Please fill in as much of the template below as you're able.

Version: output of node -v Platform: output of uname -a (UNIX), or version and 32 or 64-bit (Windows) Subsystem: if known, please specify affected core module name -->

  • Version: 14.3.0
  • Platform: Linux
  • Subsystem:

What steps will reproduce the bug?

Unknown, see: https://github.com/microsoft/vscode-js-debug/issues/660

It seems that for this user, a script in the --require was consistently not being executed on Node 14.3.0. However, he notes that reinstalling Node via nvm solved the issue.

I'm not sure what kind of repro we can get, but wanted to raise awareness on this.

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

Unknown

What is the expected behavior?

Node always executes the --require'd script, or fails.

What do you see instead?

For this user, it did not.

Additional information

<!-- Tell us anything else you think we should know. -->

closed time in 7 days

connor4312

issue commentnodejs/node

Script in NODE_OPTIONS --require not executed in Node before reinstall

Okay, thanks for the update. I'll go ahead and close this out then but let me know if you have more to share.

connor4312

comment created time in 7 days

issue commentnodejs/node

v14.6.0 dll build error

That function lives in winmm.lib and that library is linked in, as far as I'm aware. Long shot but does this patch help?

diff --git a/tools/v8_gypfiles/v8.gyp b/tools/v8_gypfiles/v8.gyp
index f8259069c9..7a51ec9b54 100644
--- a/tools/v8_gypfiles/v8.gyp
+++ b/tools/v8_gypfiles/v8.gyp
@@ -1093,6 +1093,15 @@
             'defines': ['_WIN32_WINNT=0x0602'], # For GetCurrentThreadStackLimits on Windows on Arm
           }]],
           'defines': ['_CRT_RAND_S'], # for rand_s()
+          'msvs_settings': {
+            'VCLinkerTool': {
+              'AdditionalDependencies': [
+                'dbghelp.lib',
+                'winmm.lib',
+                'ws2_32.lib'
+              ]
+            }
+          },
           'direct_dependent_settings': {
             'msvs_settings': {
               'VCLinkerTool': {
Reveares

comment created time in 7 days

issue commentnodejs/node

Porting over the Web Audio API

I'm not going to close this outright but I'd say this is unlikely to happen for the same reason node doesn't support e.g. webgl.

Richienb

comment created time in 7 days

issue commentnodejs/node

Internal error in node-inspect

It probably means the node-inspect process received a truncated response from the process that was being debugged.

That can happen when your app.js calls e.g. process.exit(), because that immediately terminates the process.

env NODE_DEBUG=inspect node inspect ... logs the protocol messages, that might be of help.

@jkrems @mmarchini The error message could probably be improved.

jabberwock31415

comment created time in 7 days

issue commentnodejs/node

Crash: Scavenger::Process, V8_Fatal unreachable code

Can you perhaps try a debug build? Build from source with ./configure --debug && make -j8, the binary is called node_g.

Debug builds have more runtime checks enabled. If nothing else, it should produce a more meaningful stack trace.

I had a look at Scavenger::Process() but it's not wholly clear to me what part is hitting unreachable code, probably code that was inlined from elsewhere.

mischnic

comment created time in 7 days

issue commentnodejs/node

Script in NODE_OPTIONS --require not executed in Node before reinstall

Thanks for the bug report but I don't see how we can help troubleshoot this. I'm not even sure where to start, there are too many places where something could have gone wrong.

If you or that user can come up with a simplified reproduction, I'm happy to take a look, but otherwise I suggest we close this.

connor4312

comment created time in 7 days

issue commentnodejs/help

date convert error

I've moved this to nodejs/help because I'm fairly sure this is a problem with your local setup, not a node bug.

With v14.6.0:

$ node
> new Date().toLocaleString("zh-CN")
'2020/7/28 下午2:03:12'
> new Date().toISOString()
'2020-07-28T12:03:28.113Z'

Note that v14.x has full-icu built in, v12.x doesn't. My guess is that node can't find the full-icu package on your system.

JoeyBling

comment created time in 7 days

issue commentnodejs/help

In vm module, 'value instanceof Array' returns false when array is defined inside the execution string

I've moved this to nodejs/help. To answer your question: it's expected behavior, the vm context has its own set of built-ins (Array, Object, Date, etc.), separate from the built-ins of the outer context:

$ node
> vm.runInNewContext('Array') === Array
false
saurabhdaware

comment created time in 7 days

issue commentlibuv/libuv

100% CPU + Socket idling in CLOSE_WAIT state

Yes, that's right.

CurlyMoo

comment created time in 8 days

pull request commentlibuv/libuv

linux: fix i386 sendmmsg/recvmmsg support

@kyze8439690 We want as little special casing as possible. I'll comment on #2167 w.r.t. the other system calls.

bnoordhuis

comment created time in 8 days

issue commentnodejs/node

Support Windows’ timezones in Intl.DateTimeFormat

Can then CanonicalizeTimeZoneName be updated to understand Windows timezones?

You need to take that up with the working group that's behind ECMA 402.

dilyanpalauzov

comment created time in 8 days

issue closednodejs/node

Support Windows’ timezones in Intl.DateTimeFormat

ICU does understand the “FLE Standard Time” timezone-ID, that exists on Windows, but not in the IANA/Olson database. NodeJS uses ICU.

Intl.DateTimeFormat('de', {timeZone: 'FLE Standard Time', timeStyle: 'full', dateStyle: 'full'}).format(new Date)

reports currently, that it does not understand FLE.

• Extend the support for Intl.DateTimeFormat to understand Windows timezones.

I use ICU 67 and Node 14.5.0

closed time in 8 days

dilyanpalauzov

issue commentnodejs/node

Support Windows’ timezones in Intl.DateTimeFormat

While you're right about this part:

ICU does understand the “FLE Standard Time” timezone-ID

I believe this section from the spec applies: https://www.ecma-international.org/ecma-402/4.0/#sec-isvalidtimezonename

ICU knows how to map Windows timezone names to their IANA counterparts but only when you specifically ask it to (it's a different API) and V8 doesn't, it follows the spec.

I'm going to close this out but let me know if you believe there is reason to reopen.

dilyanpalauzov

comment created time in 8 days

issue commentnodejs/node

net doesn't seem to be able to handle zone IDs in IPv6 literals in some cases

Your example works for me with v12.16.1 on linux and macos so I assume this is a problem specific to either openbsd or your system. The clue is probably in the ipv6Only option: linux and macos support dual-mode sockets, openbsd doesn't.

Kaiepi

comment created time in 8 days

issue commentlibuv/libuv

fs: clobber req->path on uv_fs_mkstemp() error

@tjarlama

  1. Correct.
  2. Either is fine.
  3. Correct.
bnoordhuis

comment created time in 8 days

issue commentlibuv/libuv

100% CPU + Socket idling in CLOSE_WAIT state

epoll_wait(5, [{EPOLLIN, {u32=21, u64=21}}], 1024, 71) = 1

Can you try to attach gdb and print loop->watchers[21] (or whatever fd it's busy-looping on)? You can get the loop from the frame that corresponds to uv__io_poll(), it's that function's first argument.

CurlyMoo

comment created time in 8 days

issue commentlibuv/libuv

syscall crash on Android 9.0 x86

I've opened #2925 to fix sendmmsg/recvmmsg support.

I'm ambivalent about the other system calls, they should Just Work as far as I know, maybe with the exception of statx. Can you share more details?

kyze8439690

comment created time in 8 days

PR opened libuv/libuv

linux: fix i386 sendmmsg/recvmmsg support

Android/i386 doesn't have separate sendmmsg/recvmmsg system calls, they're multiplexed through the socketcall system call.

(More precisely, the system calls may be present but the standard seccomp filter rejects them, whereas socketcall is whitelisted.)

This commit removes the flags and timeout arguments from libuv's internal system call wrappers because they're always zero and it makes EINVAL/ENOSYS detection after a failed socketcall() easier.

Fixes: https://github.com/libuv/libuv/issues/2923 CI: https://ci.nodejs.org/job/libuv-test-commit/1955/

+49 -41

0 comment

4 changed files

pr created time in 8 days

create barnchbnoordhuis/libuv

branch : fix2923

created branch time in 8 days

issue commentlibuv/libuv

How to control rx flow?

When I frequent calls uv_read_stop and uv_read_start

Yes, those are the ones you should use.

will cause can't receive more data on recv callback.

I'm afraid I don't understand what you mean.

caobug

comment created time in 9 days

Pull request review commentnodejs/node

Fixed invalid path in CONNECT method requests.

 function resetCache() {   utcCache = undefined; } +function validatePath(path) {+  const pathRegex = /^[_0-9A-Za-z]+(\.[_0-9A-Za-z]+)*\.?:([1-9]|[1-9][0-9]{1,2}|[1-5][0-9]{3}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])$/;

It might be worth checking if it matters performance-wise when you move the regex outside the function.

The regex should use (?:...) non-capturing groups, otherwise it pollutes RegExp.$1, etc.

PreYunk

comment created time in 9 days

Pull request review commentnodejs/node

Fixed invalid path in CONNECT method requests.

 function resetCache() {   utcCache = undefined; } +function validatePath(path) {+  const pathRegex = /^[_0-9A-Za-z]+(\.[_0-9A-Za-z]+)*\.?:([1-9]|[1-9][0-9]{1,2}|[1-5][0-9]{3}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])$/;+  if (!pathRegex.test(path)) {+    throw new ERR_INVALID_ARG_VALUE('options.path',+                                    path, 'must be a valid host:port combo');+  }+  return path;

I'd change this to simply return true/false and have the caller throw the exception (and rename to e.g. isValidCONNECTPath().)

Rule of thumb: exceptions should be thrown close to the edge, where "edge" means the cross-over point between user code and core code.

PreYunk

comment created time in 9 days

Pull request review commentnodejs/node

Fixed invalid path in CONNECT method requests.

 function ClientRequest(input, options, cb) {   }   this.insecureHTTPParser = insecureHTTPParser; -  this.path = options.path || '/';+  this.path = (options.path && method === 'CONNECT' &&+    options.path.charAt(0) === '/' ?+    options.path.slice(1) : options.path) || '/';

Agreed, and as a micro-optimization: assign to a let path first and then do this.path = path; outside the if block.

(Ask me why if you want details but it has to do with how V8 stores object properties.)

PreYunk

comment created time in 9 days

pull request commentnodejs/node

lib: add noThrow option to fs.f/l/statSync

Let's start with the bits I agree with. :-)

Yes, fs.statSync() is expensive when most calls throw. It's why I changed require() to use something else a long time ago.

However, rather than adding a noThrow option, why not use fs.accessSync() instead? It should be faster on Windows - and probably other platforms too - because it does less work (fewer system calls, less data conversion.)

amcasey

comment created time in 9 days

issue commentlibuv/libuv

test: fix double evaluation in ASSERT macros

@tjarlama I'd go for option 2. There are only a handful of direct ASSERT_BASE uses.

bnoordhuis

comment created time in 9 days

issue closednodejs/node

fs.access returns incorrect information

  • Version: 14.5.0
  • Platform: Win 10, 64-bit
  • Subsystem: fs

What steps will reproduce the bug?

<!-- Enter details about your bug, preferably a simple code snippet that can be run using node directly without installing third-party dependencies. -->

Method 1

> fs.promises.access('C:/', fs.constants.W_OK).then(() => { fs.promises.writeFile('C:/test.txt', '') })
Promise { <pending> }
> (node:9312) UnhandledPromiseRejectionWarning: Error: EPERM: operation not permitted, open 'C:\test.txt'
(Use `node --trace-warnings ...` to show where the warning was created)
(node:9312) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)

Method 2

I execute a bin file via childProcess.exec, which successfully writes a file to some deep unknown place on the drive. I was trying to prevent this by checking if the directory is actually writable before executing it, but it turns out access can return incorrect information.

> fs.promises.access('C:/', fs.constants.W_OK).then(() => { childProcess.exec(...) })
Promise { <pending> }
> // executed bin writes an invisible file even though 'access' should have prevent this

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

Every time when you check system drive root or other system directories.

What is the expected behavior?

When you check write access for a directory with access() it should resolve the promise only if it can actually write to the directory.

As you can see from the example above, it says it can write a file to the system directory C:/ but when you actually try to write the file, it says it's not possible.

<!-- If possible please provide textual output instead of screenshots. -->

closed time in 14 days

aleksey-hoffman

issue commentnodejs/node

fs.access returns incorrect information

I'm going to close this as a wontfix. You're still welcome to open a documentation pull request, of course.

aleksey-hoffman

comment created time in 14 days

issue commentnodejs/node

Should we add a new api, "tls.Server.prototype.removeContexts(servername)" and "tls.Server.prototype.replaceContext(servername,context)" ?

@masx200 I think you misunderstand my previous comment.

server._contexts is an array of SecureContext objects. The array exists in JS land in order to look up the right context based on the servername property. Removing elements from that array is not the issue.

The issue is that removing a SecureContext from the array doesn't mean it's no longer in use. There are a bunch of C++ resources tied to SecureContext objects, all with complex lifecycles.

Establishing when it's safe to release those resources is hard but you have to fix that first before you can fix this:

Eventually lead to memory leaks or even memory overflow.

masx200

comment created time in 14 days

issue closednodejs/node

Fügen Sie 'new stream.Duplex (options)' docs 'writable' und 'readable' hinzu

<!-- Thank you for suggesting an idea to make Node.js better.

Please fill in as much of the template below as you're able. -->

Dies sollte hinzugefügt werden, da es noch nicht existiert

closed time in 14 days

Maximillus

issue commentnodejs/node

Fügen Sie 'new stream.Duplex (options)' docs 'writable' und 'readable' hinzu

The Duplex documentation says this:

Duplex streams are streams that implement both the [Readable][] and [Writable][] interfaces.

And that's where the .readable and .writable properties are inherited from. I don't think they need to be documented again for Duplex but if you feel differently, please open a documentation pull request.

Maximillus

comment created time in 14 days

issue commentnodejs/node

Should we add a new api, tls.Server.prototype.removeContexts(servername)?

The problem is that it's really difficult to know when it's safe to remove a context.

Removing it when it's still in use results in segfaults and even when it's gone from node's internal bookkeeping, all kinds of reference counting inside openssl can still keep it alive.

masx200

comment created time in 15 days

issue commentnodejs/node

Add a native support of Argon2 hashing algorithm

https://github.com/openssl/openssl/issues/4091 - until openssl adds support for it, there's nothing actionable for Node.js.

I'm going to close this for now but it can be reopened once upstream support materializes.

pubmikeb

comment created time in 15 days

issue closednodejs/node

Add a native support of Argon2 hashing algorithm

Is your feature request related to a problem? Please describe. Currently Node.js provides a native support of scrypt, which is good but isn't the most secure option.

Describe the solution you'd like It would be great to have a native support of argon2 via crypto module, just like scrypt has nowadays.

Describe alternatives you've considered An argon2 npm module for Node.js.

closed time in 15 days

pubmikeb

issue commentlibuv/help

UV_HANDLE_READABLE and UV_EOF

If you think it's a good idea, you're welcome to open a pull request. The thing is, the observable behavior can't change - it's not allowed to break existing programs.

kyze8439690

comment created time in 15 days

issue commentlibuv/help

UV_HANDLE_READABLE and UV_EOF

uv_read_start() never clears UV_HANDLE_READABLE. Were you thinking of uv__stream_close()?

uv_read_start() sets UV_HANDLE_READING (different flag), to mark that the user wants data.

UV_HANDLE_READABLE is a note that libuv makes to remember whether the handle was opened in read mode. It never changes during the lifetime of the handle, only when it's closed.

kyze8439690

comment created time in 15 days

issue commentbnoordhuis/node-heapdump

which node process will this dump when there are more than 1 node web processes?

Are you asking for the PID to be included in the filename? If you use the heapdump.writeSnapshot() function, you can do it like this:

heapdump.writeSnapshot(`${process.pid}-${Date.now()}.heapsnapshot`)

I'd be open to change the default filename to include the PID as well but I worry a little it might break downstream users. There are (somewhat to my amazement) over 1500 packages that depend on node-heapdump so I can't check them by hand.

jiajianrong

comment created time in 15 days

issue commentlibuv/help

uv_timer_init and uv_timer_stop

uv_close() will remove the timer again.

However, you're reinitializing it again immediately after calling uv_close(). Don't do that, you need to call uv_run() first and wait for the close callback.

qiupin

comment created time in 15 days

issue commentlibuv/help

Reasonable design of api about 'uv_connection_cb'

You can obtain it through handle->loop.

huoyingyangjie

comment created time in 15 days

pull request commentnodejs/node

Add direct access to rss without iterating pages

@Aschen Sure, there's precedent, e.g., fs.realpath.native().

Aschen

comment created time in 15 days

issue closednodejs/node

Build-failed: make -j4

Trying to building node from the source but always failed when running the make-j4 command.

Triggers the below error make -C out BUILDTYPE=Release V=0 /home/adarsh/node/out/Release/.deps//home/adarsh/node/out/Release/cctest.d:1: warning: NUL character seen; rest of line ignored /home/adarsh/node/out/Release/.deps//home/adarsh/node/out/Release/cctest.d:1: *** missing separator. Stop. Makefile:104: recipe for target 'node' failed make: *** [node] Error 2

closed time in 15 days

adarshsaraogi

issue commentnodejs/node

Build-failed: make -j4

No follow-up, closing.

adarshsaraogi

comment created time in 15 days

issue closednodejs/node

socket.emit back for sending data to same client who sent it is not working

In my program I am trying to make the client send data over to the server and after this the data that was sent to the server is sent back to the client who sent the request originally. The only problem I am having is that once the data is sent over to the server it does not seem to want to be sent back to the client who sent it.

client side:

var name = document.getElementById("name_input").value;
socket = io.connect("http://localhost:8080"); 
socket.emit("new-user", name); 

socket.on("welcome", function(data) 
{ 
console.log("recived welcome"); 
});

Server side

var name_list = ["bob", "sam", "jim"]
io.on("connection", function(socket) 
{
    socket.on("new-user", function(data)
    { 
    socket.emit('welcome', name_list); 
    });
});

When I look at the console on the client side in my web browser, the message "received welcome" does not come up. With the socket.emit() on the server side, this makes me think that the data that the client sent over to the server will be sent directly back over to the client that sent it. I have tried everything I can possibly think of. I have tried asking the people on stackoverflow and they don't know the answer. This is my last resource and I am desperate to figure out why the data is still not getting sent through. I have tried using the debugging tools on the server side:

const http = require("http");

const server = http.Server(app);
const io = require("socket.io")(server);

io.on('popup', function(msg){
    console.log("hello: ", msg);
});

io.on('connect_error', function(err) {
    console.log("client connect_error: ", err);
});

io.on('connect_timeout', function(err) {
    console.log("client connect_timeout: ", err);
});

I have used a different port on the server, I have removed the io.connect parameter from the io.connect function. With parameter it is socket = io.connect("http://localhost:2000"); Without parameter it is socket = io.connect();

closed time in 15 days

Digital-Rookie4

issue commentnodejs/node

socket.emit back for sending data to same client who sent it is not working

Closing, duplicate of https://github.com/nodejs/help/issues/2860 (which you might've noticed I deliberately moved there.)

Digital-Rookie4

comment created time in 15 days

PR opened libuv/libuv

unix: support long unix paths on macos + bsds

Fixes: https://github.com/libuv/libuv/issues/2826 CI: https://ci.nodejs.org/job/libuv-test-commit/1953/

+106 -28

0 comment

3 changed files

pr created time in 15 days

create barnchbnoordhuis/libuv

branch : fix2826

created branch time in 15 days

Pull request review commentnodejs/node

src: prefer C++ empty() in boolean expressions

 void URL::Parse(const char* input,               (ch == kEOL ||                ch == '?' ||                ch == '#')) {-            while (url->path.size() > 1 && url->path[0].length() == 0) {+            while (url->path.size() > 1 && url->path[0].empty()) {               url->path.erase(url->path.begin());             }

Sorry, yeah. It was intended as a kind of self-documentation about the preconditions but I guess it's confusing more than anything else. if (to == end && from != end) ++from; is probably a clearer way of writing it.

tniessen

comment created time in 15 days

issue openedlibuv/libuv

test: fix double evaluation in ASSERT macros

https://github.com/libuv/libuv/blob/e0cb4f06c9c171028092f3cb515e4523eb824066/test/task.h#L179-L182

https://github.com/libuv/libuv/blob/e0cb4f06c9c171028092f3cb515e4523eb824066/test/task.h#L114-L130

a and b are evaluated twice in case of failure which can make for confusing errors:

int evil(void) {
  static int x;
  return x++;
}

void test(void) {
  ASSERT_EQ(1, evil());  // fails but prints "(1 == 1)"
}

cc @santigimeno

created time in 15 days

pull request commentlibuv/libuv

Fix compile error C2001 on chinese windows.

@libuv/windows Ping.

sanjusss

comment created time in 16 days

Pull request review commentlibuv/libuv

Enable full ICMP error reporting on Linux

 static int uv__set_reuse(int fd) {   return 0; } +/*+ * The Linux kernel suppresses some ICMP error messages by default for UDP+ * sockets. Setting IP_RECVERR/IPV6_RECVERR on the socket enables full ICMP+ * error reporting, hopefully resulting in faster failover to working name+ * servers.+ */+static int uv__set_recverr(int fd, sa_family_t ss_family) {+#if defined(__linux__)+  int yes;++  yes = 1;+  if (ss_family == AF_INET) {+    if (setsockopt(fd, IPPROTO_IP, IP_RECVERR, &yes, sizeof(yes)))+      return UV__ERR(errno);+  } else if (ss_family == AF_INET6) {+    if (setsockopt(fd, IPPROTO_IPV6, IPV6_RECVERR, &yes, sizeof(yes)))+       return UV__ERR(errno);+  }+#endif+  return 0;

Good point and good middle ground. What do you think, @oerdnj?

oerdnj

comment created time in 16 days

Pull request review commentlibuv/libuv

Enable full ICMP error reporting on Linux

 TEST_IMPL(udp_send_unreachable) {                   send_cb);   ASSERT(r == 0); +  r = uv_udp_init(uv_default_loop(), &client2);+  ASSERT(r == 0);++  r = uv_udp_bind(&client2, (const struct sockaddr*) &addr3, UV_UDP_RECVERR);+  ASSERT(r == 0);++  if (can_recverr) {+    r = uv_udp_recv_start(&client2, alloc_cb, recv_cb);+    ASSERT(r == 0);++    /* client sends "PING", then "PANG" */+    buf = uv_buf_init("PING", 4);++    r = uv_udp_send(&req3,+		    &client2,+		    &buf,+		    1,+		    (const struct sockaddr*) &addr,+		    send_cb_recverr);+    ASSERT(r == 0);++    buf = uv_buf_init("PANG", 4);++    r = uv_udp_send(&req4,+		    &client2,+		    &buf,+		    1,+		    (const struct sockaddr*) &addr,+		    send_cb_recverr);+    ASSERT(r == 0);+  }+   uv_run(uv_default_loop(), UV_RUN_DEFAULT); -  ASSERT(send_cb_called == 2);-  ASSERT(recv_cb_called == alloc_cb_called);-  ASSERT(timer_cb_called == 1);-  ASSERT(close_cb_called == 2);+  ASSERT_EQ(send_cb_called, (long)(can_recverr ? 4 : 2));

Is the cast necessary? And if so, why long instead of int? send_cb_called is of type int.

oerdnj

comment created time in 16 days

more