Bun’s New Crash Reporter • Hacker News Board

Re: Bun’s New Crash Reporter

#31

Post by nikita » Fri, Apr 26, 2024, 7:44 PM UTC

jallmann wrote: post #30

nikita wrote: post #19

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

I believe you had to opt in and it has some legal language before it. All the data pages were stripped and SQL Servers stores all data in the buffer pool. But of course you could find some stuff on the stack and other caches.

Re: Bun’s New Crash Reporter

#32

Post by cryptonector » Fri, Apr 26, 2024, 7:46 PM UTC

> Linux: Use dl_iterate_phdr to iterate over the loaded modules, once you find one that the raw address is contained in, .dlpi_addr on the dl_phdr_info struct will be the base address.

Er, just use `dladdr()`.

Re: Bun’s New Crash Reporter

#33

Post by verisimilidude » Fri, Apr 26, 2024, 7:48 PM UTC

vvpan wrote: post #3

So, anybody using Bun? Does it live up to hype?

The Bun libraries made it very easy to create my own static site generator. Not a huge lift, I know, but it’s been a delight to work with.

Re: Bun’s New Crash Reporter

#34

Post by cryptonector » Fri, Apr 26, 2024, 7:54 PM UTC

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

Re: Bun’s New Crash Reporter

#35

Post by Jarred » Fri, Apr 26, 2024, 8:19 PM UTC

robxorb wrote: post #29

basil-rash wrote: post #15

Earlier quoted context omitted.

It’s good unless you want a repl (they pretend to have one but it’s miserable: >6s latency all the time when it updates), or you plan to use any native modules. The error messages are also significantly worse than node’s. I used it for a bit, but node with ‘—loader tsx’ does everything I want nowadays with none of the downside. If I was building a simple server, perhaps with websockets, and I was sure it need native…

I too would use it if the REPL worked properly. JS developers are often used to working interactively - the browser/console workflow - and have come to rely on testing ideas or problems / solutions in the REPL interactively. It's efficient, as you can test and narrow things down in isolation and figure out what is working or not-working very quickly. It's also a good way to try a new module, and this is reflected in…

Currently, the REPL is an alias of `bunx bun-repl`, and bun-repl is a community-maintained npm package. We haven't had the time to do our own REPL. Honestly, we really need to hire more engineers. We're a small team and there's so much to do

Re: Bun’s New Crash Reporter

#36

Post by drewbitt » Fri, Apr 26, 2024, 8:32 PM UTC

herpderperator wrote: post #22

Bun is amazing, but I recently tried to make an http/2 server through fastify and was not able to: user@host:~/d/temp/server$ bun run index_fastify.js 14 | warned.add(feature), console.warn(new NotImplementedError(feature, issue)); 15 | }, $; 16 | 17 | class NotImplementedError extends Error { 18 | code; 19 | constructor(feature, issue) { ^ NotImplementedError: node:http2 createServer is not yet implemented in Bun. T…

That's just the status of Bun. Wait for implementations -> turns out you need more implementations of other APIs once that's done -> wait some more -> it comes out but will crash at various edge cases -> wait some more -> repeat. Bun is just too early in its lifecycle. Very hopeful for the project though!

Re: Bun’s New Crash Reporter

#37

Post by punkbit » Fri, Apr 26, 2024, 9:00 PM UTC

After years following bun, (seen first tweets about from zig) have recently started using it. Stuff just works without any hassle! Thank you

Re: Bun’s New Crash Reporter

#38

Post by ComputerGuru » Fri, Apr 26, 2024, 9:13 PM UTC

Rucadi wrote: post #4

A lot of people trash about bun, but I think that they are highly motivated people bringing a lot to the table.

Having VCs kind of forces that motivation on you, for better or worse.

Re: Bun’s New Crash Reporter

#39

Post by dzogchen » Fri, Apr 26, 2024, 9:27 PM UTC

I just cannot get excited for this VC funded experimental piece of technology. 10 years ago, maybe. Node.js is not going anywhere anytime soon.

Re: Bun’s New Crash Reporter

#40

Post by LewisJEllis » Fri, Apr 26, 2024, 9:46 PM UTC

LiamPowell wrote: post #21

So 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 unminified stack trace from a user's browser. The user was never going to view that stack trace anyway, and I am not bothered by having to use Sentry to view it - I never would have seen it at all otherwise.