Category archives: Snaking

I'm trying to release new PyTable and BasicPropery versions. Unfortunately, it's been something like 40 minutes, and I'm still waiting for the dratted SourceForge to load the release-editing pages. And the comics.com pages are taking... well... it's hours and hours anyway, I started it downloading when I woke up at 10AM, and it's still not ...

For those with a yen for PyGreSQL, there's a new version of PyTable that has preliminary support for it. It runs most of the PyTable tests, but fails miserably in the real-world project (some problem with the reverse-engineering of the schema from the database).

Anywho, there for those who want to play with it.

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 ...

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.

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 ...

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 ...

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? ...

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 ...

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 ...

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 ...