3 ms·
That seems pretty cool to me. I've never really needed to do this because well what good would it do you really unless you could change your input to not trigge
by jswinghammer 17y ago
That seems pretty cool to me. I've never really needed to do this because well what good would it do you really unless you could change your input to not trigger the undesired behavior but it's very interesting nonetheless.
I guess you could let the 3rd party vendor know about what you found though which might be helpful to getting a new dll that's fixed whatever it was you were debugging.
- barrkel 17y ago> I've never really needed to do this because well what good would it do you really ISTM it's not about avoiding triggering undesired behaviour, or "debugging" third-party code (as in finding bugs you don't own). It's about debugging your own code as invoked by third-party code - that's usually an underdocumented black box in application frameworks everywhere, where control pops in and out of your code from mysterious locations beneath the water. Figuring out the exact ordering constraints and implicit assumptions is tricky at the best of times when using trial and error; good luck trying to do that with documentation. Using the source (any readable representation of the source) is leaps and bounds ahead.
- AGorilla 17y agoI had a coworker once that used a library of his in all of the company's main applications but kept it out of source control. If you ever asked to see the code, he would say "what do you need, I'll do it for you?" One day after chasing a bug for hours, I begged him to allow me to see the code and he refused. I calmly walked back to my desk and Reflectored it and found the bug in less than 10 minutes.
- StrawberryFrog 17y agoI had a coworker once that used a library of his in all of the company's main applications but kept it out of source control That is seriously anti-social behaviour, and should not be tolerated.