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 commentnodejs/node

Yocto dunfell recipe nodejs_12.4.1.bb crashes compilation

Is there a reason you're reporting that to us rather than the maintainers of the yocto recipe?

josancardenasm

comment created time in an hour

issue commentnodejs/help

Change ec point formats

The first step would be to file a feature request or pull request with the openssl project.

zedd3v

comment created time in 2 hours

IssuesEvent

issue commentnodejs/node

Node not installing on fresh debian buster install in kvm

Okay, I'll reopen. I still think it's unlikely it's a bug in Node.js but maybe it's a KVM bug.

memetb

comment created time in a day

issue commentnodejs/node

please provide a way to use system-installed root certificates instead of bundled ones

If you want a way forward: open a pull request implementing it for the Big Three (Linux, macOS, Windows) and see how it's received.

Technologies:

  • Windows -> CryptoAPI
  • macOS -> Security.framework
  • Linux -> read /etc/ssl/certs? (My Linux desktop has two cert stores. Which one do you pick? Why?)
kapouer

comment created time in a day

issue commentnodejs/help

Change ec point formats

Those don't use openssl either.

zedd3v

comment created time in a day

issue commentnodejs/help

Change ec point formats

Chromium doesn't use openssl. What other languages are you referring to? And do you have examples of misbehaving websites?

zedd3v

comment created time in 2 days

pull request commentlibuv/libuv

Use io_uring for read/write/fsync on Linux

I ran some simple (plain C, non-libuv) network benchmarks last years but I didn't see much of a difference vis-a-vis epoll; epoll is already pretty efficient, even in level-triggered mode<sup>1</sup>, the way libuv uses it.

io_uring makes it easier for multiple consumers (threads) to pull off events from the ring buffer in a fair fashion but libuv isn't really set up to exploit that.

<sup>1</sup> Level-triggered mode has in at least one respect an edge over, er, edge-triggered mode because it can speculate that a partial read(2) means there is no more data available. With edge-triggered I/O, you need to call again to observe EAGAIN.

zbjornson

comment created time in 2 days

issue commentnodejs/node

please provide a way to use system-installed root certificates instead of bundled ones

As you can probably tell from the --use-openssl-ca switch, node farms out certificate management to openssl and openssl doesn't support what you're asking for.

You could file a feature request with the openssl project but check its mailing list, it's a topic has come up many times before and there are Reasons why things are the way they are.

kapouer

comment created time in 2 days

issue commentnodejs/help

Change ec point formats

Then you misunderstood my explanation. :-)

I don't think openssl actually lets you tweak that.

zedd3v

comment created time in 2 days

issue commentnodejs/node

please provide a way to use system-installed root certificates instead of bundled ones

and only use my system store (particularly, without providing any paths)

If you expect node to magically know where your system's certificate store can be found, it doesn't, bad expectation, but you can point it in the right direction with the --use-openssl-ca <dir> or --openssl-config <file> options (the SSL_CERT_DIR and OPENSSL_CONF environment variables, respectively.)

kapouer

comment created time in 2 days

issue commentnodejs/node

setTimeout imposes minimum 1-millisecond delay

See https://github.com/nodejs/node-v0.x-archive/issues/593 and commit 7fc835afe362ebd30a0dbec81d3360bd24525222 - basically, it's because node wanted to mimic browser behavior.

Preempting the "why not 4 ms then?" question: because there's no frame rate in node.

fmela

comment created time in 2 days

issue closedlibuv/libuv

100% CPU + Socket idling in CLOSE_WAIT state

In line with a previous issue opened in the NodeJS reporitory https://github.com/nodejs/node/issues/11307 and as requested by @santigimeno moved to here.


I hate to reopend this issue, but i experience the exact same bug in a pure C program using libuv as the async i/o backened. I've been trying to debug this for months before i got to the point that i found the cause could be dangling sockets. I never experience the issue myself, but a user of my software @NiekD experienced it in a daily matter. So i finally got access to his machine to debug this myself, and got to the root cause.

I use the uv_poll_t module to read and write to my sockets. What i see is the same as what's described here. The other end closes the connection. I see a FIN, ACK followed by a ACK, but libuv never triggers the UV_READABLE event so i can detect the socket being closed with recv == 0.

cjolnlhofgolpeja

afbeelding

pilight-d 3284 root   11u     IPv4      25026      0t0   TCP *:5555 (LISTEN)
pilight-d 3284 root   12u     IPv4      25027      0t0   TCP localhost:48862->localhost:5555 (ESTABLISHED)
pilight-d 3284 root   13u     IPv4      24186      0t0   TCP localhost:5555->localhost:48862 (ESTABLISHED)
pilight-d 3284 root   14u     IPv4      22413      0t0   TCP *:1883 (LISTEN)
pilight-d 3284 root   15u     IPv4      22414      0t0   TCP localhost:49200->localhost:1883 (ESTABLISHED)
pilight-d 3284 root   16u      REG       0,15     4096 18584 /sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio18/value
pilight-d 3284 root   17u     IPv4      22415      0t0   TCP localhost:49202->localhost:1883 (ESTABLISHED)
pilight-d 3284 root   18u     IPv4      17245      0t0   TCP localhost:48870->localhost:5555 (ESTABLISHED)
pilight-d 3284 root   19u     IPv4      22416      0t0   TCP *:56662 (LISTEN)
pilight-d 3284 root   20u     IPv4      22417      0t0   TCP *:54321 (LISTEN)
pilight-d 3284 root   21u     IPv4      22418      0t0   TCP localhost:49204->localhost:1883 (ESTABLISHED)
pilight-d 3284 root   22u     IPv4      22419      0t0   TCP localhost:1883->localhost:49200 (ESTABLISHED)
pilight-d 3284 root   23u     IPv4      24187      0t0   TCP localhost:5555->localhost:48870 (ESTABLISHED)
pilight-d 3284 root   24u     IPv4      22420      0t0   TCP 192.168.1.18:1883->RASPI4:57951 (CLOSE_WAIT)
pilight-d 3284 root   25u     IPv4      22422      0t0   TCP localhost:1883->localhost:49204 (ESTABLISHED)
pilight-d 3284 root   26u     IPv4      22423      0t0   TCP localhost:1883->localhost:49202 (ESTABLISHED)
pilight-d 3284 root   27u     IPv4      22427      0t0   TCP 192.168.1.18:1883->192.168.1.9:52456 (CLOSE_WAIT)
pilight-d 3284 root   28u     IPv4      17246      0t0   TCP 192.168.1.18:1883->RASPI3:41633 (CLOSE_WAIT)
pilight-d 3284 root   29u     IPv4      17247      0t0   TCP 192.168.1.18:1883->192.168.1.179:1174 (CLOSE_WAIT)
pilight-d 3284 root   30u     IPv4      17272      0t0   TCP 192.168.1.18:1883->RASPI1:51033 (CLOSE_WAIT)
pilight-d 3284 root   31u     IPv4      17273      0t0   TCP 192.168.1.18:1883->RASPI4:33404 (CLOSE_WAIT)
pilight-d 3284 root   32u     IPv4      24234      0t0   TCP 192.168.1.18:1883->RASPI4:59147 (CLOSE_WAIT)
pilight-d 3284 root   33u     IPv4      24235      0t0   TCP 192.168.1.18:1883->RASPI4:38467 (CLOSE_WAIT)

The 100% loop with an endless strace as was previously described in this issue is the same as i experience:

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

This shows that it's clearly not a NodeJS (only) bug.


In my latest test i added a debug line to the uv_poll_start callback:

void poll_cb(uv_poll_t *req, int status, int events) {
[...]
   r = uv_fileno((uv_handle_t *)req, &fd);
   printf("%d %d %d", fd, status, events);
[...]
}

With the last output before and after the socket got into a CLOSE_WAIT:

20 0 2

I just tried the poll backened instead of epoll but that didn't make a difference.

closed time in 2 days

CurlyMoo

issue commentlibuv/libuv

100% CPU + Socket idling in CLOSE_WAIT state

You've found your root cause, your program is violating a fundamental libuv design constraint. From docs/src/design.rst:

The libuv event loop (or any other API involving the loop or handles, for that matter) is not thread-safe except where stated otherwise.

I'll go ahead and close this.

CurlyMoo

comment created time in 2 days

issue closednodejs/node

Node not installing on fresh debian buster install in kvm

  • Version: v14.7.0
  • Platform: Linux debian 4.19.0-10-amd64 nodejs/node#1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux
  • Subsystem:

What steps will reproduce the bug?

Installed a fresh new debian buster into virsh kvm using debian-10.5.0-amd64-netinst.iso. Host system is debian buster as well.

Ran:

 wget https://nodejs.org/dist/v14.7.0/node-v14.7.0-linux-x64.tar.xz
 mkdir /usr/local/lib/nodejs
 tar -xJvf node-v14.7.0-linux-x64.tar.xz -C /usr/local/lib/nodejs

as per installation instructions here

Running:

  $node -v
  v14.7.0

  $nodejs -v
  v14.7.0

  $npm -v
  buffer.js:604
      slice: (buf, start, end) => buf.utf8Slice(start, end),
                                ^

  RangeError: Index out of range
      at Object.slice (buffer.js:604:37)
      at Buffer.toString (buffer.js:801:14)
      at Object.readFileSync (fs.js:412:41)
      at Object.Module._extensions..js (internal/modules/cjs/loader.js:1276:22)
      at Module.load (internal/modules/cjs/loader.js:1105:32)
      at Function.Module._load (internal/modules/cjs/loader.js:967:14)
      at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)
      at internal/main/run_main_module.js:17:47 {
    code: 'ERR_OUT_OF_RANGE'
  }

I can provide kvm creation script if necessary.

I've seen this bug referenced in this reddit thread with the implication that it might be relating to the kvm.

closed time in 2 days

memetb

issue commentnodejs/node

Node not installing on fresh debian buster install in kvm

I'm pretty sure you've found the root cause. /usr/bin/node is not what you downloaded from https://nodejs.org/.

Your node was installed by apt to /usr/bin whereas you extracted the tarball to /usr/local/lib/nodejs. Ergo, you're not running the binary from https://nodejs.org/, unless you copied it over (but that's a bad idea, don't do that - it'll clobber the system package.)

Debian provides its own builds. We don't support those and I can't help you with issues you have with them.

I'm going to close this but I can move it to nodejs/help if you have follow-up questions.

memetb

comment created time in 2 days

issue closednodejs/node

A new event to the process. The log event

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

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

Is your feature request related to a problem? Please describe.

A way to check when something is logged to stdout

Describe the solution you'd like

Whenever something is written to process.stdout, the log event is emitted with whatever is written into stdout.

Describe alternatives you've considered

N/A

closed time in 2 days

Milo123459

issue commentnodejs/node

A new event to the process. The log event

I believe the consensus here is that we're not going to make this change. I'll go ahead and close this.

Milo123459

comment created time in 2 days

issue commentnodejs/node

cc: error: unrecognized command line option ‘-m64’

Please post the output of ./configure --openssl-no-asm --verbose.

liyuzhao

comment created time in 2 days

issue commentnodejs/help

Change ec point formats

I don't think openssl actually lets you tweak that. Do you have examples of such websites?

openssl (and therefore node) uses the ec_point_formats TLS extension to advertise that it supports both compressed and uncompressed formats. The remote end can just pick what it's comfortable with.

Remotes that don't support the extension can just assume uncompressed because that's always supported when EC is.

If you're saying those remotes are tripping over the presence of the extension itself (unlikely, but then again, there are tons of misconfigured servers out there), then you can either:

  1. fix those sites, or

  2. switch to TLSv1.3 - the ec_points_format extensions is <= TLSv1.2 - or,

  3. hack openssl to make it stop sending the extension:

