99056 segmentation fault (core dumped) node --require esbuild-register prisma/seed.ts

[sergiotapia]

Bug description

I'm following the Remix joke tutorial app and in this part with the seeds file, I get a seg fault.

[1] 99056 segmentation fault (core dumped) node --require esbuild-register prisma/seed.ts

import { PrismaClient } from "@prisma/client";
const db = new PrismaClient();

async function seed() {
  console.log("Hello");
  const joke = await db.joke.create({
    data: {
      name: "Some joke",
      content: "Funny ha ha!",
    },
  });

  console.log(joke);
}

seed();

The output is:

➜  remix-jokes git:(master) ✗ node --require esbuild-register prisma/seed.ts
Hello
[1]    99264 segmentation fault (core dumped)  node --require esbuild-register prisma/seed.ts

Appreciate any tips!

How to reproduce

Run the command in the output.

node --require esbuild-register prisma/seed.ts

Expected behavior

Should run the script.

Prisma information

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Joke {
  id        String   @id @default(uuid())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  name      String
  content   String
}

Environment & setup

• OS: Linux Mint
• Database: Postgres
• Node.js version: v18.10.0

Prisma Version

➜  remix-jokes git:(master) ✗ npx prisma -v
Environment variables loaded from .env
prisma                  : 4.12.0
@prisma/client          : 4.12.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 659ef412370fa3b41cd7bf6e94587c1dfb7f67e7 (at node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli 659ef412370fa3b41cd7bf6e94587c1dfb7f67e7 (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Format Wasm             : @prisma/prisma-fmt-wasm 4.12.0-67.659ef412370fa3b41cd7bf6e94587c1dfb7f67e7
Default Engines Hash    : 659ef412370fa3b41cd7bf6e94587c1dfb7f67e7
Studio                  : 0.483.0

[roxxel]

Try using binary engine

generator client {
  provider = "prisma-client-js"
  engineType = "binary"
}

then

npx prisma db push

[sergiotapia]

That worked thank you @roxxel! I wonder what this does though and why it fixed the bug.

[janpio]

@aqrln can explain this one. We are working on a fix and currently testing it already.

[aqrln]

@sergiotapia Prisma relies on system OpenSSL library, which in your case is OpenSSL 1.1. So we download the Query Engine library (Node.js addon) and the Migration Engine binary compatible with OpenSSL 1.1. However, when the Node.js addon is dynamically loaded, the symbols are resolved by the dynamic linker to point at the functions from OpenSSL 3 bundled with Node.js, and the system OpenSSL is ignored. This leads to problems because OpenSSL 1.1 and OpenSSL 3 aren't compatible.

This doesn't happen when using engineType = "binary" because it's a standalone process. This also doesn't happen when using distros with newer OpenSSL versions, or when using Node.js 16 on distros with OpenSSL 1.1, because the system OpenSSL and the one that Node.js is using are compatible in those cases. And, of course, this doesn't happen when OpenSSL isn't used because the connection to the database is unencrypted: we've mainly seen this bug affect people using databases deployed in cloud (such as AWS RDS) since those are typically configured to use TLS by default.

As @janpio said above, we have a fix for this and are currently testing it.

[sergiotapia]

Thanks for the in depth explanation! You guys are fantastic

[aqrln]

This issue is fixed in Prisma 4.13.0 which will be released tomorrow, on Tuesday, Apr 18. If you need to temporarily use a pre-release version until then, you can use 4.13.0-dev.33.

---

For future readers:

Note that this GitHub issue is about a specific bug that occurs when using Node.js 17+ on a system with OpenSSL 1.1 on x86-64 CPUs when using TLS to connect to database. Please do not post comments here if you encounter a segfault under different circumstances, and open a new issue instead.

If you are facing segfaults on ARM, please leave a comment in #18510 or open a new issue.