deno v1.25 and above hangs on specific machines with no error

[jeffwillette]

Hello. I use some vim plugins which depend deno. Recently, everything broke on some machines when I updated deno and I have found that on some remote machines v1.25 breaks...

with version 1.24.3 I get this output,

$ deno run https://deno.land/std/examples/welcome.ts
Welcome to Deno!

But with any version >= 1.25 I get the following:

remote$ deno run https://deno.land/std/examples/welcome.ts
# ...hangs for many minutes before completing                                                                                                                       

This only happens on some remote machines, and my desktop handles all versions correctly. Any idea what could be causing this?

[sigmaSd]

you can use gdb -p (pidof deno) in another terminal and then thread apply all bt to get a back-trace and see where is stuck.

[jeffwillette]

you can use gdb -p (pidof deno) in another terminal and then thread apply all bt to get a back-trace and see where is stuck.

Thanks for the tip. I will try to do that, but I am not a root user on the machine and it does not have gdb. I tried to build it from source and ran into dependency issues, so it might take a while before I can run gdb

I left the deno run command going in the background and it eventually completed, so that means that deno run does work, but just incredibly slow (it take about 10 minutes to complete running). The machine is idle, and works snappy for everything else, so something is definitely off.

[sigmaSd]

Maybe it's running out of resources? Did you monitor it with htop for example?

[jeffwillette]

Maybe it's running out of resources? Did you monitor it with htop for example?

There was nothing running on the machine, and when I downgrade to anything < 1.25 it works instantly, so there is definitely something within that version that is different.

[dsherret]

What's the output with:

deno run --log-level=debug https://deno.land/std/examples/welcome.ts

Does it also happen when running a JavaScript file with no TypeScript dependencies?

[jeffwillette]

What's the output with:

deno run --log-level=debug https://deno.land/std/examples/welcome.ts

Does it also happen when running a JavaScript file with no TypeScript dependencies?

I ran the code with the log level as suggested and I saw the following difference in logs between 1.24.3 and 1.25.0...

# 1.24.3
$ deno run --log-level=debug https://deno.land/std/examples/welcome.ts
DEBUG RS - deno_runtime::js:32 - Deno isolate init with snapshots.
DEBUG JS - args []
DEBUG RS - deno:1082 - main_module https://deno.land/std/examples/welcome.ts
DEBUG RS - deno::file_fetcher:648 - FileFetcher::fetch() - specifier: https://deno.land/std/examples/welcome.ts
DEBUG RS - deno_runtime::permissions:51 - ⚠️️  Granted net access to "deno.land"
DEBUG RS - deno::file_fetcher:554 - FileFetcher::fetch_remote() - specifier: https://deno.land/std/examples/welcome.ts
DEBUG RS - deno_runtime::permissions:51 - ⚠️️  Granted net access to "deno.land"
DEBUG RS - deno::file_fetcher:400 - FileFetcher::fetch_cached - specifier: https://deno.land/std/examples/welcome.ts
DEBUG RS - deno::file_fetcher:400 - FileFetcher::fetch_cached - specifier: https://deno.land/[email protected]/examples/welcome.ts
Welcome to Deno!

# 1.25.0
$ deno run --log-level=debug https://deno.land/std/examples/welcome.ts
DEBUG RS - deno_runtime::js:32 - Deno isolate init with snapshots.
DEBUG JS - args []
DEBUG RS - deno::worker:72 - main_module https://deno.land/std/examples/welcome.ts

I also made a js file with just one line console.log("hello") and tried to run it and it hung on the same spot.

# 1.25.0 with javascript file
$ deno run --log-level=debug test.js
DEBUG RS - deno_runtime::js:32 - Deno isolate init with snapshots.
DEBUG JS - args []
DEBUG RS - deno::worker:72 - main_module file:https:///home/jeff/test.js

[dsherret]

Maybe try running with:

deno run --check --log-level=debug https://deno.land/std/examples/welcome.ts

That will indicate if it ever reaches type checking. I'm wondering if this might be caused by https://deno.com/blog/v1.25#improvements-to-startup-time where it uses sqlite to store data in the $DENO_DIR -- I'll open a PR to add more logging. It would be much faster to debug this if I could reproduce this.

I left the deno run command going in the background and it eventually completed, so that means that deno run does work, but just incredibly slow (it take about 10 minutes to complete running). The machine is idle, and works snappy for everything else, so something is definitely off.

Is it faster if you set DENO_DIR="$(pwd)/temp" or whatever in order to use a directory in the current folder for the cache? I wonder if perhaps the $DENO_DIR is a remote directory on that machine, which is causing slowness with sqlite.

[dsherret]

You may also want to try doing strace deno run https://deno.land/std/examples/welcome.ts to see where it spends all its time.

[jeffwillette]

Maybe try running with:

deno run --check --log-level=debug https://deno.land/std/examples/welcome.ts

Output:

DEBUG RS - deno_runtime::js:32 - Deno isolate init with snapshots.
DEBUG JS - args []
DEBUG RS - deno::worker:72 - main_module https://deno.land/std/examples/welcome.ts
# hangs here

Is it faster if you set DENO_DIR="$(pwd)/temp" or whatever in order to use a directory in the current folder for the cache? I wonder if perhaps the $DENO_DIR is a remote directory on that machine, which is causing slowness with sqlite.

This seems to fix the problem. If I set DENO_DIR=~/tmp/ to be on my home folder drive, then it works, but I have to work in a separate filesystem as the the drive mounted to home is quite small. So Setting DENO_DIR=/dev1/tmp causes the hang.

I have a workable solution for now, so please feel free to close this issue or keep it open if its an issue which needs to be fixed. Thanks for your help

[dsherret]

I'm glad there's a workaround, but this doesn't sound like a great experience. I'd like to get to the bottom of what's causing this, so let's keep it open.

What's the system setup like? It sounds like the DENO_DIR was previously on a different drive?

[jeffwillette]

• There is a cluster of Linux (Ubuntu 18.04) machines with shared nfs storage drives between them.
• There is a small shared storage drive for /home, but I avoid using it because it is rather small and causes problems if too many people use it and it fills up.
• Therefore, In my bashrc, I have set XDG_CACHE_HOME=/dev1/tmp instead of /home/[user]/[cachedir]
• I assume DENO_DIR probably defaults to use XDG_CACHE_HOME because if I set DENO_DIR=/dev1/tmp then it fails with the hang. (/dev1/tmp would have been the default behavior for me when I upgraded to deno >= 1.25.0)
• If I however set DENO_DIR=/home/[user]/tmp, then it works.

Whatever is causing this, deno < 1.25.0 works on /dev1/tmp but deno >= 1.25.0 does not

The weird part is that both drives are mounted as nfs filesystems so I am not sure what the difference between them would be. /etc/fstab looks like this...

ib100:/home /home nfs defaults 0 0
st1:/dev1 /dev1 nfs defaults,user,exec 0 0