-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bun crashes when using Trend Micro Deep Security #11898
Comments
Do you have any non-ascii characters in the file path or environment variables? Was there a crash report with this or did it fail to generate the URL? |
Btw, I am connected to the internet through corporate AlwaysOnVPN, would that play any role in this error? |
oh wow, a double crash.
unfortunately, i cant reproduce this with the steps above. maybe theres a chance it is fixed by #9965, can you try downloading a canary build from here and trying that: https://github.com/oven-sh/bun/releases/download/canary/bun-windows-x64-baseline.zip Linking the baseline build instead of the main one just in case it is a AVX issue as well. |
Bun v1.1.16-canary ( Segmentation fault at address 0x00000008
- ??? at `0x31548` in ntdll.dll
- ??? at `0x31040` in ntdll.dll
- ??? at `0x30e7b` in ntdll.dll
- ??? at `0x1048` in KERNEL32.DLL
- ??? at `0x395f6` in TmUmEvt64.dll
- ??? at `0x72ba8` in TmUmEvt64.dll
- ??? at `0x2b957` in TmUmEvt64.dll
- ??? at `0x310bd` in TmUmEvt64.dll
- ??? at `0x796f4` in TmUmEvt64.dll
- ??? at `0x40595` in TmUmEvt64.dll
<!-- from bun.report: I-BBsA4Ftcwcmi34ZV7o --> EDIT: This command is run on a corporate laptop with Trend Micro Deep Security installed. This laptop also has a Group Policy present, which forbids the execution of any binary from the users personal folder and from within their AppData folder (on Windows). I have admin privileges on this computer and turning off the AV does not change the outcome. Logging in with the admin acount and running the same command again also does not change account. I'm not entirely sure, this is purely based on a feeling, but maybe the issue is with how bun is compiled for windows platforms? Maybe, for whatever odd reasons, the binary that is produced is incompatible with the machine that I am using? I believe this, because if I'm not mistaken, bun uses AVX instructions and parallelized pipelines to speed up the dependency download process. Maybe this is an edge case scenario with an obscure bug in the parallelization pipeline? EDIT: I don't know if it's relevant, but this machine has AppLocker enabled. Since AppLocker encrypts all files on-the-fly, maybe it conflicts with the usage of AVX instructions in the bun executable? |
From googling Annoying for me because the only stack trace we have now is exclusively within their code. This gives me essentially nothing to work off of. Later I'll see if I can run a trial of their AV to see if I reproduce issues with it.
Oh, yikes. Does the crash trace still include The baseline build does not have AVX instructions, however simdutf8 will do per-platform detection to disable/enable that depending on the CPU. I doubt that is an issue, unless something on your computer is lying about your CPU model (Certain cloud hosting / virtual machine software may do this) What I worry about is that the Zig standard library has many calls into But yeah, I'll see if i can reproduce this within this week. |
Zig works fine, at least doing basic init and build: |
What version of Bun is running?
1.1.13
What platform is your computer?
Microsoft Windows NT 10.0.19044.0 x64
What steps can reproduce the bug?
C:\bun
C:\bun
to the Path variable of the System Environment Variablesbun add @preact/signals-react
or any other library.What is the expected behavior?
Install the library without exploding in a fiery crash.
What do you see instead?
Additional information
I'm not a specialist on this matter, but it seems to me, that this issue is caused by incorrect logic in an error handler. Why else would it panic during a panic? That indicates a new error being raised in the catch block and the code expects anything that is in the catch block to succeed, but clearly it is not succeeding and there isn't a branch to account for the error handler not succeeding.
The text was updated successfully, but these errors were encountered: