Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 06 21:42
    dependabot[bot] labeled #198
  • May 06 21:42
    dependabot[bot] opened #198
  • May 06 21:42

    dependabot[bot] on npm_and_yarn

    Bump underscore from 1.9.1 to 1… (compare)

  • May 06 21:41
    dependabot[bot] labeled #93
  • May 06 21:41
    dependabot[bot] opened #93
  • May 06 21:41

    dependabot[bot] on npm_and_yarn

    Bump underscore from 1.9.1 to 1… (compare)

  • May 06 18:04
    dependabot[bot] labeled #92
  • May 06 18:04
    dependabot[bot] opened #92
  • May 06 18:04

    dependabot[bot] on npm_and_yarn

    Bump lodash from 4.17.19 to 4.1… (compare)

  • May 06 17:39

    dependabot[bot] on npm_and_yarn

    (compare)

  • May 06 17:39
    dependabot[bot] closed #190
  • May 06 17:39
    dependabot[bot] commented #190
  • May 06 17:39
    dependabot[bot] labeled #197
  • May 06 17:39
    dependabot[bot] opened #197
  • May 06 17:39

    dependabot[bot] on npm_and_yarn

    Bump lodash from 4.17.15 to 4.1… (compare)

  • May 06 16:32
    dependabot[bot] labeled #91
  • May 06 16:32
    dependabot[bot] opened #91
  • May 06 16:32

    dependabot[bot] on npm_and_yarn

    Bump handlebars from 4.7.6 to 4… (compare)

  • May 06 16:24

    dependabot[bot] on npm_and_yarn

    (compare)

  • May 06 16:24
    dependabot[bot] closed #192
rhpijnacker
@rhpijnacker
I'll give wtfnode a try (when I get around to it)
Jason Cheatham
@jason0x43
But it stopped outputting to stdout, and you got a prompt back?
rhpijnacker
@rhpijnacker
Well, npm gave me the prompt back, but node is still running (and outputting) in the background
Jason Cheatham
@jason0x43
Ohhhhh, it's running behind npm.
rhpijnacker
@rhpijnacker
Yes, (sorry if I hadn't mentioned that before)
Jason Cheatham
@jason0x43
Are you sure that the SIGINT is being received by Intern? There have been a couple of npm issues in the past regarding signals not being forwarded to processes started via npm run.
rhpijnacker
@rhpijnacker
So, there are two ways we are invoking this:
  1. via npm ... it looks like the complete tree is still there (so could be that Intern does not get to see the SIGINT)
  2. via a custom script that spawns node directly, this is similar to when I invoke node node_modules\intern\bin\intern.js ...
    Witch case 2. I can see that the tunnel client processes are cleaned up on Ctrl-C, but then the node process keeps running. I have to kill it by some other means
So, we might be looking at 2 different errors here
Btw. when I Ctrl-C again, it tries to run wmic PROCESS GET ... which fails for some reason. This indicates that the SIGINT handler is still getting called on the next Ctrl-C's
Jason Cheatham
@jason0x43
Do you get a stack for the wmic error?
rhpijnacker
@rhpijnacker
^CUnhandled error: { Error: Command failed: wmic PROCESS GET ParentProcessId,ProcessId                          
^C                                                                                                              
    at checkExecSyncError (child_process.js:616:11)                                                             
    at Object.execSync (child_process.js:653:13)                                                                
    at getChildProcesses (c:\pms\src\iscv3\node_modules\@theintern\digdug\lib\util.js:90:28)                    
    at Object.kill (c:\pms\src\iscv3\node_modules\@theintern\digdug\lib\util.js:24:5)                           
    at process.<anonymous> (c:\pms\src\iscv3\node_modules\@theintern\digdug\Tunnel.js:237:58)                   
    at process.emit (events.js:189:13)                                                                          
  status: 3221225786,                                                                                           
  signal: null,                                                                                                 
  output: [ null, '', '^C' ],                                                                                   
  pid: 33508,                                                                                                   
  stdout: '',                                                                                                   
  stderr: '^C' }                                                                                                
(ノಠ益ಠ)ノ彡┻━┻                                                                                                     
Error: Command failed: wmic PROCESS GET ParentProcessId,ProcessId                                               
^C                                                                                                              
  at checkExecSyncError @ child_process.js:616:11                                                               
  at Object.execSync @ child_process.js:653:13                                                                  
  at getChildProcesses @ node_modules\src\lib\util.ts:133:9                                                     
  at Object.kill @ node_modules\src\lib\util.ts:49:2                                                            
  at process.<anonymous> @ node_modules\src\Tunnel.ts:462:31                                                    
  at process.emit @ events.js:189:13
Jason Cheatham
@jason0x43
Ah, ok, that's probably happening because digdug's sigint handler is trying to kill a process that's already been killed. The handler is still resident because Intern is still alive.
Hmmm...so one thing we could try is explicitly cancelling the run task, and possibly the server, when SIGINT happens. Somewhere in executors/Node, maybe in _beforeRun, register a SIGINT handler that will call this._runTask.cancel()and this.server.stop().
rhpijnacker
@rhpijnacker
ok
rhpijnacker
@rhpijnacker
It looks like wtfnode isn't very helpful. When I run it that way, it cleanly exits.
Jason Cheatham
@jason0x43
Are you using it in the same we you'd normally use node (via your test script or npm)?
rhpijnacker
@rhpijnacker
C:\> node node_modules\intern\bin\intern.js config=@local-chrome-headless

vs

C:\> wtfnode node_modules\intern\bin\intern.js config=@local-chrome-headless

the only difference are the extra wtf characters

Jason Cheatham
@jason0x43
Hmmm... But it does hang when you run the first one? (node node_modules ...) I thought it was only hanging when run through npm or via your test script.
rhpijnacker
@rhpijnacker
Yes, also this way
Jason Cheatham
@jason0x43
Oh, yeah, SIGINT with wtfnode will cleanly exit because it calls process.exit. The goal of wtfnode is to indicate what resources are still open when the program exist. Normally it'll just be stdout and stdin. If there are timers or other handles still open, that's the problem.
rhpijnacker
@rhpijnacker
So, what can we conclude from that?
Jason Cheatham
@jason0x43
What did wtfnode show when you ctrl-c'ed?
rhpijnacker
@rhpijnacker
Except for the usual "Do you want to terminate the script (y/n)" nothing
Maybe we should just switch to using wtfnode ;)
Jason Cheatham
@jason0x43
Ideally you should be seeing something like:
10:57:06 ~/Documents/Work/src/intern/intern-44.x !2                                           ▼  npm.registry.local  4.9.0-pre
❯ NODE_PATH=_build wtfnode _build/src/bin/intern.js config=@wd
Listening on localhost:9000 (ws 9001)
Tunnel started
^C[WTF Node?] open handles:
- File descriptors: (note: stdio always exists)
  - fd 1 (tty) (stdio)
  - fd 2 (tty) (stdio)
