prisma: Error: Command was killed with SIGSEGV (Segmentation fault): /Users/.../node_modules/prisma2/query-engine-darwin --enable_raw_queries cli --dmmf

I sure am, I knew it was a bad idea to use newest node 🙃 I’ll try an older node, thank you

EDIT

node 12.16.3 works perfectly, thanks again!

We could reproduce internally and are now investigating and working on a fix.

I ran into this issue when attempting seed 1,230 objects into a Supabase table. I was using node v17.x at the time and every time I ran yarn prisma db seed it would get terminated tossing the following error:

Error: Command was killed with SIGSEGV (Segmentation fault): node --require esbuild-register prisma/seed.ts

I then changed back to the most recent node LTS (v16.16.0 at the time of this writing) and it worked without issue.

This solved it for me too! Thank you. I used the snippet here to force the node version to 12.16.3 for my Prisma-containing project only.

Using Node.js v12 instead of v14 fixed the issue for me as well.

@cephalization

Are you using Node js 14? If yes, please try the latest alpha npx @prisma/cli@alpha generate. See #2361 , in case of node 14 the segfault is coming from Node js and not from Prisma when we try to concurrently write files to the file system. We need to open a bug in Node for that but for now we have implemented a workaround which is available in alpha.

Thanks @olance - this confirms our observations: There is a chunk of data missing in the binaries for an unknown reason. As I wrote above, we have our theories but we do not know for sure. We will get more data when preview025 is released and adopted by e.g. Redwood and you can try this again.

Hi @janpio thanks for pointing me to this issue!

I think I’m now 99% sure this was a corrupted binary that caused the issue:

• Working project on one machine and non-working one on another were using the exact same version of Prisma packages

• However, the query-engine-darwin binaries were different: there was at least one big 3MB chunk of zeroes in one of them, that was actually filled with data in the other.

• Deleting the cache (rm -rf ~/.cache/prisma) and regenerating the Prisma Client fetched a more recent version and fixed everything on the machine that kept on failing

• the faulty binary was fetched on March the 19th

• the working binary was fetched on March the 22nd

• I currently have, on the machine where things were failing initially, an engine binary in my cache whose lastModified-query-engine file says Tue, 03 Mar 2020 14:19:39 GMT, and it works. Not sure why it got downloaded along with the other binary from the 23rd of March though, but it really points to a corrupted download that got fixed by clearing the cache.

I’d really encourage implementation of a checksum indeed, that would help at least catch the issue early on if it’s really a corruption problem.

I don’t think crash reports will be very helpful if we’re really looking at corrupted downloads, but just in case, here goes:

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       EXC_I386_GPFLT
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [98592]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   query-engine-darwin           	0x000000010b9d7000 alloc::slice::_$LT$impl$u20$$u5b$T$u5d$$GT$::concat::h35a9f1e00e88c910 + 80
1   query-engine-darwin           	0x000000010b3dba13 _$LT$std..future..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::h7008d3eac8096ec8 + 115
2   query-engine-darwin           	0x000000010b29c22c prisma::context::PrismaContext::new::_$u7b$$u7b$closure$u7d$$u7d$::hf502954b5965bede + 940
3   query-engine-darwin           	0x000000010b27e389 std::future::poll_with_tls_context::hf4d7793409e8640a + 281
4   query-engine-darwin           	0x000000010b29ff7e prisma::main::_$u7b$$u7b$closure$u7d$$u7d$::h834229e5af9fe8cc (.llvm.2251309141205072438) + 814
5   query-engine-darwin           	0x000000010b29086d _$LT$std..future..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::h03ecd98f516356aa + 45
6   query-engine-darwin           	0x000000010b2e9e3e tokio::runtime::enter::Enter::block_on::h04f3649305bad2e3 + 110
7   query-engine-darwin           	0x000000010b256bc0 tokio::runtime::thread_pool::ThreadPool::block_on::h608917198b4ecc46 + 64
8   query-engine-darwin           	0x000000010b267b24 tokio::runtime::context::enter::h341c7c7ce3d85be9 + 180
9   query-engine-darwin           	0x000000010b31aab2 tokio::runtime::handle::Handle::enter::h783938b04a1eb2bf + 258
10  query-engine-darwin           	0x000000010b27b086 prisma::main::ha25e5272c0b99b72 + 150
11  query-engine-darwin           	0x000000010b25be16 std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h81750dd2b0df955a + 6
12  query-engine-darwin           	0x000000010bbc8c58 std::panicking::try::do_call::hb5f9c52a170af65b + 24
13  query-engine-darwin           	0x000000010bbccd6f __rust_maybe_catch_panic + 31
14  query-engine-darwin           	0x000000010bbc96ae std::rt::lang_start_internal::h032b1be013493933 + 542
15  query-engine-darwin           	0x000000010b27b249 main + 41
16  query-engine-darwin           	0x000000010b20c9d4 start + 52

The 20 crash reports I have for query-engine-darwin have an identical stack for the crashed thread.

I have uploaded all crash reports for your review, including one for introspection-engine-darwin and one for migration-engine-darwin (which I don’t think will be very helpful, but who knows).

The archive also contains a copy of the working runtime and one of the faulty runtime. Hopefully you can manually checksum the last one and figure out whether it matches any of the generated runtimes you’ve produced lately… or even reproduce crashes locally 🙂

That’s it! Let me know if I can help in any way!

@olance down node to node@12 solve the problem

Oh, I had missed your Node version… from what I gathered Prisma doesn’t work with Node 14 right now, you need to downgrade to v13