Hacker News Reader

Comment by mgaunard | Hacker News Reader

What's the advantage over calling gdb yourself?

You run the executable as usual, and if it crashes, Cosmopolitan Libc's crash handler starts gdb for you with a nice TUI and all the information you need to work with. Probably you could set up a bunch of macros in your editor that do the same thing (and I do have something like that for godbolt compiler explorer), but for gdb at least it's pretty convenient to have it performed by the executable when running it across systems. You can start gdb by yourself too if you have a workflow setup like that :)

I can launch gdb and attach it to the current process in 5 lines, hardly worth pulling a library dependency for.

Cosmopolitan is a replacement standard library. It's not so much "pulling-in" a library as replacing e.g. glibc. The point of the blog post is that it's a libc but also a batteries included C development environment. On the one hand, it's nothing magic, on the other hand, it does have some nice concordances which are worth showing off.

This is exactly the sort of drudgery from which computers were supposed to liberate us.

Depending on any third-party software is a huge liability for any professional software development.

Dependencies must be chosen and managed carefully. I'm not going to depend on something for something that's trivial; the time it takes for me to write it is less than it takes to do a license review and integrate it into my build system.

Imagine if liberating one from drudgery were merely table stakes, and that it would be ridiculous to imagine that you would have to go to any effort to have the debugger pop up when shit fucks up.

+1. I have had my ASSERT defined to 1) signal the program to pause it, 2) start gdb (or ddd), 3) attach to the pid, 4) tell gdb what the binary is, 5) wait on me most of my programming life. No idea why this is not the default.

most programs are not run interactively, so dumping a core is a more sensible default.

You want the program to hang indefinitely in production because it hit an assert?

Assertions are compiled out of 'production' (non-debug) builds.

The same holds true of Python if you run it with the optimize flag/environment variable, leading to any number of hilarious bugs because people cause side-effects in their assert calls.

Compiling out assertions in production is like taking your seat belt off when you leave the driveway. Seriously, in my experience, all the interesting stuff happens in production. We deploy two builds, app.debug and app.release. We run generally run app.debug unless there are performance issues, but even in that case, we sometimes run it just to make sure nothing shows up.

Same here. And it's insignificant cost to have a terminal attached to the process. So instead a mere stack trace and local vars on the stack in the core dump, I actually have the entire process, the heap with all the objects, all file descriptorsabd various OS handles and state, to interrogate. The program would have been running many hours, sometimes days, up to this point. Why would anyone throw all that valuable info away by default.

You want your program to continue executing in an undefined, probably erroneous, possibly destructive state because you ignored an error?

What do you you think the default behavior of an assert is? If you are turning them off, then you get what you describe, which is not what I am advocating.

And this isn't theoretical. I've seen ignored errors do damage in the past. Was infuriating to see that we had set a top-level exception handler in our server that just logged and kept going. We had a couple tables in our database trashed because of that and ended up having to restore from the nightly backup, losing everything that was changed that day.

Of course - crash, hang, core dump, whatever, just do NOT continue as if nothing happened. My programs are in control of much $$$, I would be horrified if a program was to continue running in undefined state. Errors and warnings are issued and handled by operations - that's part of the program logic. But if an assert is triggered then all bets are off, best to stop 99.9% of the time.

Sometimes the binary I am trying to debug is nested within several layers of crap. I have written shims before to attach gdb to the running process so that I don't need to try and wrangle gdb through shell scripts.

Reply on news.ycombinator.com