Our great sponsors
-
Crashlogs
A simple way to output stack traces when a program crashes in C++, using the new C++23 <stacktrace> header
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
libunwind
Mirror of official LLVM libunwind git repository located at http://llvm.org/git/libunwind. Updated every five minutes. http://llvm.org
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I found Sentry's crash reporting (which uses crashpad) simple enough to configure into an existing CMake build within an afternoon.
Building Sentry/crashpad from source in a few lines of CMake: https://github.com/ArmageddonGames/ZQuestClassic/commit/3471...
And a few lines in the main function: https://github.com/ArmageddonGames/ZQuestClassic/commit/3471...
Neat, I didn't know Sentry also had a good fork, I haven't tried it! But in contrast, here's an in-process fault library that I whipped up (from forking Phusion Passenger) about 10 years ago that I still reach for sometimes, which is surprisingly robust to most of the original complaints about async safety, but still not perfect: https://github.com/thoughtpolice/libfault
You add one C file and 6 lines of code in `main()`, and you can do this in pretty much any programming language with a tiny extra bit of glue. It takes 3 minutes to do this in any C/C++ codebase of mine. It is build system agnostic and works immediately, with zero outside deps. It's something, and that's better than nothing, in practice. So people reach for that. I reach for it. And not just because I wrote it.
I want to be clear: Crashpad is 10000x better than mine in every way, except this one way. And I really wish it wasn't. To add onto this, I really don't like CMake for example, so this problem isn't just a "well I like my thing." I want something that will also work in my Java programs, or Rust programs, for instance! Sometimes they crash too. I don't need to add any dependencies except like 2 or 3 C function calls, which almost every langauge supports with a native FFI out of the box.
I'm reminded of something Yann Collet once said about the design of zstd, and getting people to adopt new compression technology. If you make a compressor and it's better than an alternative in one or more dimensions, but worse in another (size, decompressor speed), then friction is actually significantly increased by that one failure. But if you make it better in every dimension -- so it gives an equal ratio and compression and decompression are always better than alternatives -- the friction is eliminated and people will just reach for it. Even though you only did worse in one spot, people find ways to make it matter.
So that's what I really wish we had here. There needs to be a version of Crashpad, or any robust out of process crash collector, that you can just drop into any language and any build system with a little C glue (or Rust! Sure! Whatever!) in 5 minutes and it should have a crash database server and crash handler process which should instantly work for most uses.
https://github.com/ClickHouse/libunwind/
There were multiple steps:
1. Avoid using malloc/free inside libunwind.
2. Avoid using FDECache that required a mutex.
3. Avoid using dl_iterate_phdr (a mutex inside libc).
4. Protection from dereferencing wrong pointers due to incorrect unwind tables.
Most of the changes were integrated to libunwind, but not everything.
If you don't care about exotica like async or signal safety, and just need to see the callstack from arbitray points, this can do the job without C++23:
https://github.com/Ardour/ardour/blob/master/libs/pbd/stackt...
(2 different implementations, one for POSIX-y systems with the execinfo.h header, and one for Windows)
The demange() function is elsewhere.