workers-sdk: 🐛 BUG: "warning: Not symbolizing stack traces because $LLVM_SYMBOLIZER is not set"

Which Cloudflare product(s) does this pertain to?

Wrangler core

What version(s) of the tool(s) are you using?

3.2.0

What version of Node are you using?

No response

What operating system are you using?

Ubuntu 22.04.2 LTS

Describe the Bug

Anytime the application reports an error, the first error is prepended with this:

workerd/util/symbolizer.c++:99: warning: Not symbolizing stack traces because $LLVM_SYMBOLIZER is not set. To symbolize stack traces, set $LLVM_SYMBOLIZER to the location of the llvm-symbolizer binary. When running tests under bazel, use `--test_env=LLVM_SYMBOLIZER=<path>`.

Stack traces that follow are squished and hard to read.

This has also been reported in comments at the bottom of #3262 and #3457, and appears to affect multiple operating systems.

Please provide a link to a minimal reproduction

No response

Please provide any relevant error logs

No response

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 37
  • Comments: 19 (5 by maintainers)

Most upvoted comments

Sorry for the delay on getting back to this issue. We are taking a look at what the root cause of this could be.

To update this issue, these warnings are coming from the workerd runtime in dev mode. We’re working to suppress these since they are not actionable by users.

I read the previous comment but it would be nice to know what temporary workaround actions we can do to fix this issue for now while waiting for update. I assume one the fix is pushed we just need to update wrangler npm package right?

in my case, I’m getting the same error, just by starting the server. I have started my repo with create-remix using the Cloudflare Pages starter just a few days ago

also getting this error as well:

workerd/jsg/jsg.c++:136: error: took recursive isolate lock; kj::getStackTrace() = 10282cd9f 102ab5947 102ac8cf3 102ac8c77 1040bd7bb 102e2ced7 102e2dbf3 102d93eb3 102d940db 104090a3f 102ba9a33 104090d67 102baa51f 104090d67 102a957cf 1040926eb 104090d67 102a963c3 104091a13 104090a3f 102a96af7 104090d67 102a96c23 104091a13 104090a3f 102

this is the already spoken error I’m also getting

workerd/util/symbolizer.c++:99: warning: Not symbolizing stack traces because $LLVM_SYMBOLIZER is not set. To symbolize stack traces, set $LLVM_SYMBOLIZER to the location of the llvm-symbolizer binary. When running tests under bazel, use `--test_env=LLVM_SYMBOLIZER=<path>`.
Screenshot 2023-08-20 at 13 58 03

For now I only got this error when dealing with Durable Objects & its WebSockets API. Sounds like to be triggered by socket closing, related : https://github.com/cloudflare/workerd/issues/1299

There’s probably many scenarios where it could fall into : https://github.com/cloudflare/workerd/blob/main/src/workerd/util/symbolizer.c%2B%2B#L93

Hope we found a solution for this 🙏, or at least something we can do to suppress these error outputs (which sound to be false-positive errors only in development ?).

yup …super annoying …and no comment from the devs 👀 …I don’t know if you realize this, but this crashes the server extremely frequently for the majority (?) of people.

My way to regularly kill the server: kill $(lsof -t -i:8788)

People keep hitting this in Discord, with errors like Address already in use; toString() = 0.0.0.0:8788.

After killing any other workerd processes, things being to work again for them. Can anything be done to improve the DX here?

Happening all the time here as well, we can’t use it anymore, unfortunately. Any work around in the meantime?

@niconiahi did you ever find a solution to this error? It’s super frustrating not having source maps when developing locally. (We also are building a Remix app using the CF Pages starter).