- Child processes
  - PID 6843
    - Entry point: /Users/jason/Documents/Work/src/intern/intern-4/node_modules/@theintern/digdug/Tunnel.js:231
    - STDIO file descriptors: 28, 30, 32
- Servers:
  - :::9001 (HTTP)
    - Listeners:
      - request: WebSocketServer @ /Users/jason/Documents/Work/src/intern/intern-4/node_modules/ws/lib/websocket-server.js:65
  - :::9000 (HTTP)
    - Listeners:
      - request: app @ /Users/jason/Documents/Work/src/intern/intern-4/node_modules/express/lib/application.js:617
- Timers:
  - (30000 ~ 30 s) (anonymous) @ /Users/jason/Documents/Work/src/intern/intern-4/_build/src/lib/Test.js:143
  - (5 ~ 5 ms) (anonymous) @ /Users/jason/Documents/Work/src/intern/intern-4/node_modules/lodash/lodash.js:6646
  - (5 ~ 5 ms) (anonymous) @ /Users/jason/Documents/Work/src/intern/intern-4/node_modules/lodash/lodash.js:6646
rhpijnacker
@rhpijnacker
i'm not seeing any this._runTask in executors/Node
Jason Cheatham
@jason0x43
It's set in the parent class (executors/Executor)
rhpijnacker
@rhpijnacker
Ah, ok
rhpijnacker
@rhpijnacker
Looks like that suggestion to cancel _runTask and stop the server helps.
It still takes 5 sec. for it to actually exit, but at least it does not keep running anymore.
With coverage enabled, it actually takes much longer, and the CPU goes up. So it looks like it still tries to calculate the coverage.
Jason Cheatham
@jason0x43
Progress!
rhpijnacker
@rhpijnacker
FYI: I took another look at Babel and the problems we had with not-inline source maps. Looks like this is a known bug: babel/babel#5261.
Fortunately it also lists a workaround. So that means stripping the sourceMaps run-time will not be needed after all.
Jason Cheatham
@jason0x43
:tada:
rhpijnacker
@rhpijnacker

Do you recognize this message:

