Bun crashes in `Bun::formatStackTrace`

KevinArce commented 2 months ago

How can we reproduce the crash?

I just ran as usual my project with Dockerfile:

# Use the official Bun Docker image
FROM oven/bun

# Create app directory
WORKDIR /usr/src/app

# Install app dependencies by copying package.json, package-lock.json, and bun.lockb
# and then running bun install. Note that if you don't have package-lock.json, you can omit it.
COPY package*.json bun.lockb ./
RUN bun install --production

# Bundle app source by copying the rest of your app's source code
COPY . .

# Build the project according to the "build" script in package.json
RUN bun run build

# Your app binds to port 8080 so you'll use the EXPOSE instruction to have it mapped by the docker daemon
EXPOSE 8080

# Define environment variable
ENV NODE_ENV production
ENV PORT 8080

# Define the command to run your app using the "start" script from your package.json
CMD [ "bun", "run", "start" ]

And this is my package.json:

{
  "name": "bun-bug",
  "version": "1.0",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "bun run --watch src/index.ts",
    "build": "bun build ./src/*.ts ./src/**/*.ts --outdir ./dist --target bun --sourcemap=external --minify",
    "start": "bun run build && bun run dist/src/index.js --watch"
  },
  "dependencies": {
    "@bogeychan/elysia-logger": "^0.0.22",
    "@elysiajs/cors": "^1.0.2",
    "@elysiajs/swagger": "^1.0.5",
    "@sentry/bun": "^8.7.0",
    "@types/luxon": "^3.4.2",
    "elysia": "^1.0.22",
    "jsonwebtoken": "^9.0.2",
    "luxon": "^3.4.4",
    "mongoose": "^8.4.1",
    "openai": "^4.47.3",
    "winston": "^3.13.0",
    "winston-daily-rotate-file": "^5.0.0"
  },
  "devDependencies": {
    "@types/jsonwebtoken": "^9.0.6",
    "bun-types": "^1.1.12"
  },
  "module": "src/index.js"
}

JavaScript/TypeScript code that reproduces the crash?

No response

Relevant log output

error: script "start" was terminated by signal SIGILL (Illegal instruction)
============================================================
Bun v1.1.12 (43f0913c) Linux x64 (baseline)
Args: "bun" "run" "start"
Features: spawn 
Elapsed: 15749ms | User: 9ms | Sys: 23ms
RSS: 1.07GB | Peak: 14.55MB | Commit: 1.07GB | Faults: 0
panic(main thread): Segmentation fault at address 0x0
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Stack Trace (bun.report)

Bun v1.1.12 (43f0913) on linux x86_64_baseline [RunCommand]

Segmentation fault at address 0x00000000

ld-temp.o:0: WTF::jscSignalHandler
??
StringImpl.h:1154: Bun::formatStackTrace
ZigGlobalObject.cpp:554: computeErrorInfoWithoutPrepareStackTrace
ZigGlobalObject.cpp:649: computeErrorInfo
Function.h:53: WTF::Detail::CallableWrapper<WTF::String (...)(...), WTF::String, JSC::VM&, WTF::Vector<JSC::StackFrame, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, unsigned int&, unsigned int&, WTF::String&, JSC::JSObject*>::call
ld-temp.o:0: JSC::ErrorInstance::computeErrorInfo
ld-temp.o:0: JSC::Heap::runEndPhase
ld-temp.o:0: JSC::Heap::runCurrentPhase
ld-temp.o:0: WTF::ScopedLambdaFunctor<void (...), JSC::Heap::collectInMutatorThread()::$_0>::implFunction

Jarred-Sumner commented 2 months ago

Can you provide the source code? Without that, we can only guess where the problem is without having a way to verify whether or not it is fixed

tapz commented 2 months ago

How do you even get the 1.1.12 image to work? For me it gives this error:

ERROR: failed to solve: process "/bin/sh -c bun install --production" did not complete successfully: exit code: 1

1.1.8 works just fine.

FROM --platform=linux/arm64 oven/bun:1.1.8-alpine

cholasimmons commented 2 months ago

Yea I had a lot of that error while deploying a test production container using bun 1.1.13.

tapz commented 2 months ago

I wonder does anybody test the containers images when a new version is released. This is not the first time the image does not work.

Jarred-Sumner commented 2 months ago

How do you even get the 1.1.12 image to work? For me it gives this error:

ERROR: failed to solve: process "/bin/sh -c bun install --production" did not complete successfully: exit code: 1

1.1.8 works just fine.

FROM --platform=linux/arm64 oven/bun:1.1.8-alpine

We do not recommend using the alpine or musl images of Bun. Bun does not support musl yet - #918. The alpine image uses glibc. Anything that uses dlopen (like Prisma) will crash when it attempts to load a musl-based image. Instead, please use the Debian slim build:

FROM --platform=linux/arm64 oven/bun

tapz commented 2 months ago

@Jarred-Sumner The Debian slim does not work any better. Version 1.1.8 is the last one, which works.

Jarred-Sumner commented 2 months ago

@tapz can you run bun install --production --verbose? That should say more information about what went wrong. Bun usually prints a lot of logs when there's an error.

tapz commented 2 months ago

@Jarred-Sumner Obviously, the verbose argument does not do anything as the bun cannot be found and even started. So something is off with the bun path in the image. Previously it was in the path and could be found, now it does not seem to be in the path.

Jarred-Sumner commented 2 months ago

@Jarred-Sumner Obviously, the verbose argument does not do anything as the bun cannot be found and even started. So something is off with the bun path in the image. Previously it was in the path and could be found, now it does not seem to be in the path.

If that were the case, the below Dockerfile would fail to run:

FROM  oven/bun
WORKDIR /usr/src/app
RUN bun --version
CMD [ "bun", "--version"]

On Linux x64 and Linux arm64, it successfully prints the version number:

tapz commented 2 months ago

But this error does get printed when running the container, but when building it. I don't understand how running bun with the install command causes this "failed to solve: process" error, but running it without does not. Is it returning some specific error code that causes this? Why doesn't it print what file it cannot find?

RUN bun install --production --verbose

RUN bun --version

tapz commented 2 months ago

I moved bun installfrom build time to run time. With verbose argument I still get only one line of logging. I have a feeling that bun simply crashes.

2024-06-14 12:30:35 bun install v1.1.13 (bd6a6051)

tapz commented 2 months ago

There were some duplicate keys in the package.json, which caused bun to output warnings. This seems to have crashed bun. After removing the duplicates, the version 1.1.13 succeeds in creating the docker image.

Jarred-Sumner commented 2 months ago

failed to solve: process

This is the generic docker error when something goes wrong, it's saying that the process exited with code 1 but the error is somewhere above in the logs

If you run bun install --production locally does it error? Is bun.lockb checked in to version control? Does it run successfully if you omit --production?

Jarred-Sumner commented 1 month ago

I think #12246 is likely to fix this

Jarred-Sumner commented 1 month ago

We still have no reproduction for this issue

If you have a way for us to reproduce it, please share so that we can fix it.

github-actions[bot] commented 1 month ago

Hello @KevinArce. Please provide a minimal reproduction using a GitHub repository, Replit, or CodeSandbox. Issues marked with needs repro will be closed if they have no activity within 3 days.

cholasimmons commented 1 month ago

We do not recommend using the alpine or musl images of Bun. Bun does not support musl yet - #918. The alpine image uses glibc. Anything that uses dlopen (like Prisma) will crash when it attempts to load a musl-based image. Instead, please use the Debian slim build:
FROM --platform=linux/arm64 oven/bun

My Elysia app uses Prisma and it fails to run since Bun 1.1.13, I've tried debian and slim distros, still the same crash.

Jarred-Sumner commented 1 month ago

@cholasimmons can you provide a reproduction we can run?

cholasimmons commented 1 month ago

@cholasimmons can you provide a reproduction we can run?

Yea you assigned @paperdave to my issue #11931. For a second today I thought it was coz I had a wrong .env value, but after fixing that and upgrading Bun to 1.1.18 I'm certain it's something to do with Bun+Prisma.

mGranTY commented 1 month ago

@Jarred-Sumner can't share the repo, but we building our code using this:

Bun v1.1.18 (5a0b9352) Linux x64

Linux Kernel v6.1.0 | glibc v2.39

Args: "bun" "dist/app.js"

Features: jsc fetch tsconfig

Builtins: "bun:main" "node:assert" "node:buffer" "node:crypto" "node:dns" "node:events" "node:fs" "node:http" "node:net" "node:os" "node:path" "node:stream" "node:string_decoder" "node:timers" "node:tls" "node:tty" "node:url" "node:util" "node:util/types" "node:zlib" "node:punycode"

Elapsed: 896ms | User: 860ms | Sys: 132ms

RSS: 2.12GB | Peak: 0.31GB | Commit: 2.12GB | Faults: 1

import * as fs from "fs";

const result = await Bun.build({
  entrypoints: ["src/app.ts"],
  minify: true,
  outdir: "dist",
  target: "bun",
  splitting: false,
  sourcemap: "external",
});

if (!result.success) {
  console.error("Build failed");
  console.timeEnd("Build");
  for (const message of result.logs) {
    console.error(message);
    process.exit(0);
  }
} else {
  console.info("Build Successful");
  fs.cpSync("assets", "dist/assets", { recursive: true });
  for (const message of result.logs) {
    console.info(message);
  }
}

and the code is running on railway with the following nixpacks.toml

[phases.setup]
nixPkgs = ['bun']
nixpkgsArchive = '166a63579d0070bf4f036726b9ac24a784d70d67'

[phases.build]
cmds = ['bun run build']

[start]
cmd = 'bun run start'

our package.json

