oven-sh / bun

Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one
https://bun.sh
Other
71.98k stars 2.57k forks source link

CPU emulator leads to strange memory issues #3312

Open dtinth opened 1 year ago

dtinth commented 1 year ago

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

Bun.serve()

(It is a minimal reproduction)

What is the expected behavior?

Bun starts a server (which does nothing).

What do you see instead?

1 | Bun.serve();
   ^
TypeError: 湕捩摯潨瑳慮敭⁳畭瑳愠牬慥祤戠湥潣敤潦⁲潮⹷渊睥唠䱒椨灮瑵⸩潨瑳慮敭猠潨汵潤琠敨琠楲正.硅数瑣摥䀠浩潰瑲琠瑳牡⁴楷桴愠猠牴湩牯甠汲⤨䠀呔⁐破⁸桷汩敲潳癬湩慰正条笧絳‧瑡✠獻
 code: "ERR_INVALID_ARG_TYPE"

      at �����������������������������������������:1:0

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.

trnxdev commented 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.

image image

trnxdev commented 1 year ago

It might have something to do with your linux version, the recommended is 5.6+ (screenshot from readme) image

Jarred-Sumner commented 1 year ago

The bug is a memory issue. The text is stack memory

Doesn't reproduce on macOS, but will try on Linux

trnxdev commented 1 year ago

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

cirospaciari commented 1 year ago

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

trnxdev commented 1 year ago

Will try with Ubuntu 20.04

Any progress on it? @cirospaciari

cirospaciari commented 1 year ago

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?

trnxdev commented 1 year ago

@dtinth

dtinth commented 1 year ago

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.
trnxdev commented 11 months ago

@cirospaciari we hit another case, any further progress with this? (^ see below)

Northernside commented 11 months ago

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

Northernside commented 11 months ago

I upgraded my Linux kernel to 6.4.0, hoping this would fix it, but unfortunately it doesn't (maybe this info helps? idk).

image
cirospaciari commented 11 months ago

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

image

OS: Debian GNU/Linux trixie/sid x86_64 Kernel: 6.3.0-1-amd64

image

OS: Ubuntu 22.04.2 LTS x86_64 Kernel: 5.19.0-43-generic

image

and the same on Debian 10

image

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.

Northernside commented 11 months ago

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

image
Northernside commented 11 months ago

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?

Jarred-Sumner commented 11 months ago

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.

Northernside commented 11 months ago

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?

image
Northernside commented 11 months ago

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!

Jarred-Sumner commented 11 months ago

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.

Northernside commented 11 months ago

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:

image

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?

Northernside commented 11 months ago

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).

Northernside commented 11 months ago

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.

Jarred-Sumner commented 11 months ago

@Northernside if you explicitly set hostname in Bun.serve does that work, by chance? I have a hunch what the cause is

Northernside commented 11 months ago

It doesn't, unfortunately.

image
pak-unyil commented 11 months ago

I fix this issue by changing VPS provider

Northernside commented 11 months ago

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.

VilleOlof commented 10 months ago

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

Jarred-Sumner commented 10 months ago

@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 commented 10 months ago

@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.

VilleOlof commented 10 months ago

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.

pacman-Syu commented 10 months ago

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.

VilleOlof commented 10 months ago

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?

dtinth commented 10 months ago

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
dtinth commented 10 months ago

@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?

VilleOlof commented 10 months ago

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.

Northernside commented 10 months ago

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

Northernside commented 10 months ago

Alright, went faster than expected.. and....!

image

Works 🥳 Switched the system to the Host CPU and installed the baseline bun version :)

pacman-Syu commented 10 months ago

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.

image

Jarred-Sumner commented 10 months ago

I wonder if it’s a CPU self-reporting AVX2 support and then not actually supporting it. That would explain most of these issues.

ItzDerock commented 10 months ago

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.

hiep1998vnhn11 commented 9 months ago

Hi, I have the same issue, but my vps provider not have the cpu type select This is my CPU info Screenshot 2023-09-22 at 11 06 29 AM

So can i use bun without change the CPU option?

Eltik commented 9 months ago

Hey is there any status on this? I seem to still have the same problem.

itpcc commented 9 months ago

Still got the same error even with Bun 1.0.4.

fhucko commented 9 months ago

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: image

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.

shidemuri commented 9 months ago

same here, not working on 1.0.4, vps cpu doesn't support avx2 and i dont have proxmox

JuanQuiro commented 9 months ago

My processor does not support AVX2. In my case it's my personal computer...

rizrmd commented 9 months ago

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.
PHOTO-2023-10-16-19-23-25

wayanjimmy commented 9 months ago

run into the same issue this morning, very sad @rizrmd I have to reconfigure my vm 😢

Jarred-Sumner commented 8 months ago

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

ahoys commented 8 months ago

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.