Linked by Thom Holwerda on Mon 7th Mar 2011 23:21 UTC
Thread beginning with comment 465677
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
*headdesk*
Such and investigation (of a single event) can be a multi-million dollar proposition, and still might not uncover the cause.
There are _numerous_ debugging tools out there, and I can do a memory dump, if I must.
Do it with processor emulator and I can step at any speed I choose, pause, and inspect the state.
If the software allows, I can use standard debugging tools and step through the execution.
Yowza, you're ignorant.
*headdesk* Such and investigation (of a single event) can be a multi-million dollar proposition, and still might not uncover the cause. There are _numerous_ debugging tools out there, and I can do a memory dump, if I must. Do it with processor emulator and I can step at any speed I choose, pause, and inspect the state. If the software allows, I can use standard debugging tools and step through the execution. Yowza, you're ignorant.
As someone who has debugged countless kernel issues, you're kidding yourself if you think that you can easily debug non-deterministic memory corruption, race conditions, etc AFTER the fact. More often than not, there isn't enough forensic data to reconstruct the root cause. Threads disappear. Processes crash. Repro cases are non-existent. Yeah, really easy, lightweight.




Member since:
2006-01-06
Have you seen the FBI laying out parts after a crash? It certainly is easier to inspect.