I'm a bit surprised you don't run into things like this then :). Do you use GDB and the like at all?
replyOr do you mean all the windows specific stuff etc, I guess I was more imaging the call stack etc.
No insult was intended XD
As someone who has debugged his fair share of tricky low-level issues, the parts that I find impressive in his blog posts are things such as "then we look at the bytes in memory and oh yeah, this looks like an exception record". I would usually not think to do that (or be able to recognise it as easily as I presume he did).
replyI assume it's mostly just something you learn to recognize after decades of poking at the same things. I remember being impressed with Thiago (Qt developer) being able to immediately tell if a pointer was heap allocated, invalid/unaligned, etc. until I spent more time poring over /proc/*/maps and in gdb.
Never figured out how he could tell someone's Qt version just from an strace excerpt, though.
reply> Never figured out how he could tell someone's Qt version just from an strace excerpt, though.
replySonames might be a big clue? Otherwise, initialization order changes maybe? Sometimes there's enough file content in an strace to be able to see a strong indicator?
Those are just guesses, I do a lot more debugging with pcaps rather than straces. Although you do often want to determine which side of the syscall caused whatever you're seeing in the pcap.
I have done everything from desktop apps to web apps and a bunch in between. Regular debugging is good enough for me. Never had the need to go down into call stack level.
replyEven with embedded programming, regular C debugger has always been enough.
deleted
reply