## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
• 16:32
dependabot[bot] labeled #91
• 16:32
dependabot[bot] opened #91
• 16:32

dependabot[bot] on npm_and_yarn

Bump handlebars from 4.7.6 to 4… (compare)

• 16:24

dependabot[bot] on npm_and_yarn

• 16:24
dependabot[bot] closed #192
• 16:24
dependabot[bot] commented #192
• 16:24
dependabot[bot] labeled #196
• 16:24
dependabot[bot] opened #196
• 16:24

dependabot[bot] on npm_and_yarn

Bump handlebars from 4.4.2 to 4… (compare)

• Apr 16 14:13

jason0x43 on master

Update webdriver versions (compare)

• Apr 16 14:13

jason0x43 on gh-pages

Update assets (compare)

• Mar 30 17:45
dependabot[bot] labeled #195
• Mar 30 17:45
dependabot[bot] opened #195
• Mar 30 17:45

dependabot[bot] on npm_and_yarn

Bump y18n from 4.0.0 to 4.0.1 … (compare)

• Mar 30 17:40
dependabot[bot] labeled #90
• Mar 30 17:40
dependabot[bot] opened #90
• Mar 30 17:40

dependabot[bot] on npm_and_yarn

Bump y18n from 4.0.0 to 4.0.1 … (compare)

• Mar 18 07:44
Biboba commented #1179
• Mar 17 01:05
jason0x43 commented #1179
• Mar 17 00:59

jason0x43 on 4.9

Update dependencies to fix vuln… (compare)

rhpijnacker
@rhpijnacker
I think I have found a way to circumvent the dojo loader issue: by increasing the waitSeconds dojo configuration property to 120 I'm not getting the error any more.
This did point me at another issue, though: we are using Babel and include the full source code in the sourceMappingURL (which was the only way to get it mapped correctly, IIRC). However, there is little use sending this additional data to BrowserStack every time we run the test suite. Is there a way to remove this line at run-time?
Jason Cheatham
@jason0x43
There isn't currently an automatic way to strip source maps out of code, no. Intern has the infrastructure in place to write custom middleware for its server, which would let you strip that out on-the-fly; it would need to expose some config options to let users actually write middleware. It would probably be cleaner to use separate source maps, though.
rhpijnacker
@rhpijnacker
Yes, I will investigate the latter, but we could not get that running.
rhpijnacker
@rhpijnacker
About the Ctrl-C issue. Do you have any suggestion where to start looking?
Jason Cheatham
@jason0x43
One tool I've used for this sort of thing is wtfnode. You run a program with wftnode, then kill it with ctrl-c, and wtfnode will tell you what resources are still being held open.
I'm still a bit unsure of exactly what's still running. Like, in a functional test run there are normally three processes: Intern (node), Selenium (java), and whatever webdriver is in use (e.g., chromedriver). If there's still a node process running after Intern dies, I'm curious about what it is.
You could also run Intern in debug mode and ensure that you see "Stopping server..." followed by "Stopped http server" and "Stopped ws server".
rhpijnacker
@rhpijnacker
Haha, wtfnode ... hilarious
Jason Cheatham
@jason0x43
:smile:
rhpijnacker
@rhpijnacker
The process that remains running is Intern (node)
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-4  4.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
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.
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.