Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken message test #5

Closed
targos opened this issue Jun 1, 2017 · 15 comments
Closed

Broken message test #5

targos opened this issue Jun 1, 2017 · 15 comments

Comments

@targos
Copy link
Member

targos commented Jun 1, 2017

CI run: https://ci.nodejs.org/job/node-test-commit-node-v8/32/

Error:

length differs.
expect=1
actual=0
patterns:
pattern = ^Hello\,\ World\!$
outlines:
not ok 1432 message/console_low_stack_space
  ---
  duration_ms: 0.140
  severity: fail
  stack: |-

Commit: v8/v8@69aa868

@targos
Copy link
Member Author

targos commented Jun 13, 2017

This is still happening and I don't know if we have to change this test or if it's a V8 issue.

Repro:

function a(n) {
  try {
    a(n + 1);
  } catch (e) {
    console.log('overflow ' + n);
  }
}

a(0);

With Node 7, it prints "overflow 15288".
With Node 8, it prints "overflow 5088".
With canary, it prints nothing.

I put some process._rawDebug() in the code and it shows that the log fails here (Maximum call stack size exceeded): https://github.com/nodejs/node/blob/ca8a29c3606421d71ce3120cd34febacd7874293/lib/console.js#L92

/cc @nodejs/v8 @addaleax

@targos
Copy link
Member Author

targos commented Jun 13, 2017

Reverting v8/v8@69aa868 fixes this issue.

@addaleax
Copy link
Member

Ugh … this is tricky. I think the most semantically correct way to fix that would be to re-throw certain errors like a stack overflow in the catch block two lines below the line you linked

@bmeurer
Copy link
Member

bmeurer commented Jun 13, 2017

cc @isheludko

@addaleax
Copy link
Member

@bmeurer To be clear, I don’t think V8 is doing anything it shouldn’t, and you don’t need to investigate.

This is my fault, I introduced that test in dab0987 and later accidentally broke it by changing error handling in f18e08d, it’s pure luck that the test hasn’t been failing so far.

@bnoordhuis
Copy link
Member

I wouldn't expect console.log() or any other function call to work in a stack overflow situation. I'd just change or remove the test.

@addaleax
Copy link
Member

@bnoordhuis I probably should have commented that in the test, but the test isn’t checking that console.log() works in a stack overflow situation; it’s checking that, once a stack overflow occurs while trying to put theconsole object together, console.log() works after the stack has unwound sufficiently.

@bnoordhuis
Copy link
Member

I was going by @targos's test case, I see that the message test does something slightly different. I don't know if exception landing pads are expected to work like that when the stack is full.

@targos
Copy link
Member Author

targos commented Jun 14, 2017

@addaleax do you have an idea on how to fix this without removing the test?

@addaleax
Copy link
Member

@targos can you try something like

