Bun crashes when using Trend Micro Deep Security

[aabmets]

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?

1) Download bun.exe and place it into folder C:\bun 2) Add C:\bun to the Path variable of the System Environment Variables 3) Call bun 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?

bun add v1.1.13 (bd6a6051)
============================================================
Bun v1.1.13 (bd6a6051) Windows x64
Args: "C:\bun\bun.exe" "add" "@preact/signals-react"
Elapsed: 34ms | User: 31ms | Sys: 15ms
RSS: 52.83MB | Peak: 52.83MB | Commit: 95.59MB | Faults: 13214

panic(main thread): Segmentation fault at address 0x8

panic: Segmentation fault at address 0x8
panicked during a panic. Aborting.

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.

[Jarred-Sumner]

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?

[aabmets]

@Jarred-Sumner 1) No non-ascii chars 2) No crash report, no URL

Btw, I am connected to the internet through corporate AlwaysOnVPN, would that play any role in this error?

[paperdave]

oh wow, a double crash.

1. first there is a bug in bun install causing it to crash. could be related to the vpn, but i doubt it.
2. second, the panic handler hits while attempting to encode the crash dump. this doesn't use networking.

unfortunately, i cant reproduce this with the steps above.

maybe theres a chance it is fixed by https://github.com/oven-sh/bun/pull/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.

[aabmets]

@paperdave

Bun v1.1.16-canary (ff2080d) on windows x86_64_baseline [InstallCommand]:

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. While being logged in with regular user Active Directory account and running the bun add @preact/signals-react command in an elevated Powershell console 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?

[paperdave]

From googling TmUmEvt64.dll, it seems that's related to Trend Micro Deep Security you mentioned. I wont say for sure that this Anti-virus causes bun to mess up, but that seems to be the likely cause. Tagging this as windows-only.

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.

I have admin privileges on this computer and turning off the AV does not change the outcome.

Oh, yikes. Does the crash trace still include TmUmEvt64.dll? If so, the AV is off but still acting on Bun (and all other software). If you can get a trace that includes any of our code, that would be great.

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 ntdll.dll, which are very low level APIs. I suspect the AV, through their DLL, are patching or blocking some of these in ways that the Zig standard library does not expect. If this is the case, other zig software (including the Zig compiler) would likely crash under this.

But yeah, I'll see if i can reproduce this within this week.

[aabmets]

@paperdave

Zig works fine, at least doing basic init and build:

[aabmets]

@paperdave Tried bun version 1.1.17, the same result. Bun Report

[aabmets]

The issue persists in bun version 1.1.18. Bun Report