Hacker News Reader

Comment by exmadscientist | Hacker News Reader

My favorite hack along these lines was to put a timer/ISR on an embedded system that did nothing more than crawl up the stack frame the two or three addresses that the ISR used (yep, it was really just as dumb as [sp + 8] or whatever), and then dump that address to the serial terminal every second or so.

You can fix a lot of stupid problems that way. (And most problems are stupid.) Yes, yes, a real profiler would be better, but if you don't have the fancy tools because your employer doesn't buy you such things, and it's a primitive and cruddy embedded system so there's no obvious better way to do it, and you built this horrible hack right now and... hey, the hack solved the problem, and what do you know? it keeps on solving things....

View on HN

> Yes, yes, a real profiler would be better

As someone who wrote several profilers for a living... that is a real profiler.

only once you pipe the output to sort | uniq -c

It's amusing; your 2nd paragraph drives at the core of the programmer experience - having to disclaim everything you do and say with "yes, I know there are better ways, I'm not dumb, I'm just working within constraints, and this does the job".

that's just the core of the posting-on-hn experience. when i'm programming i don't try to preemptively defuse personal attacks like that, though i do try to accurately document the advantages and disadvantages of things in my comments, which often looks like 'this is a fucking broken piece of shit that only works if none of the input bytes are null and takes cubic time'

but my motivation there isn't to keep people from calling me an idiot. that's a lost cause. it's to save me and them time rediscovering problems i already know about

> My favorite hack along these lines was to put a timer/ISR on an embedded system that did nothing more than crawl up the stack frame the two or three addresses that the ISR used (yep, it was really just as dumb as [sp + 8] or whatever), and then dump that address to the serial terminal every second or so.

Did the same, but added a stack canary to tell if I overflowed, and wrote my call-stack results to a hardcoded address at the very end of memory (last 32 bytes, IIRC). When the chip reset, in addition to the reset flags (brownout, etc), I could peek that memory to see what the last addresses in the callstack were.

Helped immensely in figuring out a transient bug (device resets) which was hard to repro.

Reply on news.ycombinator.com