{
  "name": "pd-api",
  "type": "module",
  "module": "src/app.ts",
  "scripts": {
    "tsc": "tsc",
    "build": "bun build.ts",
    "start": "bun dist/app.js",
    "dev": "bun run --watch src/app.ts",
    "lint": "bunx eslint --ext .tsx,.ts . --fix"
  },
  "devDependencies": {
    "@types/bun": "latest",
    "@typescript-eslint/eslint-plugin": "^7.0.2",
    "@typescript-eslint/parser": "^7.0.2",
    "eslint": "^8.57.0",
    "eslint-config-prettier": "^9.1.0",
    "eslint-plugin-prettier": "^5.1.3",
    "eslint-plugin-unused-imports": "^3.1.0",
    "prettier": "^3.2.5",
    "typescript": "5.4.5",
    "mongodb-memory-server": "^9.3.0"
  },
  "dependencies": {
    "ansi-styles": "4.3.0",
    "croner": "^8.0.0",
    "decimal.js-light": "^2.5.1",
    "dotenv": "16.0.3",
    "hono": "^3.12.9",
    "mongoose": "^7.6.2",
    "viem": "^2.16.5",
    "zod": "^3.22.4"
  }
}

mGranTY commented 1 month ago

@Jarred-Sumner can't share the repo, but we building our code using this:

Bun v1.1.18 (5a0b935) Linux x64

Linux Kernel v6.1.0 | glibc v2.39

Args: "bun" "dist/app.js"

Features: jsc fetch tsconfig

Builtins: "bun:main" "node:assert" "node:buffer" "node:crypto" "node:dns" "node:events" "node:fs" "node:http" "node:net" "node:os" "node:path" "node:stream" "node:string_decoder" "node:timers" "node:tls" "node:tty" "node:url" "node:util" "node:util/types" "node:zlib" "node:punycode"

Elapsed: 896ms | User: 860ms | Sys: 132ms

RSS: 2.12GB | Peak: 0.31GB | Commit: 2.12GB | Faults: 1

import * as fs from "fs";

const result = await Bun.build({
  entrypoints: ["src/app.ts"],
  minify: true,
  outdir: "dist",
  target: "bun",
  splitting: false,
  sourcemap: "external",
});

if (!result.success) {
  console.error("Build failed");
  console.timeEnd("Build");
  for (const message of result.logs) {
    console.error(message);
    process.exit(0);
  }
} else {
  console.info("Build Successful");
  fs.cpSync("assets", "dist/assets", { recursive: true });
  for (const message of result.logs) {
    console.info(message);
  }
}

and the code is running on railway with the following nixpacks.toml

[phases.setup]
nixPkgs = ['bun']
nixpkgsArchive = '166a63579d0070bf4f036726b9ac24a784d70d67'

[phases.build]
cmds = ['bun run build']

[start]
cmd = 'bun run start'

our package.json

{
  "name": "pd-api",
  "type": "module",
  "module": "src/app.ts",
  "scripts": {
    "tsc": "tsc",
    "build": "bun build.ts",
    "start": "bun dist/app.js",
    "dev": "bun run --watch src/app.ts",
    "lint": "bunx eslint --ext .tsx,.ts . --fix"
  },
  "devDependencies": {
    "@types/bun": "latest",
    "@typescript-eslint/eslint-plugin": "^7.0.2",
    "@typescript-eslint/parser": "^7.0.2",
    "eslint": "^8.57.0",
    "eslint-config-prettier": "^9.1.0",
    "eslint-plugin-prettier": "^5.1.3",
    "eslint-plugin-unused-imports": "^3.1.0",
    "prettier": "^3.2.5",
    "typescript": "5.4.5",
    "mongodb-memory-server": "^9.3.0"
  },
  "dependencies": {
    "ansi-styles": "4.3.0",
    "croner": "^8.0.0",
    "decimal.js-light": "^2.5.1",
    "dotenv": "16.0.3",
    "hono": "^3.12.9",
    "mongoose": "^7.6.2",
    "viem": "^2.16.5",
    "zod": "^3.22.4"
  }
}

UPDATE:

removing minify from bun build and changing the nixPkgs commit to 0d1ef1a839ce0f3282bf24bea2788b9ad659be83, fixed the issue to me.

Jarred-Sumner commented 1 month ago

@mGranTY are the contents of src/app.ts not needed to reproduce the issue? I tried on macOS arm64 and it didn't reproduce. I will now try on Linux.

mGranTY commented 1 month ago

@mGranTY are the contents of src/app.ts not needed to reproduce the issue? I tried on macOS arm64 and it didn't reproduce. I will now try on Linux.

Essentially the src/app.ts its just connection to the db like

await mongoose.connect....

Can share the repo whole repo tomorrow privately, it's bedtime here in Brazil

Jarred-Sumner commented 1 month ago

okay sounds great, would love to fix this it's just been really hard to get a way to reproduce it in a debugger

Jarred-Sumner commented 1 month ago

@mGranTY following up - would you be able to provide a repo?

mGranTY commented 1 month ago

@mGranTY following up - would you be able to provide a repo?

sent a friend request on discord, my discord name is granty._.

Jarred-Sumner commented 1 month ago

The fix for this will roll out in Bun v1.1.19 which releases later today

oven-sh / bun