A Perspective on D from game industry

[H. S. Teoh via Digitalmars-d]

On Fri, Jun 27, 2014 at 03:36:08PM -0400, Nick Sabalausky via Digitalmars-d wrote:
> On 6/26/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Thu, Jun 26, 2014 at 09:16:27PM -0400, Nick Sabalausky via Digitalmars-d wrote:
> >[...]
> >>Aye. Sometimes in embedded work, you're *lucky* if you can even do
> >>printf at all, let alone a debugger. I've had to debug with as
> >>little as one LED.  It's...umm..."interesting". And time consuming.
> >>Especially when it's ASM.  (But somewhat of a proud-yet-twisted rite
> >>of passage though ;) )
> >
> >Reminds me of time I hacked an old Apple II game's copy protection by
> >using a disk editor and writing in the instruction opcodes directly.
> >:-)
> >
> 
> Cool. I once tried to hack a game I'd bought to change/remove the part
> where it took my name directly from the payment method and displayed
> that it was registered to "Nicolas" instead of "Nick" in big bold
> letters on the title screen. I didn't quite get that adjusted, but I
> did wind up with a tool (in D) to pack/unpack the game's resource file
> format.

Heh, nice! :)

On another note, something more recent that I'm quite proud of, was to
fix a bug that I couldn't reproduce locally, for which the only
information I have was the segfault stacktrace the customer gave in the
bug report (which had no symbols resolved, btw, just raw hex addresses).
I looked up the exact firmware build number he was using, and got myself
a copy of the binary from the official release firmware FTP server. Of
course, that didn't have any symbols either (it's a release build), but
at least the addresses on the stacktrace matched up with the addresses
in the disassembly of the binary. So I had to check out the precise
revision of the source tree used to make that build from revision
control, build it with symbols, then match up the function addresses so
that I could identify them. However, the last few frames on the
stacktrace are static functions, which have no symbols in the binary
even in my build, so I had to trace through the stacktrace by comparing
the disassembly with the source code to find the offending function,
then find the offending line by tracing through the disassembly and
matching it up with the source code, up to the point of the segfault.
Once I found the exact source line, the register values on the
stacktrace indicated that it was a null dereference, so I worked
backwards, in the source code now, until I identified the exact variable
corresponding to the register that held the NULL pointer (the compiler's
optimizer shuffled the variable around between RAM and various registers
as the function progressed, so all of that had to be unravelled before
the exact variable could be identified). After that, I could resume the
regular routine of tracing the paths through which the NULL could have
come.

You have no idea how awesome it felt when my test image (which I
couldn't test locally since I couldn't reproduce the bug), installed on
the customer's backup test environment, worked the first time.


T

-- 
Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine