Closed KevinArce closed 1 month 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
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
Yea I had a lot of that error while deploying a test production container using bun 1.1.13.
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.
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
@Jarred-Sumner The Debian slim does not work any better. Version 1.1.8 is the last one, which works.
@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.
@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 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:
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
I moved bun install
from 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)
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.
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
?
I think #12246 is likely to fix this
If you have a way for us to reproduce it, please share so that we can fix it.
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.
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.
@cholasimmons can you provide a reproduction we can run?
@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.
@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"
}
}
@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.
@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 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
okay sounds great, would love to fix this it's just been really hard to get a way to reproduce it in a debugger
@mGranTY following up - would you be able to provide a repo?
@mGranTY following up - would you be able to provide a repo?
sent a friend request on discord, my discord name is granty._.
The fix for this will roll out in Bun v1.1.19 which releases later today
How can we reproduce the crash?
I just ran as usual my project with Dockerfile:
And this is my package.json:
JavaScript/TypeScript code that reproduces the crash?
No response
Relevant log output
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