Reading Tea Leaves
Reading Tea Leaves is a talk that was first given by Danny Thorpe in 1999, and it used to be a 1-hour session. Today, we did four hours worth, and it was still a bit rushed. For those who don't know, Danny is the lead coder for the Delphi compiler, including its refactoring into a .NET compiler. He also wrote the old Tomes of Delphi books. This guy knows his stuff. Side note, the Delphi compiler is 3.5MLOC.
Key number one: you need to separate what you know you wrote from what it's actually doing. To be effective, you have to forget that you wrote the code.
Multiprocessing is the biggest potential hurdle for developers in the future. Since processors are not going to get much faster, you're going to encounter more cores. So, if you've got a mutlithreaded app, you must test with multiple CPUs where your app is sensitive to contention. You can get away with HyperThreaded if you don't care that your on-chip cache is shared. You can get away with dual-core if you don't care about PCI bus contention. Going from 1 processor to 2 is the big jump...n-way is only incrementally harder.
He described a scenario where he's seen a user move the mouse rapidly and crash the software. Now, he underestimated just how rapidly. This must have been a Quake player, because they shook the mouse so fast that the message queue ran out of memory. Yikes!
I don't want to cover everything, because you really need to hear Danny speak. (I'll relay more to my coworkers in my trip report.) Here's some highlights:
App disappears? Likely, you overflowed the stack and the object whose exception handler was supposed to be called is actually already gone or corrupt. If Windows can't locate a valid exception handler, poof!
Bug only shows up when you turn on Delphi's compiler optimizations? Turning on optimization causes the compiler to do lifetime analysis on local vars, holding them in registers where it can. Sounds like you forgot initialize a variable later in the method, where the compiler has mapped that variable into a register that was already used further up and probably non-zero.
CPU view is your friend. If you see an address in $004nnnnn, it's probably data in your code. $7Cnnnnnn is Windows code.
Need to inject code into a process? Send a system-wide message (like change wallpaper or resolution, etc.) that gets sent to all top-level windows. This will cause your dll to get loaded into every process that message hits. Great for hacking network games...not that Danny would do something like that.
I've got 3 more pages of notes. Come to the conference next year if you want more.
Key number one: you need to separate what you know you wrote from what it's actually doing. To be effective, you have to forget that you wrote the code.
Multiprocessing is the biggest potential hurdle for developers in the future. Since processors are not going to get much faster, you're going to encounter more cores. So, if you've got a mutlithreaded app, you must test with multiple CPUs where your app is sensitive to contention. You can get away with HyperThreaded if you don't care that your on-chip cache is shared. You can get away with dual-core if you don't care about PCI bus contention. Going from 1 processor to 2 is the big jump...n-way is only incrementally harder.
He described a scenario where he's seen a user move the mouse rapidly and crash the software. Now, he underestimated just how rapidly. This must have been a Quake player, because they shook the mouse so fast that the message queue ran out of memory. Yikes!
I don't want to cover everything, because you really need to hear Danny speak. (I'll relay more to my coworkers in my trip report.) Here's some highlights:
App disappears? Likely, you overflowed the stack and the object whose exception handler was supposed to be called is actually already gone or corrupt. If Windows can't locate a valid exception handler, poof!
Bug only shows up when you turn on Delphi's compiler optimizations? Turning on optimization causes the compiler to do lifetime analysis on local vars, holding them in registers where it can. Sounds like you forgot initialize a variable later in the method, where the compiler has mapped that variable into a register that was already used further up and probably non-zero.
CPU view is your friend. If you see an address in $004nnnnn, it's probably data in your code. $7Cnnnnnn is Windows code.
Need to inject code into a process? Send a system-wide message (like change wallpaper or resolution, etc.) that gets sent to all top-level windows. This will cause your dll to get loaded into every process that message hits. Great for hacking network games...not that Danny would do something like that.
I've got 3 more pages of notes. Come to the conference next year if you want more.
0 Comments:
Post a Comment
<< Home