'prisma db seed' command errors out with error: sigsegv sevfault on node v18.3.0 with NextJS and TS

Bug description

Upon migrating my application to a new server my node version went up from 18.1.0 to 18.3.0. Tried seeding my DB in the new server and I got the sigsegv sevfault error. No other errors besides that was given. You can reproduce this with this package.json while running node 18.3.0:

{
  "private": true,
  "scripts": {
    "dev": "next",
    "build": "next build",
    "start": "next start"
  },
  "prisma": {
    "seed": "ts-node --compiler-options {\"module\":\"CommonJS\"} prisma/seed.ts"
  },
  "dependencies": {
    "@date-io/date-fns": "^2.13.1",
    "@emotion/react": "^11.8.2",
    "@emotion/styled": "^11.8.1",
    "@material-ui/pickers": "^3.3.10",
    "@mui/lab": "^5.0.0-alpha.81",
    "@mui/material": "^5.5.0",
    "@prisma/client": "^3.12.0",
    "@stripe/react-stripe-js": "^1.7.1",
    "@stripe/stripe-js": "^1.29.0",
    "apexcharts": "^3.28.3",
    "axios": "^0.21.4",
    "bcrypt": "^5.0.1",
    "date-fns": "^2.28.0",
    "eslint": "^8.13.0",
    "final-form": "^4.20.6",
    "formik": "^2.2.9",
    "formik-mui": "^4.0.0-alpha.3",
    "js-cookie": "^3.0.1",
    "jsonwebtoken": "^8.5.1",
    "multer": "^1.4.5-lts.1",
    "next": "^12.1.5",
    "next-connect": "^0.12.2",
    "nookies": "^2.5.2",
    "nprogress": "^0.2.0",
    "pg": "^8.7.1",
    "prisma": "^3.12.0",
    "react": "^17.0.2",
    "react-accessible-accordion": "^3.3.5",
    "react-apexcharts": "^1.3.9",
    "react-bootstrap": "^1.6.1",
    "react-dom": "^17.0.2",
    "react-dropzone": "^11.4.0",
    "react-final-form": "^6.5.8",
    "react-google-charts": "^3.0.15",
    "react-gravatar": "^2.6.3",
    "react-image-lightbox": "^5.1.4",
    "react-owl-carousel3": "^2.2.5",
    "react-redux": "^7.1.0",
    "react-slick": "^0.28.1",
    "react-stripe-checkout": "^2.6.3",
    "react-swipeable-views": "^0.14.0",
    "react-toast-notifications": "^2.5.1",
    "react-visibility-sensor": "^5.1.1",
    "redux": "^3.6.0",
    "redux-devtools-extension": "^2.13.2",
    "sequelize": "^6.6.5",
    "slick-carousel": "^1.8.1",
    "stripe": "^8.174.0",
    "styled-components": "^4.1.3",
    "uuid": "^8.3.2",
    "uuid-validate": "0.0.3",
    "validator": "^13.6.0",
    "yup": "^0.32.11"
  },
  "devDependencies": {
    "@types/chance": "^1.1.3",
    "@types/node": "^17.0.21",
    "@types/react": "^17.0.40",
    "sequelize-cli": "^6.2.0",
    "ts-node": "^10.7.0",
    "typescript": "^4.6.2"
  }
}

npm list -g:
├── corepack@0.10.0
└── npm@8.8.0

After trying practically every troubleshooting option I could think of, I (unfortunately after several hours) finally downgraded my node to 18.1.0 and it seeded perfectly fine. Hope this helps someone else.

How to reproduce

1. rm -rf /node_modules && package-lock.json
2. ensure node version is 18.3.0 (node -v)
3. Run npm install --legacy-peer-deps
4. Run npx prisma db push
5. Run npx prisma db seed
6. Error should pop up.

Expected behavior

Expect prisma to seed the database without erroring out.

Prisma information

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

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


