Author archives: Mike
Once again, the universe rewards cynicism (Stupid universe.)
Written by
on
in
Snaking.
Well, that one leak definitely wasn't the end of it. Still seeing a leak of 4KB every 5 or 6 minutes when running the tests in a tight loop.
Blah. Should have gone out for coffee with Shane, would have been more productive.
Don't forget to remove the testing fixtures you've added (Otherwise the test suite goes to heck...)
Written by
on
in
Snaking.
File this in the "stupid things that waste half an hour of debugging time" category. Switching to trying to verify the memory leak fixed, I suddenly discovered that something like half of the tests were now failing... so combed through all of the changes trying to figure out what I screwed up... turns out I'd ...
Burned too many times (Can't get happy about finding a leak...)
Written by
on
in
Snaking.
Have just discovered another leak, which is the one that was showing up with the "raise an error on send" test. Somehow holding a reference to a Deferred object which had methods registered from the holding object is producing the leak.
That so shouldn't be happening. Going to have to do some reworking of the ...
Play in Design: The Ampersand (First draft starts... forgot how interesting this stuff is (well, to me, anyway)...)
Written by
on
in
Design Theory.
Since the whole point of starting this blog was to prod me into doing some serious work on making my thesis work more accessible I suppose I should actually do some writing for it. So, the first sub-section of the "Play in Design" section now has a first-draft. There are 14 "Treasure Chest" sections in ...
A blowout for grams (I rather sucked at pool this afternoon...)
Written by
on
in
Vindaloo.
Aunt Lil' dropped grams off and had lunch with us. After she and Rosey had left grams and I played 4 games of pool. She won three of them, with my sinking the black mid-game, scratching on the black, and sewering on the black.
Ah well, guess that's what happens when she doesn't go about ...
I give up (How the heck can *that* be leaking?)
Written by
on
in
Snaking.
Somehow a test case which consists of creating a client, calling getTable( ) on it, and having it immediately raise a socket error when it goes to send is leaking. There must be something going wonky at the Twisted level. Maybe a deferred/callLater object getting left on the stack for every call? Maybe a demon? ...
Take a step away from the computer (That's it, nice and easy...)
Written by
on
in
Snaking.
Frustrating (I'm gnashing my teeth at this point) to spend literally hours trying to whittle down a memory leak only to get close and find that it disappears. Mirages of memory leaks plague me. Now that I'm doing a gc run after each test case, and with a few other tweaks to try and filter ...
I believe this bug is driving me nutty (But at least I have a date for the staff Christmas party...)
Written by
on
in
Snaking,
Vindaloo.
Okay, so I have the bug isolated... sort-of. I have two test cases which differ solely by 1 call. In the one case, there's a memory leak (beyond the garbage created by the bisect oid store). In the other, there's none.
The problem is, I can't see any way for the leak to fall out ...
Leaks in the test-suite (Bisect OID storage seems to create unreachable tuples...)
Written by
on
in
Snaking.
The most obvious leak in the test suite turns out to be limited to the bisect-based OID storage module. Nothing to do with the real-world system :( . Haven't been able to figure out how the garbage gets produced, the tuples are just part of a big list stored inside the Agent object. The Agent ...
Oh, yes, the memory-leak safari continues... (Just in case anyone cares...)
Written by
on
in
Snaking.
Tracking down the memory leak is not going well. So far each time I think I've isolated a test case that produces a leak it eventually stabilises at some memory level after an hour or two of operation.
There's something funky going on that I'm thinking may be a reference loop that's requiring the cyclic ...
Mike C. Fletcher, the VRPlumber, is a philosopher of design turned computer programmer based in Toronto, Canada. He works primarily in the Python programming language, and maintains a large number of Open Source software packages. You can reach him at: mcfletch@vrplumber.com.