A Perspective on D from game industry

[H. S. Teoh via Digitalmars-d]

On Thu, Jun 26, 2014 at 10:57:28PM +0000, Sean Kelly via Digitalmars-d wrote:
> On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
> >
> >That's why I inadvertently learned to love printf debugging. I get to
> >see the whole "chart" at one.
> 
> Yep.  A lot of this is probably because as a server programmer
> I've just gotten used to finding bugs this way as a matter of
> necessity, but in many cases I actually prefer it to interactive
> debugging.  For example, build core.demangle with -debug=trace
> and -debug=info set.

Over the years, I've come to prefer printf debugging too.

At my job I work with headless embedded systems, and interactive
debugging can only be done remotely. Unfortunately, remote debugging is
rather flaky -- gdbserver does work wonders sometimes, but due to quirky
system library setups and older system software (we don't have the
luxury of always running the latest and greatest), it works poorly when
the application in question calls fork() or is multithreaded or loads
dynamic libraries at runtime.  One especially unhelpful scenario is when
the failure happens at boot-time, before the network devices have been
initialized, so you can't even ssh into the machine to start gdbserver
-- no debugger magic will help you there!  And even in the cases where I
do manage to get gdbserver to work, all too often it's unable to match
addressees to symbols in the source tree (due to differing runtime
environments on the machine vs. my PC), so it ends up not being very
informative.

While there *are* ways of setting things up so that they will work, it's
a lot of trouble. I've since developed a crude printf-based debug
logging system which lets me insert debug() lines anywhere in the code,
and it gets printf-formatted, prefixed with the process ID, with a
simple fcntl file lock to ensure atomic output when multiple processes /
threads call debug() at the same time. Armed with this, inserting
debug() into a few strategic places does wonders -- the output goes in a
file that can be examined long after the problem has occurred (say at
boot time when the machine is inaccessible), contains PIDs that can be
used to trace exactly which instance of a program failed, reviewed at
leisure, etc..


T

-- 
It's bad luck to be superstitious. -- YHL