Papa's "Wall of Dumb"
If memory serves correctly, always an iffy thing with us old fogies, Chloe Sullivan (on "Smallville") maintained a "Wall of Weird" covering all the strange events in her benighted hometown.
So Papa's decided to inaugurate his "Wall of Dumb" today- but don't worry about showing up on it- this wall is for Papa's dumb ideas. If I get ambitious enough to think about and and describe all of those I've had, 'twould be a grand wall indeed!
Today's entry (the fuel for this disgruntled posting) is a DDI test for a new KMDF 1.9 feature. Can't tell you about the feature, of course, but as a result of one of the relevant DDI, the driver writer can allocate large numbers of objects if he or she so desires. The original plan had a cap on the amount you could request, so of course I had a test that hit just above that mark. But then the cap was removed, the idea being to allow as much as there was memory for.
So Papa said- "hey fine, the number I want is a ULONG, so I'll ask for 4 billion or so [(ULONG) -1]- that ought to fail eventually [sure will on any machine I own], and I can verify it all cleans up nicely afterwards, and so forth". Possibly a dumb idea as it turned out, but we'll get back to that.
Later Papa was looking at the possibility that if there was a bug in the driver or framework, he might hang forever, so he put an explicit 20 second timeout on each test. The timeout was reported, and the test had very specific history tracking and such that it would be easy to look at the logs and see just about where it hung. The idea here being that an automated run would detect and report the failure, the logs would give a good idea where to look, and if needed, good clues for either code review of suspect areas or good breakpoints for repro could be easily determined. Thinking ahead, Papa thought he was.
Perhaps you see where this is headed...
Papa ran his test, debugged it, found bugs in the feature, and eventually got it into the regular automation runs for KMDF. All was well, the test had no false positives or negatives, and no feature regressions turned up [in part because by then it was the winter holidays and all the folks that could have been breaking stuff were on vacation].
Meanwhile, in other parts of Testland, trouble was a brewin'- older test drivers developed by more junior folks and at a time when we were still becoming familiar with the technologies that would just as soon bugcheck as look at ya. So after picking out the worst of that lint, Papa enabled driver verifier on the framework runtime, loader and the most likely of the corrupting drivers.
In some ways this was a very good thing. New bugs were found, even some framework bugs we should have been catching sooner. Many more horrible test bugs also surfaced- nice icky big ones that steal your lunch when you're not looking and slap you in the back of your head with their tails as the scuttle out of sight... Papa had more fun than an SDET should trying to squash all them 'orrible critters.
But Papa's prize test, the one where he pushed some gnarly hacks for quicker tracking and coding, and where he did things like tear down one software device stack while spawning another [to increase throughput at runtime, of course]- it began crashing, timing out on one test, and sometimes even bugchecking. Papa was mortified.
But Papa was very busy with all his other problems [including some installation issues people have presented through this blog- keep 'em coming], so he just had to wait for some time to investigate, wondering in the meantime what could be wrong with his bus driver [had to be the bus driver- couldn't possibly be an issue with the newest code- that blind spot has always troubled that old dude].
So today he finally got his chance. The test quickly hit the overlong case, so Papa broke into the debugger, set up his symbols, loaded the extension, and thinking "well, let's see how far this got- maybe I'll just see what handles and such are in my driver":
!wddfdriverinfo <DriverNameSuppressedToPreventPapaBeingDismissedForLeakingConfidenshulInfermashuns> ff
That command is still running, and it's been over an hour, and it will probably be a lot longer- the same object type, over and over.
So let's see, standard settings include special pool, so instead of each object taking a few bytes, it consumes a page of pool. Pages are fewer in number than bytes, and there is extra overhead for all that neat tracking driver verifier does. So that 20 seconds that was enough with it off to run out of memory wasn't near enough with special pool on.
Papa is an idiot. Really should have seen that one coming...