SyntaxError: Unexpected token h in JSON at position 0
  at JSON.parse @ anonymous
  @ src\lib\ProxiedSession.ts:152:29
  @ node_modules\@theintern\common\index.js:16:7174
  at process._tickCallback @ internal\process\next_tick.js:68:7
  at Command._callSessionMethod @ node_modules\src\Command.ts:811:11
  at Command.quit @ node_modules\src\Command.ts:1561:16
  at Suite.after @ src\lib\executors\Node.ts:565:28
  @ src\lib\Suite.ts:434:54
  at new e @ node_modules\@theintern\common\index.js:16:5068
  at runLifecycleMethod @ src\lib\Suite.ts:399:13
  at after @ src\lib\Suite.ts:507:13
  @ src\lib\Suite.ts:719:47
  @ node_modules\@theintern\common\index.js:16:6889
  @ node_modules\@theintern\common\index.js:16:7174

This happens every now and then (on BrowserStack and IE11)

Jason Cheatham
@jason0x43
That's happening when the local server is trying to parse coverage data it downloaded from the browser.
It means that whatever it got wasn't valid JSON. Possibly the raw selenium log from BS would show more information.
That error should also ideally be showing some part of the invalid data.
rhpijnacker
@rhpijnacker
In this session I did not request for coverage results. But apparently it still tries to get that from the browser? Does that make sense?
Jason Cheatham
@jason0x43
Coverage data is collected by default unless coverage is set to false. You shouldn't be getting an error in any case, though -- if there was no coverage data available, the request shouldn't return any. Try setting coverage: false in your config. If you happen to see what data cause the error, that would be useful to know so we could fix the underlying issue.
rhpijnacker
@rhpijnacker
Does it have to be false or falsy? I only set coverage to an actual value for other configurations.
The raw selenium logs does not seem to show anything suspicious:
13:04:29.538 DEBUG [WebDriverServlet.handle] - Found handler: fef00a61-78c4-43a9-97df-11ba3c1b0a0e (org.openqa.selenium.ie.InternetExplorerDriverService)
13:04:29.538 DEBUG [WebDriverServlet.lambda$handle$3] - Handler thread for session fef00a61-78c4-43a9-97df-11ba3c1b0a0e (internet explorer): Executing POST on /session/fef00a61-78c4-43a9-97df-11ba3c1b0a0e/execute (handler: ServicedSession)
13:04:29.540 DEBUG [Passthrough.handle] - To upstream: {"script":"return (function getCoverageData(coverageVariable) {\n        var coverageData = (function () {\n            return this;\n        })()[coverageVariable];\n        return coverageData && JSON.stringify(coverageData);\n    }).apply(this, arguments);","args":["__coverage__"]}
13:04:29.540 DEBUG [HttpURLConnection.writeRequests] - sun.net.www.MessageHeader@c2cff515 pairs: {POST /session/fef00a61-78c4-43a9-97df-11ba3c1b0a0e/execute HTTP/1.1: null}{Authorization: Basic cnV1ZGdyYXZlc3RlaWpuMTpGMXBReFRIYnk3d3hCZVBkc21IUw==}{Accept: application/json,text/plain;q=0.9}{X-Forwarded-Host: hub.browserstack.com}{User-Agent: axios/0.19.2}{X-Forwarded-For: 194.171.252.100}{x-connid: 21621292158}{BStack-Host: 185.44.130.87}{x-conn: keep-alive}{Content-Type: application/json; charset=utf-8}{Connection: close}{Cache-Control: no-cache}{Pragma: no-cache}{Host: localhost:64856}{Content-Length: 285}
13:04:29.610 DEBUG [HttpURLConnection.getInputStream0] - sun.net.www.MessageHeader@1b0da276 pairs: {null: HTTP/1.1 200 OK}{Content-Length: 77}{Content-Type: application/json; charset=UTF-8}{Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept}{Accept-Ranges: bytes}{Connection: close}
13:04:29.611 DEBUG [Passthrough.handle] - To downstream: {"sessionId":"fef00a61-78c4-43a9-97df-11ba3c1b0a0e","status":0,"value":null}
Jason Cheatham
@jason0x43
false. It can be specifically false, or an array of files or globs.
rhpijnacker
@rhpijnacker
What happens when it is not set in the config? Does it default to false?
Jason Cheatham
@jason0x43
No (hence "Coverage data is collected by default" :smile: )
rhpijnacker
@rhpijnacker
Ah, ok. That's something I would want to definitely fix then.
Jason Cheatham
@jason0x43
It should probably be disabled by default, though. Currently the default is [], which enables coverage collection, but doesn't actually instrument any files.
rhpijnacker
@rhpijnacker
Is there any usecase where that is useful?
Jason Cheatham
@jason0x43
When you've instrumented code using an external tool like nyc
rhpijnacker
@rhpijnacker
Ah, ok
Jason Cheatham
@jason0x43
That could be more clear, too, though. Like, coverage could support false, an array of globs, and something more explicit like 'external' to indicate that coverage data should be collected even though Intern isn't instrumenting any files itself.