diff --git a/deps/openssl/openssl/ssl/statem/extensions.c b/deps/openssl/openssl/ssl/statem/extensions.c
index be09afbe71..2ef0e37cf6 100644
--- a/deps/openssl/openssl/ssl/statem/extensions.c
+++ b/deps/openssl/openssl/ssl/statem/extensions.c
@@ -163,7 +163,7 @@ static const EXTENSION_DEFINITION ext_defs[] = {
         SSL_EXT_CLIENT_HELLO | SSL_EXT_TLS1_2_SERVER_HELLO
         | SSL_EXT_TLS1_2_AND_BELOW_ONLY,
         NULL, tls_parse_ctos_ec_pt_formats, tls_parse_stoc_ec_pt_formats,
-        tls_construct_stoc_ec_pt_formats, tls_construct_ctos_ec_pt_formats,
+        NULL, NULL,
         final_ec_pt_formats
     },
     {
zedd3v

comment created time in 2 days

issue commentnodejs/node

SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1544:SSL alert number 80

I'm moving this to nodejs/help because I don't think this is an issue with Node.js per se.

The server at h5api.wapa.taobao.com:443 closes the TCP connection before the TLS handshake completes, probably because it doesn't like something that Node.js advertises in its ClientHello.

Here is a hint: it completes the handshake when you tweak ciphers:

tls.connect({host:'h5api.wapa.taobao.com', port:443, ciphers:'ECDHE-ECDSA-AES256-GCM-SHA384'})
xcodebuild

comment created time in 2 days

issue commentnodejs/node

Node not installing on fresh debian buster install in kvm

Can you post the output of which node and which nodejs? I have a sneaking suspicion that you have node installed from both https://nodejs.org/ and apt, and that the two end up biting each other. The official binary is node, not nodejs.

memetb

comment created time in 2 days

issue commentlibuv/libuv

100% CPU + Socket idling in CLOSE_WAIT state

Thanks! There's something fishy going on in your program. The relevant bits:

6803  epoll_ctl(3, EPOLL_CTL_ADD, 18, {EPOLLIN, {u32=18, u64=18}} <unfinished ...>
6808  epoll_ctl(3, EPOLL_CTL_DEL, 18, 0x73bfed50) = 0
# ...
6803  <... epoll_ctl resumed> )         = 0
6803  epoll_ctl(3, EPOLL_CTL_MOD, 18, {EPOLLIN|EPOLLOUT, {u32=18, u64=18}}) = -1 ENOENT (No such file or directory)

Note how EPOLL_CTL_DEL happens in one thread but EPOLL_CTL_ADD and EPOLL_CTL_MOD in another.

CurlyMoo

comment created time in 3 days

issue commentnodejs/help

dns.resolve() returns ESERVFAIL error for localhost

dns.resolve() contacts the DNS servers listed in /etc/resolv.conf and those may not know about (or want to return something for) localhost. Example: querying 8.8.8.8 (Google's public DNS) fails with ENOTFOUND.

Try dns.lookup(), that calls libc's getaddrinfo(3).

As using dns.lookup is not recommended

Define 'not recommended'? It's perfectly okay to use it as long as you are aware of the differences with dns.resolve().

vinitshahdeo

comment created time in 3 days

issue commentnodejs/help

NPM install returning Segmentation fault on PPC64 architecture

cc @nodejs/platform-aix (I know, it's not AIX but we don't have a PPC team.)

@narkhedek3 Would it be possible for you turn on core dumps (ulimit -c unlimited) and inspect the core dump with gdb afterwards?

gdb $(which node) <corefile> , then bt to get a stack trace and disassemble and info registers to get a disassembly of the segfaulting code.

narkhedek3

comment created time in 3 days

issue closednodejs/node

`node --perf-basic-prof index.js` - No information about JavaScript functions, only v8.

<!-- 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: Platform: -->

  • Version: v14.6.0
  • Platform: Linux rd 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

What steps will reproduce the bug?

Following this tutorial from the official node website.

perf record -e cycles:u -g -- node --perf-basic-prof index.js

This generates perf.data and a /tmp/perf-somenumbers.js file.

index.js:


function FunctionA1() {
  FunctionB2();
}

function FunctionB2() {
  console.log("Hello!");
}

FunctionA1();
perf script > perfs.out
  1. Now, this doesn't return any results, although I'd expect to see FunctionA1 calls logged by perf.
cat perfs.out | grep FunctionA1

Perf was installing via

sudo apt install linux-tools-generic

What is the expected behavior?

Javascript functions, such as FunctionA1, are visible in the captured info.

closed time in 3 days

vlopp

issue commentnodejs/node

`node --perf-basic-prof index.js` - No information about JavaScript functions, only v8.

Closing as answered, let me know if there's reason to reopen.

vlopp

comment created time in 3 days

issue closednodejs/node

child_process spawn does not pass environment key-value pairs on Windows

<!-- 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: 12.18.3
  • Platform: 64-bit Windows

What steps will reproduce the bug?

require('child_process').spawn('node', ['-pe', 'process.env.PATH'], {
  stdio: 'inherit',
  shell: true,
  env: {
    ...process.env,
    PATH: process.env.PATH + require('path').delimiter + __dirname,
  }
});

Actual behavior: PATH environment variable is not updated in the spawned process.

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

Always on Windows. It is not an issue on OSX.

What is the expected behavior?

PATH environment variable should be updated in the spawned process.

What do you see instead?

add a fake env variable to the env object passed to spawn

require('child_process').spawn('node', ['-pe', 'process.env.PATH'], {
  stdio: 'inherit',
  shell: true,
  env: {
    ...process.env,
    PATH: process.env.PATH + require('path').delimiter + __dirname,
    FAKEENV: 'FAKEVALUE',
  }
});

closed time in 3 days

beliayeu

issue commentnodejs/node

child_process spawn does not pass environment key-value pairs on Windows

I'll close this as answered. Let me know if it should be reopened.

beliayeu

comment created time in 3 days

issue closednodejs/node

Rename readdir and readdirSync methods

The method naming convention is camelcase, but I was using the fs module a few days ago and realized that only the readdir and readdirSync methods are not following this pattern. I would like to contribute to this, but I want to discuss it first, as this trivial modification will cause a breaking change.

I suggest renaming readdir to readDir and readdirSync to readDirSync, what do you think?

closed time in 3 days

thejinbok

issue commentnodejs/node

Rename readdir and readdirSync methods

The reason is this: camelCase is idiomatic JS, hence readFile(), but for methods that mirror their C/POSIX counterparts, we followed the existing naming, hence readdir().

We're not going to change that due to backwards compatibility so I'll go ahead and close this out.

thejinbok

comment created time in 3 days

issue commentnodejs/node

Node not installing on fresh debian buster install in kvm

I've moved it back but I'm unable to come up with a good explanation of why that happens. A bug seems unlikely because we've received no other bug reports but on the other hand, the stack trace is unequivocally all inside node core.

Does the REPL work (just node, no args)? Does touch t.js; node t.js work?

memetb

comment created time in 3 days

issue commentnodejs/help

Incorrect process id from spawn method, while spawning gnome-terminal, it results bash process id, not the gnome-terminal

gnome-terminal probably forks itself out of the way, or attaches to an already running instance, that's why you don't see its pid. Unless it has some out-of-band means of sending the pid back to you, the answer is "no, you can't."

VEmpink

comment created time in 3 days

issue commentnodejs/help

Change ec point formats

I'm fairly sure s->ext.ecpointformats field is dead, unused.

s->ext.peer_ecpointformats is in use but that's parsed from the cipher announcements in the peer's handshake, you don't set it manually.

If the above doesn't answer your question, can you tell more about what you're trying to do and to what end?

zedd3v

comment created time in 3 days

issue closednodejs/node

dot-prop 4.2.0 installs with nodejs 14 creating security issue

Version: v14.7.0 Platform: Linux 359fde9c186f 5.3.0-1019-aws #21~18.04.1-Ubuntu SMP Mon May 11 12:33:03 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Subsystem: dot-prop

What steps will reproduce the bug?

curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash - sudo apt-get install -y nodejs

Installs dot-prop 4.2.0 in /usr/lib/node_modules/npm/node_modules/dot-prop https://www.npmjs.com/advisories/1213

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

Every time nodejs installs

What is the expected behavior?

dot-prop >=5.1.1 should install

closed time in 3 days

dominopetter

issue commentnodejs/node

dot-prop 4.2.0 installs with nodejs 14 creating security issue

The .deb isn't maintained by us, but by nodesource. What's more, npm isn't maintained by us either, only distributed. It's its own project. Can you report your issue over at https://npm.community/? Thanks.

dominopetter

comment created time in 3 days

issue commentlibuv/libuv

100% CPU + Socket idling in CLOSE_WAIT state

Try adding -f so you also capture system calls from other threads.

CurlyMoo

comment created time in 3 days

issue commentnodejs/help

Nodemailer not working :(

Comments like yours aren't really helpful either. What's up with the downvotes?

WAINGOR

comment created time in 4 days

pull request commentlibuv/libuv

unix: refactor uv_try_write

@twose Yes, it's a node.js test. It's almost certainly a flake but let's try it one more time. Can you rebase against v1.x? Thanks.

twose

comment created time in 4 days

issue commentlibuv/libuv

100% CPU + Socket idling in CLOSE_WAIT state

This part:

epoll_ctl(3, EPOLL_CTL_ADD, 18, {EPOLLIN, {u32=18, u64=18}}) = 0
epoll_ctl(3, EPOLL_CTL_MOD, 18, {EPOLLIN|EPOLLOUT, {u32=18, u64=18}}) = -1 ENOENT (No such file or directory)

Suggests another thread closed the file descriptor (or you / strace filtered out the close() system call.)

CurlyMoo

comment created time in 4 days

issue commentnodejs/nan

Add module initializer with context corresponding to NODE_MODULE_INITIALIZER

why does Node's API also pass it in as an argument to the initializer?

As the one who introduced the original multi-context support in Node: because it seemed like a good idea at the time. :-)

murgatroid99

comment created time in 4 days

issue commentnodejs/node

A new event to the process. The log event

I think you'll be disappointed vis-a-vis compactness because you'll have to deal with ANSI control codes in the data. You're not getting a plain string.

I'll leave this open for a few more days but if no one else chimes in with strong support, I'm going to close this.

One reason for not implementing this is that emitting events is not zero cost. It's not a huge cost but little bits add up.

Milo123459

comment created time in 4 days

issue commentnodejs/node

A new event to the process. The log event

I guess my question is: what do you need that for? What's the use case?

process.stdout at its core is a stream.Writable. Other stream.Writable instances don't emit such events either.

You can monkey-patch process.stdout to intercept writes:

process.stdout.write = (function(write) {
  return function(...args) {
    console.error(args)
    return write.apply(this, args)
  }
})(process.stdout.write)
Milo123459

comment created time in 4 days

issue commentnodejs/node

cc: error: unrecognized command line option ‘-m64’

Can you try again with v10.22.0? It contains several build system fixes.

Are you cross-compiling or compiling on the machine itself? What does ./configure --openssl-no-asm --verbose print?

liyuzhao

comment created time in 4 days

issue closednodejs/node

Assert in uv__io_poll

  • Version: 12.18.3
  • Platform: macOS 10.15
  • Subsystem:

What steps will reproduce the bug?

Unknown 🤷‍♂️ , failed only once on CI.

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

Once

What is the expected behavior?

Run without crashes

What do you see instead?

Assertion failed: (timeout != -1), function uv__io_poll, file ../deps/uv/src/unix/kqueue.c, line 231.
##[error]Exit code 134 returned from process: file name '/Users/runner/runners/2.172.2/externals/node/bin/node', arguments '"/Users/runner/work/_tasks/Xcode_1e78dc1b-9132-4b18-9c75-0e7ecc634b74/5.170.2/xcode.js"'.

Additional information

Sorry that there is so little info here, but it doesn't repro on the same VM with same parameters. It's more like notification that this problem exists so you can review/analyze this part of the code. Just in case: the script is open source https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/XcodeV5/xcode.ts

closed time in 7 days

MatkovIvan

issue commentnodejs/node

Assert in uv__io_poll

Thanks, but... v6.x has been end-of-life'd for over a year so, if nothing else, you should upgrade to a supported version.

I'll close this but let me know if you still run into this with node v1[024].x.

MatkovIvan

comment created time in 7 days

issue commentnodejs/node

Assert in uv__io_poll

Interesting... I can tell from the line number that the kevent() system call (what node/libuv uses to suspend itself and wait for new events) timed out even though we told it to wait indefinitely.

It's basically an impossible condition barring kernel bugs - which is probably what you hit here. Is it possible for you to check uname -a on the affected VM?

MatkovIvan

comment created time in 7 days

Pull request review commentnodejs/node

Fixed invalid path in CONNECT method requests.

 function resetCache() {   utcCache = undefined; } +function isValidCONNECTPath(path) {+  if (!VALID_PATH_REGEX.test(path)) {+    return false;+  }+  return true;
  return VALID_PATH_REGEX.test(path));
PreYunk

comment created time in 7 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 || '/';+  path = options.path;+  if (path) {+    if (method === 'CONNECT') {+      if (path.charAt(0) === '/') {+        path = path.slice(1) || '/';+        if (!isValidCONNECTPath(path)) {+          throw new ERR_INVALID_ARG_VALUE('options.path',+                                          path,+                                          'must be a valid host:port combo');+        }+        this.path = path;+      } else {+        this.path = path;+      }+    } else {+      this.path = path;+    }+  } else {+    this.path = '/';+  }

Can you assign to this.path just once outside the if block? Every this.path = ... forces V8 to emit a type check that this is an object of the expected shape.

V8 can hoist and coalesce such checks but... it's complicated. Just assign once, please. :-)

PreYunk

comment created time in 7 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 || '/';+  path = options.path;+  if (path) {+    if (method === 'CONNECT') {+      if (path.charAt(0) === '/') {
      if (path.startsWith('/')) {

Arguably a little more idiomatic for core code.

PreYunk

comment created time in 7 days

Pull request review commentnodejs/node

Fixed invalid path in CONNECT method requests.

 const Agent = require('_http_agent'); const { Buffer } = require('buffer'); const { defaultTriggerAsyncIdScope } = require('internal/async_hooks'); const { URL, urlToOptions, searchParamsSymbol } = require('internal/url');-const { kOutHeaders, kNeedDrain } = require('internal/http');+const { kOutHeaders,+        kNeedDrain,+        isValidCONNECTPath+} = require('internal/http');
const {
  kOutHeaders,
  kNeedDrain,
  isValidCONNECTPath,
} = require('internal/http');
PreYunk

comment created time in 7 days

issue commentnodejs/nan

Add module initializer with context corresponding to NODE_MODULE_INITIALIZER

@murgatroid99 Do you want to update the API or the docs? In both cases a pull request is the best way forward. :-)

murgatroid99

comment created time in 7 days

delete branch bnoordhuis/libuv

delete branch : fix-test-thread-race

delete time in 7 days

PR merged libuv/libuv

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

bnoordhuis

pr closed time in 7 days

push eventlibuv/libuv

Ben Noordhuis

commit sha e44781a16155f2ed227aa32661edeeecbbf573c5

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. PR-URL: https://github.com/libuv/libuv/pull/2946 Refs: https://github.com/libuv/libuv/pull/2853#issuecomment-665259082 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Jameson Nash <vtjnash@gmail.com>

view details

push time in 7 days

push eventbnoordhuis/libuv

Ben Noordhuis

commit sha e44781a16155f2ed227aa32661edeeecbbf573c5

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. PR-URL: https://github.com/libuv/libuv/pull/2946 Refs: https://github.com/libuv/libuv/pull/2853#issuecomment-665259082 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Jameson Nash <vtjnash@gmail.com>

view details

push time in 7 days

issue closedlibuv/libuv

libuv fails on MontaVista Linux

uv_accept is failing on MontaVista Linux.

closed time in 7 days

vasubabukandimalla

issue commentlibuv/libuv

unix: uv_async_send takes long latency on single core CPU again

Completely untested (not even if it compiles) but this is the basic idea:

diff --git a/src/unix/async.c b/src/unix/async.c
index 5f58fb88..56274d33 100644
--- a/src/unix/async.c
+++ b/src/unix/async.c
@@ -36,6 +36,8 @@
 
 #ifdef __linux__
 #include <sys/eventfd.h>
+#include <sys/prctl.h>
+#include <time.h>
 #endif
 
 static void uv__async_send(uv_loop_t* loop);
@@ -82,9 +84,13 @@ int uv_async_send(uv_async_t* handle) {
 
 /* Only call this from the event loop thread. */
 static int uv__async_spin(uv_async_t* handle) {
+  unsigned long slack;
   int i;
   int rc;
 
+  slack = (unsigned long) -1;
+  (void) &slack;
+
   for (;;) {
     /* 997 is not completely chosen at random. It's a prime number, acyclical
      * by nature, and should therefore hopefully dampen sympathetic resonance.
@@ -97,18 +103,44 @@ static int uv__async_spin(uv_async_t* handle) {
       rc = cmpxchgi(&handle->pending, 2, 0);
 
       if (rc != 1)
-        return rc;
+        goto done;
 
       /* Other thread is busy with this handle, spin until it's done. */
       cpu_relax();
     }
 
+#ifdef __linux__
+  if (slack == (unsigned long) -1) {
+    if (prctl(PR_GET_TIMERSLACK, &slack))
+      abort();
+    if (prctl(PR_SET_TIMERSLACK, 0))
+      abort();
+  }
+
+  {
+    struct timespec ts;
+    ts.tv_sec = 0;
+    ts.tv_nsec = 0;
+    nanosleep(&ts, NULL);
+  }
+#else
     /* Yield the CPU. We may have preempted the other thread while it's
      * inside the critical section and if it's running on the same CPU
      * as us, we'll just burn CPU cycles until the end of our time slice.
      */
     sched_yield();
+#endif
   }
+
+done:
+
+#ifdef __linux__
+  if (slack != (unsigned long) -1)
+    if (prctl(PR_SET_TIMERSLACK, slack))
+      abort();
+#endif
+
+  return rc;
 }
 
 
Parallel-Hao

comment created time in 7 days

issue commentlibuv/libuv

unix: uv_async_send takes long latency on single core CPU again

I think the problem with nanosleep() is timer slack.

The linux kernel applies a performance optimization where it rounds up timeouts (the slack) in order to coalesce them. A zero timeout nanosleep() system call can sleep for 50 us or more because of slack. I expect that to negatively affect performance in an unpredictable manner.

It's possible to temporarily change the slack but that means two extra system calls in uv__async_spin() and that function should be fast.

I don't have time at the moment to do an in-depth investigation, but if you do, you know what to pay attention to now. :-)

Parallel-Hao

comment created time in 7 days

Pull request review commentlibuv/libuv

test: Avoid double evaluation in ASSERT_BASE macro

 typedef enum {   }                                                       \  } while (0) -#define ASSERT_BASE(expr, a, operator, b, type, conv)        \+#define ASSERT_BASE(a, operator, b, type, conv)              \  do {                                                        \-  if (!(expr)) {                                             \+  type eval_a = (type) a;                                    \+  type eval_b = (type) b;                                    \
  type eval_a = (type) (a);                                  \
  type eval_b = (type) (b);                                  \

Casts have higher priority than e.g. binary operators. Without the parentheses, the left-hand side gets cast but not the right-hand side.

tjarlama

comment created time in 7 days

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";

Right, I understand what Jameson means now. Can you undo this change? It's just confusing.

req->path is a copy of the path argument to uv_fs_mkstemp(), i.e., path is never mutated and can just be a string literal, like it was before.

tjarlama

comment created time in 7 days

issue commentlibuv/libuv

Get time left from timer

I think a pull request implementing that functionality is welcome.

The catch is that the timeout is stored as the event loop's idea of the current time + the timeout, i.e., as absolute time. To derive the remaining time, you have to compute handle->timeout - loop->time and check it's >= 0.

ulrikstrid

comment created time in 8 days

issue commentnodejs/nan

Add module initializer with context corresponding to NODE_MODULE_INITIALIZER

That does look relevant, but it looks like it just ignores the context parameter, instead of providing some kind of shim or fallback.

What should that shim/fallback do in your opinion? Add-ons can already obtain the context in their initializer with Nan::GetCurrentContext().

murgatroid99

comment created time in 8 days

issue commentlibuv/libuv

libuv fails on MontaVista Linux

Can you fill out the issue template? Please provide steps to reproduce.

vasubabukandimalla

comment created time in 8 days

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 9 days

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 9 days

issue commentlibuv/libuv

ci,macos: flaky process_title_threadsafe test

#2946

bnoordhuis

comment created time in 9 days

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 9 days

create barnchbnoordhuis/libuv

branch : fix-test-thread-race

created branch time in 9 days

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 9 days

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 9 days

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 9 days

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 9 days

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 9 days

pull request commentlibuv/libuv

darwin: use IOKit for uv_cpu_info

Landed in 87f07651, thanks Evan!

evanlucas

comment created time in 9 days

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 9 days

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 9 days

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 9 days

caobug

issue commentlibuv/libuv

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

Duplicate of #2923

caobug

comment created time in 9 days

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 9 days

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 9 days

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 9 days

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 9 days

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 9 days

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 9 days

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 9 days

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 11 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 11 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 11 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 11 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 12 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 12 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 12 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 12 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 12 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 12 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 12 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 12 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 12 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 12 days

more