5 ms·
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 wor
by ahgamut 4y ago
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 :)
- mgaunard 4y agoI can launch gdb and attach it to the current process in 5 lines, hardly worth pulling a library dependency for.
- anewhnaccount2 4y agoCosmopolitan 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.
- tom_ 4y agoThis is exactly the sort of drudgery from which computers were supposed to liberate us.
- mgaunard 4y agoDepending 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.
- tom_ 4y agoImagine 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.
- ljosifov 4y ago+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.
- mgaunard 4y agomost programs are not run interactively, so dumping a core is a more sensible default.
- throwaway9870 4y agoYou want the program to hang indefinitely in production because it hit an assert?
- mickeyp 4y agoAssertions 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.
- throwaway9870 4y agoCompiling 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.
- ljosifov 4y agoSame 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.