model test1{
  id Int @id @default(autoincrement())
  Type String
  Price Int
}

model test2{
  id Int @id @default(autoincrement())
  Type String
  Price Int
}

model test3{
  id Int @id @default(autoincrement())
  Type String
  Price Int
}

model test4{
  id Int @id @default(autoincrement())
  satisfied Boolean
  otherInfo String
  country String
  name String
  address String
  city String
  zipCode String
  emailAddress String
  phoneNumber String
  orderNotes String
  specialUpgradeRequests String
}

seed.ts:

import { info, lo, lu } from './staticTables';
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient;

async function main() {
    for (let r of info) {
        await prisma.test1.create({
            data: r
        })
    }
    for (let l of lo) {
        await prisma.test2.create({
            data: l
        })
    }
    for (let m of lu) {
        await prisma.test3.create({
            data: m
        })
    }
}

main().catch(e => {

    process.exit(10)
}).finally(() => {
    prisma.$disconnect()
})

Environment & setup

• OS: Rocky Linux 8
• Database: PostgreSQL 14
• Node.js version: 18.3.0 it doesn’t work. 18.1.0 it does work.

Prisma Version

prisma                  : 3.14.0
@prisma/client          : 3.14.0
Current platform        : rhel-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/libquery_engine-rhel-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/migration-engine-rhel-openssl-1.1.x)
Introspection Engine    : introspection-core 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/introspection-engine-rhel-openssl-1.1.x)
Format Binary           : prisma-fmt 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/prisma-fmt-rhel-openssl-1.1.x)
Default Engines Hash    : 2b0c12756921c891fec4f68d9444e18c7d5d4a6a
Studio                  : 0.460.0

[aqrln]

As for the original report by @maximm98 in this issue: I can reproduce it crashing with a segfault on Rocky Linux 8 x86_64 and cloud PostgreSQL 14, it looks like the same issue as https://github.com/prisma/prisma/issues/10649. What I can’t reproduce is that it was supposed to be working after downgrading Node.js to 18.1.0 — for me any Node.js version that bundles OpenSSL 3 (i.e., Node.js 17+) is broken with this setup due to the mysterious interference with system OpenSSL (see https://github.com/prisma/prisma/issues/10649#issuecomment-1247961614 for more details) that breaks the Query Engine when it’s loaded as a library.

I believe that what you encountered is an issue of the same nature, but you either might have subtle differences in your setup that might be useful and provide additional context, or might have unintentionally omitted some information from your report focusing on the Node.js version while what actually led to different behavior could have been something else. Did you switch the Node.js versions on the system that otherwise had no differences, or were these, e.g., different Docker images? Were you using the same database? Is your database self-hosted or is it a cloud offering like RDS?

As for the comments by @DenisMirandaJ: what you described in 100% consistent with https://github.com/prisma/prisma/issues/10649.

I am going to go ahead and close this issue in favor of https://github.com/prisma/prisma/issues/10649 to make it easier to keep track of it. Please post any additional details in that thread. We can reopen it if it turns out to be a different problem.

---

While we are looking for the best way to fix or prevent the underlying problem, the recommended workaround for affected users is to make sure that the versions of OpenSSL used by Node.js and the system OpenSSL match:

• either by downgrading Node.js to 16.x,
• or by upgrading the operating system (or Docker image) to use OpenSSL 3. Depending on your requirements, it might be less suitable for production systems, but this is a good option for those who only encounter the issue on their local machines during development.

Alternatively, if you can’t do that and you need to stay with Node.js 18 on a system with OpenSSL 1.1.x, you can switch to the binary engine in Prisma.

[jkomyno]

Hi @maximm98, I have tried a more accurate reproduction with prisma@3.14.0 and Postgres 14 on Rocky Linux 8, but as can be seen here, again, I wasn’t able to trigger the segmentation fault issue. Could you please update us on whether this issue is still arising on your side?