Open dtinth opened 1 year ago
Can you change the name to something like "TypeError: Random symbols when calling Bun.serve()", it looks very weird and takes up too much space.
It might have something to do with your linux version, the recommended is 5.6+ (screenshot from readme)
The bug is a memory issue. The text is stack memory
Doesn't reproduce on macOS, but will try on Linux
The bug is a memory issue. The text is stack memory
Doesn't reproduce on macOS, but will try on Linux
I tried it on a recent version of linux, it just doesn't do anything. no output (just keeps it alive) my linux version: Linux tiramifybox 6.3.6-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC x86_64 GNU/Linux
The bug is a memory issue. The text is stack memory
Doesn't reproduce on macOS, but will try on Linux
on Debian 10 Kernel 4.19.0-24-amd64 and on Debian 12 Kernel 6.1.0-9-amd64, got no error, just keep the process alive because the server is alive on port 3000. Will try with Ubuntu 20.04
Will try with Ubuntu 20.04
Any progress on it? @cirospaciari
We a
Will try with Ubuntu 20.04
Any progress on it? @cirospaciari
We added better validation on Bun.serve
this probably solves the issue, can you check on the latest canary to see if it is solved?
@dtinth
Still error, but error message is now shorter:
$ wget https://github.com/oven-sh/bun/releases/download/canary/bun-linux-x64.zip
$ unzip bun-linux-x64.zip
$ ./bun-linux-x64/bun bug.js
1 | Bun.serve();
^
TypeError: 畂敳癲硥数瑣湡漠橢捥t慔扲污䙬楡敬呤䕯瑸慲瑣椀慭
code: "ERR_INVALID_ARG_TYPE"
at �����������������������������������������:1:0
$ ./bun-linux-x64/bun bug.js 2>&1 | xxd
00000000: 3120 7c20 4275 6e2e 7365 7276 6528 293b 1 | Bun.serve();
00000010: 0a20 2020 5e0a 5479 7065 4572 726f 723a . ^.TypeError:
00000020: 20e7 9582 e2b9 aee6 95b3 e799 b2e2 81a5 ...............
00000030: e7a1 a5e6 95b0 e791 a3e2 81b3 e6b9 a1e6 ................
00000040: bca0 e6a9 a2e6 8da5 74e6 8594 e689 b2e6 ........t.......
00000050: b1a1 e499 ace6 a5a1 e695 ace5 91a4 e495 ................
00000060: afe7 91b8 e685 b2e7 91a3 e6a4 80e6 85ad ................
00000070: 0a20 636f 6465 3a20 2245 5252 5f49 4e56 . code: "ERR_INV
00000080: 414c 4944 5f41 5247 5f54 5950 4522 0a0a ALID_ARG_TYPE"..
00000090: 2020 2020 2020 6174 2000 0000 0000 0000 at .......
000000a0: 00aa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................
000000b0: aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................
000000c0: aaaa aaaa aaaa aaaa aaaa 3a31 3a30 0a ..........:1:0.
@cirospaciari we hit another case, any further progress with this? (^ see below)
Also happening on my end (since bun 0.7.0)
Linux 5.10.0-23-amd64 x86_64 unknown bun 0.7.1 (e110ccf8) (With OP's attached reproduction)
bun kartoffel.js 2>&1 | xxd
:
https://paste.laby.net/gapavecusi.makefile
I upgraded my Linux kernel to 6.4.0, hoping this would fix it, but unfortunately it doesn't (maybe this info helps? idk).
Still not able to reproduce, @Northernside can you share more info about your system like processor name etc?
Some systems I tried:
OS: macOS 13.3 22E252 arm64 Kernel: 22.4.0
OS: Debian GNU/Linux trixie/sid x86_64 Kernel: 6.3.0-1-amd64
OS: Ubuntu 22.04.2 LTS x86_64 Kernel: 5.19.0-43-generic
and the same on Debian 10
basically, this is the expected behavior for Bun.serve()
if you do not pass any object as an option. But not able to see the same broken text, looks like a memory issue.
It didn't occur on my macOS (Sonoma, latest beta) but it does on my VPS hosted by Dashserv (German hoster).
My VPS runs under Qemu (at least that's what I believe?) so all hardware outputs tell some weird ass things, but anyway:
https://paste.laby.net/marupohehi.m (sudo lshw
)
https://paste.laby.net/bukelaboti.cs (sudo lshw -short
)
https://paste.laby.net/bisewahefo.sql (sudo lscpu
)
According to my hoster, the CPU is an AMD Epyc 7443 4Ghz
Also, I can give you full SSH access to my system on which it's bugging out lol - maybe this can help you debug stuff quicker?
The original bug was caused by incorrect arguments type checking in Bun.serve()
and has since been fixed (as of Bun v0.6.11 or so).
The error @Northernside is seeing appears to be due to using bun-linux-x64 when the machine should be using bun-linux-x64-baseline. Bun's install script is meant to auto-detect this, but if installed through Docker or on a machine which does support avx2, it will install the wrong choice. @Northernside please use the .tar.gz from https://github.com/oven-sh/bun/releases/download/bun-${version}/bun-linux-x64-baseline.zip instead of https://github.com/oven-sh/bun/releases/download/bun-${version}/bun-linux-x64.zip. In the future, we will make this work better to not need this step.
Sorry to bother you again, I don't know if I did something wrong, or not, but even when switching to -baseline
, this issue still exists 👀
I made it so that it'll always grab the baseline archive in the installer (that's why I did the grep output, don't get confused).
Did I forget/do something wrong?
Any updates on this? I wanted to note again that this only occurs since 0.7.0 (it all works perfectly fine in 0.6.9!) and it prevents me from being able to update & use newer versions and features. No pressure of course, don't worry!
Any updates on this? I wanted to note again that this only occurs since 0.7.0 (it all works perfectly fine in 0.6.9!) and it prevents me from being able to update & use newer versions and features. No pressure of course, don't worry!
Does this happen for any call to Bun.serve() or specifically ones with invalid arguments (eg Bun.serve()
or Bun.serve(Symbol())`)
It’s very confusing why this could still be happening and why it doesn’t seem to reproduce on any hardware I’ve tried.
Does this happen for any call to Bun.serve() or specifically ones with invalid arguments (eg Bun.serve() or Bun.serve(Symbol())`)
Seems like it does happen on every Bun.serve()
call:
It’s very confusing why this could still be happening and why it doesn’t seem to reproduce on any hardware I’ve tried.
I'm still up for giving you SSH access to my VPS with the affected hardware so that you can test/debug things etc. What could have changed from 0.6.9 -> 0.7.0 that caused this?
I know, I know, this might annoy you, but are you up to testing/debugging it with my hardware? I want to be able to use the newer versions of bun because they also fix a lot of issues which I'm currently experiencing on 0.6.9 (e.g. a LOT of segfaults and compatibility issues).
Oh btw I have to correct myself, it's not from 0.6.9 -> 0.7.0 but from 0.6.9 -> 0.6.10 when this issue started occurring.
@Northernside if you explicitly set hostname
in Bun.serve does that work, by chance? I have a hunch what the cause is
It doesn't, unfortunately.
I fix this issue by changing VPS provider
Yeah this makes sense because they probably use hardware which doesn't trigger this thing lol, but I don't see this as a valid "fix" for my case.
I recently also got this exact problem. Running on Ubuntu Linux 5.4.0-153-generic x86_64
const server = Bun.serve({
port: 2010,
async fetch(req) {
return await HandleRequest(req);
},
});
But all i get is
$ bun run src/index.ts
[0.03ms] ".env"
19 |
20 | return response;
21 | }
22 |
23 | export function StartServer() {
24 | const server = Bun.serve({
^
TypeError: 湕捩摯潨瑳慮敭畭瑳愠牬慥祤戠湥潣敤潦潮渊睥唠䱒椨灮瑵⸩潨瑳慮敭猠潨汵潤琠敨琠楲正.湉整湲污挠湯楳瑳湥祣攠牲牯›慷捴敨畭整⁸獩氠捯敫桷湥椠⁴桳畯摬渠瑯戠䤀呎㐶呟彏半䅖啌⡅半
code: "ERR_INVALID_ARG_TYPE"
at StartServer (/src/server.ts:24:19)
at /src/index.ts:6:0
error: script "start" exited with code 1 (SIGHUP)
While developing i had it running fine in WSL and just got this while trying to deploy it
@VilleOlof random idea, what if you try putting the folder one level deeper in a directory? instead of /src/index.ts
/app/src/index.ts
?
@VilleOlof random idea, what if you try putting the folder one level deeper in a directory? instead of
/src/index.ts
/app/src/index.ts
?
Yeahh noopee, sadly not. Exact same error. Nothing changed. Tried nesting only index.ts and then the entire src directory.
Might also give all the information that i know to help anything. Have been running Bun on two other servers and running fine. similar OS configurations.
Annoying that it works fine in WSL with a kernel version thats older than the VM ive been running Bun and getting these memory issues in. The Ubuntu 20.04.5 VM thats been causing these are running in Proxmox. Also messed around with some bun cli to get it to work. Tried compiling to an executable. Didnt work, Complained about some root file not being present or something weird.
The program didnt however did work to compile and run in WSL (yet again). Also tried --smol flag and stuff. But to no avail. This is the last hurdle i've could have gotten to deploying this. VM has been on latest bun release (0.8.1) While my WSL on some older (0.6.12). Would like to try and downgrade the servers Bun version but i am clueless on how on that.
Update: i updated my ubuntu version to 22, updated kernel to 6.5.1. tried bun canary and yet nothing. Currently feels like its somehow the underlying hardware thats causing the problem for bun. The ram is ECC Ram i believe, if that changes anything.
Might also give all the information that i know to help anything. Have been running Bun on two other servers and running fine. similar OS configurations.
Annoying that it works fine in WSL with a kernel version thats older than the VM ive been running Bun and getting these memory issues in. The Ubuntu 20.04.5 VM thats been causing these are running in Proxmox. Also messed around with some bun cli to get it to work. Tried compiling to an executable. Didnt work, Complained about some root file not being present or something weird.
The program didnt however did work to compile and run in WSL (yet again). Also tried --smol flag and stuff. But to no avail. This is the last hurdle i've could have gotten to deploying this. VM has been on latest bun release (0.8.1) While my WSL on some older (0.6.12). Would like to try and downgrade the servers Bun version but i am clueless on how on that.
Update: i updated my ubuntu version to 22, updated kernel to 6.5.1. tried bun canary and yet nothing. Currently feels like its somehow the underlying hardware thats causing the problem for bun. The ram is ECC Ram i believe, if that changes anything.
I was experiencing the same issue running an ubuntu 22.04 vm on proxmox. This seems to be an issued with the cpu. When the vm is configured to use the 'host', bun.serve works as expected.
I was experiencing the same issue running an ubuntu 22.04 vm on proxmox. This seems to be an issued with the cpu. When the vm is configured to use the 'host', bun.serve works as expected.
Use "host"? I'm not that deep into proxmox stuff and i dont suspect its "hostname" in bun.serve you're talking about?
I tested again with Bun v1.0.0.
Still same error message but the stack trace is now correct.
# ./bun --version
1.0.0
# ./bun repro.js
1 | Bun.serve();
^
TypeError: 畂敳癲硥数瑣湡漠橢捥t慔扲污䙬楡敬呤䕯瑸慲瑣椀慭
code: "ERR_INVALID_ARG_TYPE"
at vol_sgp1_01/lab/bun-linux-x64/repro.js:1:0
Edit: Using the -baseline
version works now.
# ./bun repro.js
1 | Bun.serve();
^
TypeError: Bun.serve expects an object
code: "ERR_INVALID_ARG_TYPE"
at /mnt/vol_sgp1_01/lab/bun-linux-x64-baseline/repro.js:1:0
@Northernside Can you try the -baseline
version of Bun and see if it works on your side?
BTW, I looked in the documentation and it was not documented anywhere why there has to be a "baseline" version vs non-baseline version.
However, looking at the installation script reveals this:
# If AVX2 isn't supported, use the -baseline build
if [[ $(cat /proc/cpuinfo | grep avx2) = '' ]]; then
target=linux-x64-baseline
fi
Does it mean that when building a Docker image based on Bun, we should prefer the "baseline" build to maximize compatibility although it might slow down execution? Or is it recommended to ship both versions of Bun and at runtime (i.e. in an entrypoint script) decide which binary should be used?
I Finally got it to work once i switched the CPU type to "host" in proxmox hardware settings for this specific VM. I did try to switch to baseline as well. But that didnt even work for me.
I'm out in the forest right now lol I'll see when I can get back to my laptop. I have it carrying out here but it's out of power 😭 Will probably be able to test it in about half an hour
Alright, went faster than expected.. and....!
Works 🥳 Switched the system to the Host CPU and installed the baseline bun version :)
I was experiencing the same issue running an ubuntu 22.04 vm on proxmox. This seems to be an issued with the cpu. When the vm is configured to use the 'host', bun.serve works as expected.
Use "host"? I'm not that deep into proxmox stuff and i dont suspect its "hostname" in bun.serve you're talking about?
Try setting the cpu type of the vm to host. This can be found in the hardware configuration of the vm.
I wonder if it’s a CPU self-reporting AVX2 support and then not actually supporting it. That would explain most of these issues.
I wonder if it’s a CPU self-reporting AVX2 support and then not actually supporting it. That would explain most of these issues.
running grep avx2 /proc/cpuinfo
yields no results, so it looks like the cpu isn't reporting avx2 support.
I Finally got it to work once i switched the CPU type to "host" in proxmox hardware settings for this specific VM. I did try to switch to baseline as well. But that didnt even work for me.
this worked for me too, after this change, grep avx2 /proc/cpuinfo
shows that the CPU is reporting avx2 support now.
Hi, I have the same issue, but my vps provider not have the cpu type select This is my CPU info
So can i use bun without change the CPU option?
Hey is there any status on this? I seem to still have the same problem.
Still got the same error even with Bun 1.0.4.
Same issue on Debian 10. Reinstalled OS to Debian 12, still same issue. It is on virtual server. I tried to fix my problem by switching to expressjs, but it seems to have same result:
I switched to Linode becaue of this, it works there.
Btw thank you for making Bun. I also tried Deno, but Bun seems to be much more user friendly.
same here, not working on 1.0.4, vps cpu doesn't support avx2 and i dont have proxmox
My processor does not support AVX2. In my case it's my personal computer...
Thank god this issue exists. I spent entire day looking for this. This is default Proxmox setting. Notice the Type: Default (kvm64). You should change that to Host.
run into the same issue this morning, very sad @rizrmd I have to reconfigure my vm 😢
Edited the original question to show the solution. We are blocked on function multi-versioning until Zig implements that. Until then, downloading & installing bun using bun’s install script inside the machine itself is the best approach and otherwise installing bun-profile manually when not.
We’ve also added a warning on start to bun when using an AVX2 build of bun on a machine that lacks support. I don’t think there’s further action here so I’m closing it, but please leave a comment if what needs to be done is unclear
Is there a list of the required instruction sets for Bun available? Installing using the default installation script shown in the manual did not mention anything about the missing sets. I'm suspecting it will cause plenty of confusion in the future, especially as the error is as cryptic as it is.
The solution
edited
Download the build of Bun with “baseline” in the name
https://github.com/oven-sh/bun/releases/latest/download/bun-linux-x64-baseline.zip
if using Proxmor, follow this screenshot
Original issue:
What version of Bun is running?
0.6.9
What platform is your computer?
Linux 5.4.0-45-generic x86_64 x86_64
What steps can reproduce the bug?
repro.js
(It is a minimal reproduction)
What is the expected behavior?
Bun starts a server (which does nothing).
What do you see instead?
Additional information
The repro above is just for testing. I ran into this error while trying to run an actual app inside a Docker container.
I went ahead and downloaded https://github.com/oven-sh/bun/releases/download/bun-v0.6.9/bun-linux-x64.zip and run it outside the Docker container and get the same error and reduced the code to the above repro script. The host OS is Ubuntu 20.04.