This is awesome. Great work Bun team
Bun’s New Crash Reporter
41–50 of 91 posts
Re: Bun’s New Crash Reporter
#42Microsoft is really good at this BTW. At SQL Server we had mini dumps they were tiny stripped out of personal info and incredibly useful. And a full dump of a production SQL Server even at that time (15 years ago) would be a huge file - too big to move around.
Curious - was this for Microsoft internal services or customer deployments? If the latter, how did they know what was PII?
Possibly this was used MiniDumpFilterTriage (from https://learn.microsoft.com/en-us/windows/win32/api/minidump...) and some of other stripping/scrubbing data fields.
This one fills all non-null ptr in the callstack (and other areas?) with 0xAAAAAAAA
I actually had to fix this for us two weeks ago, as our internal tools were crashing on the CI with this, and it wasn't helpful (to us), but at the same time understand how important is for this if shipped to external customers.
Crashdumps are underrated field that needs more eyes to solve the big data problem there.
Re: Bun’s New Crash Reporter
#43This is great. Very creative. Many should copy this scheme. The key is the relative-to-executable/shared object base stack trace program counters. bun is statically linked, yes? In a dynamically linked system one would need to prefix every normalized program counter with a small numeric shared object ID.
It's not really anything new. Very common in environments where you can't ship symbols such as games crashing on player's computers.
For example, the Unreal Engine crash reporter has been capable of sending such a simple format for many years. You can restore a reasonably accurate function/line number from it for each stack frame.
Though minidump is usually preferred as having the stack variables can give additional hints to what happened.
Re: Bun’s New Crash Reporter
#44So, anybody using Bun? Does it live up to hype?
It’s super fast and nice. But I can’t bring myself to use it with anything other than side projects because of the VC funding model.
Re: Bun’s New Crash Reporter
#45So the argument for using this over a regular stack trace is that they don't have to ship megabytes of debug symbols. However they have seemingly just ignored the better option of only including function names in the debug table, which is obviously a much nicer option than having to use a web service to view you stack trace. This isn't just a theoretical solution either, it's already implemented in LLVM: https://clan…
"they have seemingly just ignored the better option...obviously much nicer" This comes off a bit presumptuous. I would assume that they are aware this is a possibility. "having to use a web service to view you stack trace" This is just not a downside that matters for this usage scenario. It's almost the same story as minifying your frontend JS bundle, uploading source maps to Sentry, then using Sentry to view an unmi…
> This comes off a bit presumptuous. I would assume that they are aware this is a possibility.
They don't present it here, they justify their solution by claiming that the existing solution is bad because it includes several megabytes of debug symbols.
Re: Bun’s New Crash Reporter
#46Bun seems really compelling. I tried it out for a couple of small example projects and I like the speed and the fact that it combines package management and a JS runtime. However, I use Dependabot on most of my serious projects. I know work is under way, or at least there is some discussion in a couple of repo issues, for Bun support in Dependabot. I'm kind of holding off on using it until support for it has been rolled out.
Re: Bun’s New Crash Reporter
#47So the argument for using this over a regular stack trace is that they don't have to ship megabytes of debug symbols. However they have seemingly just ignored the better option of only including function names in the debug table, which is obviously a much nicer option than having to use a web service to view you stack trace. This isn't just a theoretical solution either, it's already implemented in LLVM: https://clan…
"they have seemingly just ignored the better option...obviously much nicer" This comes off a bit presumptuous. I would assume that they are aware this is a possibility. "having to use a web service to view you stack trace" This is just not a downside that matters for this usage scenario. It's almost the same story as minifying your frontend JS bundle, uploading source maps to Sentry, then using Sentry to view an unmi…
> I am not bothered by having to use Sentry to view it
I am. And by source maps in general.
Re: Bun’s New Crash Reporter
#48So, anybody using Bun? Does it live up to hype?
I'm using it for my programming language (~15kLOC) as a dev and test runner and haven't had any Bun specific issues so far.
It still surprises me with its instant startup.
Re: Bun’s New Crash Reporter
#49I just cannot get excited for this VC funded experimental piece of technology. 10 years ago, maybe. Node.js is not going anywhere anytime soon.
They used to say "perl is not going anywhere", too, and it turns out they were right.
Re: Bun’s New Crash Reporter
#50Unpopular opinion …
Please use the same TLD for all your services.
Don’t do: Bun.sh, and now Bun.report
It’s confusing for users and also a security vector.
Just make it report.bun.sh