Category archives: Snaking
Discussions of programming, particularly of programming Python
Most of the day disappears in getting dependencies built (And still it disappears...)
Written by
on
in
Snaking.
Wound up going down to Givex to work with D'Arcy on the EFT server. Spent most (almost all) of the time getting NetBSD packages set up for BasicProperty and PyTable, then getting a PyGreSQL driver written (and debugged) for PyTable (D'Arcy won't even install PyPgSQL).
Still problems with the PyGreSQL driver that I'm intending to ...
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 ...
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 ...
Doesn't look like it's in any condition to update to using v4 (PySNMP is hard enough to use with full releases...)
Written by
on
in
Snaking.
After a few attempts to get everything working with PySNMP v4a1, think I'm going to have to shelve that work and move back to PySNMP 3.x. Whatever fixes may have shown up, the amount of rewriting it's requiring is just too much to consider in the middle of trying to track down this memory leak. ...
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.