diff --git a/lib/console.js b/lib/console.js
index 7ec9c846329c..49e6633902b0 100644
--- a/lib/console.js
+++ b/lib/console.js
@@ -90,6 +90,9 @@ function write(ignoreErrors, stream, string, errorhandler) {
 
     stream.write(string, errorhandler);
   } catch (e) {
+    if (String(e) === 'RangeError: Maximum call stack size exceeded') {
+      throw e;
+    }
     // Sorry, there’s no proper way to pass along the error here.
   } finally {
     stream.removeListener('error', noop);

I didn’t check myself that this works together with canary, I might have the time a bit later this week to do it myself.

(I know this seems odd – maybe f18e08d should have been a bit less strict about catching all errors…)

@targos
Copy link
Member Author

targos commented Jun 14, 2017

@addaleax I tried that and it doesn't work with canary.
If I add process._rawDebug('test') just before the throw, I can see "test" being logged 4 times and then nothing.

@addaleax
Copy link
Member

Ugh, okay. I’ll take a look as soon as I get the chance (which is likely not before Friday, sorry).

@targos
Copy link
Member Author

targos commented Jun 14, 2017

No problem. We have plenty of time before V8 6.1 goes stable.

targos added a commit to nodejs/node that referenced this issue Jun 23, 2017
targos added a commit to nodejs/node that referenced this issue Jun 26, 2017
targos added a commit that referenced this issue Jun 26, 2017
targos added a commit to nodejs/node that referenced this issue Jun 27, 2017
targos added a commit to nodejs/node that referenced this issue Jun 28, 2017
@targos
Copy link
Member Author

targos commented Jul 21, 2017

Ping @addaleax. Would you still like to find something better than removing the test?

addaleax added a commit to addaleax/node that referenced this issue Aug 1, 2017
Make a message test more accurate in what it’s testing for.
This requires not swallowing stack overflow RangeErrors in
`console.log` and similar methods, which I would consider a
bugfix in itself.

Fixes: nodejs/node-v8#5
@targos
Copy link
Member Author

targos commented Aug 3, 2017

This is going to be fixed in nodejs/node#14580. Closing.

@targos targos closed this as completed Aug 3, 2017
targos pushed a commit to targos/node that referenced this issue Aug 3, 2017
Make a message test more accurate in what it’s testing for.
This requires not swallowing stack overflow RangeErrors in
`console.log` and similar methods, which I would consider a
bugfix in itself.

PR-URL: nodejs#14580
Fixes: nodejs/node-v8#5
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
addaleax added a commit to nodejs/node that referenced this issue Aug 7, 2017
Make a message test more accurate in what it’s testing for.
This requires not swallowing stack overflow RangeErrors in
`console.log` and similar methods, which I would consider a
bugfix in itself.

PR-URL: #14580
Fixes: nodejs/node-v8#5
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
nodejs-ci pushed a commit that referenced this issue Oct 27, 2017
Currently when running the test without an internet connection there are
two JavaScript test failures and one cctest. The cctest only fails on
Mac as far as I know. (I've only tested using Mac and Linux thus far).

This commit moves the two JavaScript tests to test/internet.

The details for test_inspector_socket_server.cc:

[ RUN      ] InspectorSocketServerTest.FailsToBindToNodejsHost
make[1]: *** [cctest] Segmentation fault: 11
make: *** [test] Error 2

lldb output:

[ RUN      ] InspectorSocketServerTest.FailsToBindToNodejsHost
Process 63058 stopped
* thread #1: tid = 0x7b175, 0x00007fff96d04384
* libsystem_info.dylib`_gai_simple + 87, queue =
* 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1,
* address=0x0)
    frame #0: 0x00007fff96d04384 libsystem_info.dylib`_gai_simple + 87
libsystem_info.dylib`_gai_simple:
->  0x7fff96d04384 <+87>: movw   (%rdx), %ax
    0x7fff96d04387 <+90>: movw   %ax, -0x2a(%rbp)
    0x7fff96d0438b <+94>: movq   %r13, -0x38(%rbp)
    0x7fff96d0438f <+98>: movq   0x18(%rbp), %rcx

(lldb) bt
* thread #1: tid = 0x7b175, 0x00007fff96d04384
* libsystem_info.dylib`_gai_simple + 87, queue =
* 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1,
* address=0x0)
  * frame #0: 0x00007fff96d04384 libsystem_info.dylib`_gai_simple + 87
    frame #1: 0x00007fff96cfe98b libsystem_info.dylib`search_addrinfo +
179
    frame #2: 0x00007fff96cfafef libsystem_info.dylib`si_addrinfo + 2255
    frame #3: 0x00007fff96cfa67b libsystem_info.dylib`getaddrinfo + 179
    frame #4: 0x00000001017d8888
cctest`uv__getaddrinfo_work(w=0x00007fff5fbfe210) + 72 at
getaddrinfo.c:102
    frame #5: 0x00000001017d880e
cctest`uv_getaddrinfo(loop=0x000000010287cb80, req=0x00007fff5fbfe1c8,
cb=0x0000000000000000, hostname="nodejs.org", service="0",
hints=0x00007fff5fbfe268) + 734 at getaddrinfo.c:192
    frame #6: 0x000000010171f781
cctest`node::inspector::InspectorSocketServer::Start(this=0x00007fff5fbfe658)
+ 801 at inspector_socket_server.cc:398
    frame #7: 0x00000001016ed590
cctest`InspectorSocketServerTest_FailsToBindToNodejsHost_Test::TestBody(this=0x0000000105001fd0)
+ 288 at test_inspector_socket_server.cc:593

I'm not sure about the exact cause for this but when using a standalone
c program to simulate this it seems like when the ai_flags
`AI_NUMERICSERV` is set, which is done in inspector_socket_server.cc
line 394, the servname (the port in the FailsToBindToNodejsHost test) is
expected to be a numeric port string to avoid looking it up in
/etc/services. When the port is 0 as is it was before this commit the
segment fault occurs but not if it is non-zero.

PR-URL: nodejs/node#16255
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants