🐛 BUG: "warning: Not symbolizing stack traces because $LLVM_SYMBOLIZER is not set" #3631
Comments
|
Also happening in Fedora Linux 38 |
|
Also happening on macos ventura |
|
Here is how it was triggered for me. Let it run using As a result, when restarting the server, you get: ...because the address is still in use, but you're back in the terminal prompt instead of tailing output. Browser side, you have: |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
Installing However, because the symbolizer’s arguments are version-dependent, this just raises a new issue: It seems like |
+1 Yes please, logs are a bit hard to read with this error message. |
|
I used the example code from CF at https://developers.cloudflare.com/r2/examples/aws/aws-sdk-js-v3/ As long I use cloudflare it is working fine. |
|
People keep hitting this in Discord, with errors like After killing any other |
|
in my case, I'm getting the same error, just by starting the server. I have started my repo with 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 102this 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>`.
|
|
@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). |
|
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: |
|
It seems the root cause is this: cloudflare/workerd#706 (comment)
I can confirm that when I configure -workerd/util/symbolizer.c++:98: 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>`.
workerd/jsg/jsg.c++:136: error: took recursive isolate lock; kj::getStackTrace() = /workspace/node_modules/.pnpm/@cloudflare+workerd-linux-64@1.20230922.0/node_modules/@cloudflare/workerd-linux-64/bin/workerd@...
+
+
+
+
+
+
+kj::_::HeapDisposer<workerd::Worker::Isolate::ResponseStreamWrapper>::disposeImpl(void*) const at ??:0:0
+
+
+kj::OneOf<kj::Own<kj::AsyncOutputStream, std::nullptr_t>, kj::Own<kj::GzipAsyncOutputStream, std::nullptr_t>, kj::Own<kj::BrotliAsyncOutputStream, std::nullptr_t>, workerd::api::(anonymous namespace)::EncodedAsyncOutputStream::Ended>::destroy() at ??:0:0
+
+
+kj::_::HeapDisposer<workerd::api::(anonymous namespace)::EncodedAsyncOutputStream>::disposeImpl(void*) const at ??:0:0
+
+workerd::api::ReadableStreamInternalController::pumpTo(workerd::jsg::Lock&, kj::Own<workerd::api::WritableStreamSink, std::nullptr_t>, bool)::Holder::~Holder() at ??:0:0
+kj::_::AttachmentPromiseNode<kj::Own<workerd::api::ReadableStreamInternalController::pumpTo(workerd::jsg::Lock&, kj::Own<workerd::api::WritableStreamSink, std::nullptr_t>, bool)::Holder, std::nullptr_t> >::destroy() at ??:0:0
+
+
+kj::_::AttachmentPromiseNodeBase::dropDependency() at ??:0:0
+kj::_::AttachmentPromiseNode<kj::_::Deferred<workerd::api::ServiceWorkerGlobalScope::request(kj::HttpMethod, kj::StringPtr, kj::HttpHeaders const&, kj::AsyncInputStream&, kj::HttpService::Response&, kj::Maybe<kj::StringPtr>, workerd::Worker::Lock&, kj::Maybe<workerd::api::ExportedHandler&>)::$_7> >::destroy() at ??:0:0
+
+kj::_::TransformPromiseNodeBase::dropDependency() at ??:0:0
+
+
+kj::_::TransformPromiseNode<workerd::api::DeferredProxy<void>, workerd::api::DeferredProxy<void>, workerd::api::ServiceWorkerGlobalScope::request(kj::HttpMethod, kj::StringPtr, kj::HttpHeaders const&, kj::AsyncInputStream&, kj::HttpService::Response&, kj::Maybe<kj::StringPtr>, workerd::Worker::Lock&, kj::Maybe<workerd::api::ExportedHandler&>)::$_8, workerd::api::ServiceWorkerGlobalScope::request(kj::HttpMethod, kj::StringPtr, kj::HttpHeaders const&, kj::AsyncInputStream&, kj::HttpService::Response&, kj::Maybe<kj::StringPtr>, workerd::Worker::Lock&, kj::Maybe<workerd::api::ExportedHandler&>)::$_9>::destroy() at ??:0:0
+
+kj::_::TransformPromiseNodeBase::dropDependency() at ??:0:0
+
+kj::_::TransformPromiseNode<kj::_::Void, workerd::api::DeferredProxy<void>, workerd::WorkerEntrypoint::request(kj::HttpMethod, kj::StringPtr, kj::HttpHeaders const&, kj::AsyncInputStream&, kj::HttpService::Response&)::$_6, kj::_::PropagateException>::destroy() at ??:0:0
+
+kj::_::ExclusiveJoinPromiseNode::Branch::~Branch() at ??:0:0
+kj::_::ExclusiveJoinPromiseNode::~ExclusiveJoinPromiseNode() at ??:0:0
+
+kj::_::TransformPromiseNodeBase::dropDependency() at ??:0:0
+
+
+
+
+kj::_::ChainPromiseNode::~ChainPromiseNode() at ??:0:0
+
+kj::_::AttachmentPromiseNodeBase::dropDependency() at ??:0:0
+
+kj::_::AttachmentPromiseNode<kj::_::Deferred<workerd::WorkerEntrypoint::request(kj::HttpMethod, kj::StringPtr, kj::HttpHeaders const&, kj::AsyncInputStream&, kj::HttpService::Response&)::$_8> >::destroy() at ??:0:0
+
+kj::_::TransformPromiseNodeBase::dropDependency() at ??:0:0
+
+kj::_::TransformPromiseNode<kj::Promise<void>, kj::_::Void, workerd::WorkerEntrypoint::request(kj::HttpMethod, kj::StringPtr, kj::HttpHeaders const&, kj::AsyncInputStream&, kj::HttpService::Response&)::$_9, kj::_::PropagateException>::destroy() at ??:0:0
+
+
+
+kj::_::AttachmentPromiseNodeBase::dropDependency() at ??:0:0
+
+kj::_::AttachmentPromiseNode<kj::_::Deferred<workerd::WorkerEntrypoint::request(kj::HttpMethod, kj::StringPtr, kj::HttpHeaders const&, kj::AsyncInputStream&, kj::HttpService::Response&)::$_10> >::destroy() at ??:0:0
+
+
+kj::_::TransformPromiseNode<kj::Promise<void>, kj::_::Void, kj::_::IdentityFunc<kj::Promise<void> >, workerd::WorkerEntrypoint::request(kj::HttpMethod, kj::StringPtr, kj::HttpHeaders const&, kj::AsyncInputStream&, kj::HttpService::Response&)::$_11>::destroy() at ??:0:0
+
+
+
Error: Testing errors
at loader12 (file:///tmp/tmp-xxx-xxx/xxx.js:53093:9)
at async callRouteLoaderRR (file:///tmp/tmp-xxx-xxx/xxx.js:3419:16)
at async callLoaderOrAction (file:///tmp/tmp-xxx-xxx/xxx.js:2532:16)
at async Promise.all (index 2)
at async loadRouteData (file:///tmp/tmp-xxx-xxx/xxx.js:2236:19)
at async queryImpl (file:///tmp/tmp-xxx-xxx/xxx.js:2113:20)
at async Object.query (file:///tmp/tmp-xxx-xxx/xxx.js:2065:18)
at async handleDocumentRequestRR (file:///tmp/tmp-xxx-xxx/xxx.js:3574:15)
at async file:///tmp/tmp-xxx-xxx/xxx.js:3700:294
at async handleFetch (file:///tmp/tmp-xxx-xxx/xxx.js:32751:36) {
stack: Error: Testing errors
at loader12 (file:///tmp…p/tmp-xxx-xxx/xxx.js:32751:36),
message: Testing errors
-}
[mf:inf] GET / 500 Internal Server Error (323ms)
[mf:inf] GET /favicon.ico 200 OK (9ms)Setting |
|
I got this problem when I did a simple static site testing (which has nothing to do with worker): wrangler pages dev ./siteAfter I restart the whole pc, it works. Anyway, I got the error above from /home/user/.local/bin/volta/tools/image/packages/wrangler/lib/node_modules/wrangler/wrangler-dist/cli.js:29374
throw a;
^
Error: spawn google-chrome ENOENT
at ChildProcess._handle.onexit (node:internal/child_process:284:19)
at onErrorNT (node:internal/child_process:477:16)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
Emitted 'error' event on ChildProcess instance at:
at ChildProcess._handle.onexit (node:internal/child_process:290:12)
at onErrorNT (node:internal/child_process:477:16)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
errno: -2,
code: 'ENOENT',
syscall: 'spawn google-chrome',
path: 'google-chrome',
spawnargs: [
'https://devtools.devprod.cloudflare.dev/js_app?theme=systemPreferred&ws=localhost%3A9229%2Fws&debugger=true'
]
} |
|
Sorry for the delay on getting back to this issue. We are taking a look at what the root cause of this could be. |
|
Happening all the time here as well, we can't use it anymore, unfortunately. Any work around in the meantime? |
|
For now I only got this error when dealing with Durable Objects & its WebSockets API. There's probably many scenarios where it could fall into : 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 ?). |
|
To update this issue, these warnings are coming from the |
|
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? |
|
For me, this issue was accompanied by another issue: cloudflare/workerd#1401 (comment) When I fixed that issue, this one was fixed as well... in |
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:
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
The text was updated successfully, but these errors were encountered: