A Philosophy of Software Design

[H. S. Teoh]

On Thu, May 28, 2026 at 08:50:57PM +0000, Basile B. via Digitalmars-d wrote:
> On Sunday, 24 May 2026 at 17:15:12 UTC, Zz wrote:
[...]
> > https://rm4n0s.github.io/posts/3-error-handling-challenge/
> > 
> > Zz
> 
> That's a good challenge, really. The problem I have with that however
> is very simple. Why the heck do you need a stack trace at runtime ? If
> you need a stack trace then it's probably cuz you have encountered a
> serious bug.  Time to run the software in gdb you see.
[...]

Running the program in gdb is a luxury you don't always have.  I've had
to fix segfault bugs that happen only in a customer's production
environment, so (1) gdb access is not an option, not even remotely (this
is running on embedded hardware); (2) the problem is not reproducible in
my dev environment; (3) the customer is using a release build, so no
symbols, only stack addresses and register contents at the time of the
segfault; (4) the customer cannot run a custom debug build with debug
hooks because this is a live production environment.

Having a stack trace enabled me to trace the location of the crash
(build the exact version the customer is running, map hex addresses to
the disassembly of the executable in my build, trace through the
assembly and map it back to the source code, then trace the code back up
the chain of callers to determine where the bad value came from).
Without that information, the bug would've remained open till this day.


T

-- 
There are two types of idiots. One type says "this is old and therefore bad", the other type says "this is new and therefore better". Beware of individuals who fall under both types. -- Crivens