This is the output of 'ps' while bittorrent is downloading 1 ~800MB torrent and
seeding three more, in variable sizes from 400MB to 3GB (you can see the
timestamps of 'grep' to see how horrible this is):

[root@donkey ~]# ps auxww | grep bitt
asuardi   6989 33.5  6.1 125304 31792 pts/2    Sl   10:07   0:16 /usr/bin/python
/usr/bin/bittorrent
root      7015  0.0  0.1   3884   668 pts/0    R+   10:08   0:00 grep bitt
[root@donkey ~]# ps auxww | grep bitt
asuardi   6989 22.3 20.2 189192 103956 pts/2   Sl   10:07   7:00 /usr/bin/python
/usr/bin/bittorrent
root      7035  0.0  0.1   3880   668 pts/0    R+   10:39   0:00 grep bitt
[root@donkey ~]# ps auxww | grep bitt
asuardi   6989 22.7 23.0 203592 118272 pts/2   Sl   10:07   8:33 /usr/bin/python
/usr/bin/bittorrent
root      7041  0.0  0.0   1672   308 pts/0    R+   10:45   0:00 grep bitt



The growth is always localized at the same address - attached pmap of the
running process, from which you can see:

[root@donkey ~]# pmap 6989
6989:   /usr/bin/python /usr/bin/bittorrent
08048000      4K r-x--  /usr/bin/python
08049000      4K rw---  /usr/bin/python
0804a000 108620K rw---    [ anon ]

BT and python-related packages are also attached. You might notice the presence
of many BT-5.0.3 related RPMs, which is due to my trying out your 5.0.3 city-fan
RPM; I've downgraded however due to

a) it uses much more memory than 4.4.0 on startup
b) it still leaks, albeit not in this spectacular way
c) torrents stop without clear reasons why and the logs are quite packed with
python exceptions, I've seen three different ones in 24 hours. 4.4.0 is much
less problematic

The only weird thing is that I don't recall such a devastating problem until
recently (but then again I haven't been on FC6 for that long with my P2P box).

Created attachment 144630 [details]
pmap output of the running bittorrent process

Created attachment 144631 [details]
bittorrent and python-related packages on the box

Forgot to say... machine is an AMD K7-800, FC6-latest currently running a
2.6.20-rc2-git2 kernel (I bump it up from time to time), with 512MB RAM.

The problem can be summarized by saying that I can't complete a sizable download
via BT unless I restart the client at least once during the process; if I don't
do that it eventually sends the box into swapping.

Isn't this a duplicate of Bug 204622?

There's not a lot as a packager that I can do about this since the memory leaks
and other issues you've observed really need to be addressed upstream. Could you
try reporting this to bugs? I think they'll only be interested in
the issues with 5.0.x though.

Doh, forgot to mention that I had noticed bug 204622 - but that one was leaking
very slowly (at a rate that might be comparable to 4.4.0-2 while only seeding,
or 5.0.3 in normal operation as I observed it), while this one leaks like a
broken fountain, and almost all (if not entirely) at the same memory address.

I might still have my FC5 partition around, if that's the case I'll try and see
whether this huge leak happened in FC5 as well. If it does, then it was the FC3
rpm that worked fine...

I will try anyway reporting in the next few days to bugs.

It appears that after recent updates, namely these:

-rw-r--r-- 1 root root   715016 Jan 26 17:00 glib2-2.12.9-1.fc6.i386.rpm
-rw-r--r-- 1 root root  1315464 Jan 26 17:00 glib2-devel-2.12.9-1.fc6.i386.rpm
-rw-r--r-- 1 root root  6929626 Jan 26 17:00 gtk2-2.10.8-1.fc6.i386.rpm
-rw-r--r-- 1 root root  3171856 Jan 26 17:00 gtk2-devel-2.10.8-1.fc6.i386.rpm
-rw-r--r-- 1 root root    54532 Jan 29 16:27
gnome-python2-libegg-2.14.2-8.fc6.i386.rpm
-rw-r--r-- 1 root root    24712 Jan 29 16:27
gnome-python2-extras-2.14.2-8.fc6.i386.rpm

the major leak has entirely gone away. If you're interested, I might be able to
play with RPM downgrade to see whether it's possible or not to pinpoint what RPM
package fixed the huge leak...

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Closing as NOTABUG - actually it WAS a bug but in other packages, as noted above.