Transmission causes leopard slow death

[kine]

o hi, me from earlier in the thread (pages 1 and 2)

Wanted to report that i had this happen to me again, just now, for the first time since the 1.20 update. Since that update i've routinely had multiple torrents download -- my max active downloads is 4 and my max uploads is 50. I have on several occasions reached the maximum bandwidth i've allotted for Transmission. Haven't had any trouble.

Now, though, all of a sudden, i got this crash again. I had four torrents downloading and one waiting to start. Three were from private trackers, so they had high speeds (each fighting for bandwidth i'm sure), whilst the fourth is from a public tracker and is going quite slow.

Transmission version is 1.33 (6594), Mac OS is 10.5.4. Aluminium iMac 2.4 GHz, 1 gig of RAM, &c.

I was so happy. :( Please help me feel that way again Transmission devs :(

[vandozza]

i dont know if this is related, but since 1.33 my router has been crashing/rebooting every 2-3 min.

i have a dlink 4300, and in the past have had no problems with the amount of peers that i could connect to.
my adsl link is 1500/256

prior to 1.33, i had max peers set at 400
and peers per torrent at 200
max downloads at a time 2

with these same settings, having upgraded to 1.33, the router crashes as soon as >160 or so peers are connected.

edit - here's a link to bitrocket not crashing with many more peers.

Click for full size - Uploaded with plasq's Skitch

[psykeeq]

I tried the latest night build 1.33+ (6690)...seeding 15 torrents...crashes in about 5 mintues the same way as the other mentioned.

Is there any progress on this bug? Did you discover what causes the problem? When can we espect any update?

[kidmidnight]

This had been happening to me for a while now.

It seems to hang the entire system. Stuff kind of works, but then everything beachballs. I've noticed it really only happens on very large torrents (1 gig and up) or lots of small torrents running at the same time. Sometimes it doesnt occur for days, sometimes it happens 2 or 3 times in one day. There is no crash log. When it happened today, i lost most of the info on a 2 gig torrent. it was around 85% of the way complete when the system beachballed. I had to hard restart the system, and when I restarted Transmission the torrent was at 3%. I dont know if maybe this is related to the problem or not.

This ISNT a router problem. The router still works fine. Other computers can connect and still surf the internet. This is an entire system beachball. No I have no and have never had any interface manager hacks.

To sum up:

1. Your entire system beachballs. This usually manifests when you mouse over any of your menu bar items.
2. IT ISNT RELATED TO THE ROUTER or transmission's effects on the router (previous versions killed some routers)
3. IT ISNT RELATED TO SIMBL or any other silly hacks.

This is happening to me on leo 10.5.4 with transmission 1.22

[Debu]

I don't know if this is related to the "slow death" problem, but I discovered that if I use the "Verify Local Data" command (under the "Transfers" menu) my system immediately starts gobbling up "Free" memory and apparently deposits it into the "Inactive" category. As I recall, quitting Transmission does not release the "Inactive" ram back to "Free"; a restart is required.

I know nothing about programming, but is it possible that the "leak" occurs when a piece is verified?

[MBP, 4G RAM, Leopard 10.5.4, Transmission 1.33+ (6666)]

[essiw]

I don't know if this is related to the "slow death" problem, but I discovered that if I use the "Verify Local Data" command (under the "Transfers" menu) my system immediately starts gobbling up "Free" memory and apparently deposits it into the "Inactive" category. As I recall, quitting Transmission does not release the "Inactive" ram back to "Free"; a restart is required.

I know nothing about programming, but is it possible that the "leak" occurs when a piece is verified?

[MBP, 4G RAM, Leopard 10.5.4, Transmission 1.33+ (6666)]

inactive is just free memory what is been used, it will be used when there is not enough free memory left

[Debu]

Inactive is just free memory what is been used, it will be used when there is not enough free memory left

You may be right, but I've never seen any other program eat RAM this way. I thought that once all "Free" RAM is used "page outs" start to occur - i.e. the system starts to write to disk to free up RAM. If that's true, that's a lot of writing once "Free" RAM is exhausted.

As I write this, Transmission has uploaded 1.86 GB and downloaded 2.26 GB during the session. I have 751 MB of free RAM, less every few seconds. 742 MB now. This is out of a total of 4 G of RAM. When I started the session, I had more than 3 G of free RAM available.

I'm not complaining, mind you. Transmission works well for me and is easy to use - for free - and I haven't yet experienced the beachball.

Still, a program that eats this much RAM is a bit strange (pun intended). (696 MB now.)

[Zorg]

This had been happening to me for a while now.

It seems to hang the entire system. Stuff kind of works, but then everything beachballs. I've noticed it really only happens on very large torrents (1 gig and up) or lots of small torrents running at the same time.
....
To sum up:
1. Your entire system beachballs. This usually manifests when you mouse over any of your menu bar items.

This is happening to me on leo 10.5.4 with transmission 1.22

Same here. I have a lot of small downloads (100+) and quite a few over 2GB each, so maybe that's related? And like you, it seems to only freeze after it's been going for a while and you interact with your mac, i.e. use the dock, menus, or touch transmission in anyway (including quitting it).
Please continue this thread here ->http://forum.transmissionbt.com/viewtop ... a&start=15, so we can just use one thread to keep track of this problem. Cheers

[loopkid]

Why not continue using this thread? It's much older and more informative than the other thread.

[Zorg]

I guess because I thought the other one had a more appropriate name....but neither of them are good really. It should be something like "Transmission 1.22 - 1.33 causing permanent system-wide freeze/hang" or something similar. I've pointed to this one from the other thread now.
I really hope one of the Devs sees this soon and gives us some hope.

[essiw]

Inactive is just free memory what is been used, it will be used when there is not enough free memory left

You may be right, but I've never seen any other program eat RAM this way. I thought that once all "Free" RAM is used "page outs" start to occur - i.e. the system starts to write to disk to free up RAM. If that's true, that's a lot of writing once "Free" RAM is exhausted.

As I write this, Transmission has uploaded 1.86 GB and downloaded 2.26 GB during the session. I have 751 MB of free RAM, less every few seconds. 742 MB now. This is out of a total of 4 G of RAM. When I started the session, I had more than 3 G of free RAM available.

I'm not complaining, mind you. Transmission works well for me and is easy to use - for free - and I haven't yet experienced the beachball.

Still, a program that eats this much RAM is a bit strange (pun intended). (696 MB now.)

there is already a thread about this

[Jordan]

Back to the original `slow death' issue of this thread, there have been some changes recently for ticket #1254 that might be useful. I'd like to hear feedback from users experiencing `slow death', especially with respect to network connections, on whether or not a nightly build of revsion 6700 or higher changes anything.

[loopkid]

I just tried the 6717 on Mac OS 10.5.4 with 28 torrents with 5 gb each and it caused a quick death to Transmission. After about 2 minutes the user interface is completely locked up. I triggered forcequit and it took several minutes for a complete shutdown, usually I even have to restart my system to restart Transmission.

[Zorg]

I tried rev 6700 last night, and it was the first time in 2 weeks my system didn't freeze upon interaction with Transmission after a few hours. I first checked Activity Monitor, which seemed to be hanging, so with a sigh, i thought it was completely frozen again. However, Transmission was still active and so I tried a different method of quitting it to the normal command Q - I first closed the Transmission window (as in the red x / circle at the top of every osx window) and then quit via the menu bar. To my surprise, the system was fine and Transmission actually quit! So basically, i'm not sure if it's the changes you made in this revision or the way I quit it this time, it's probably the former. I'll do more testing and get back to you. Thanks!

[Jordan]

I just tried the 6717 on Mac OS 10.5.4 with 28 torrents with 5 gb each and it caused a quick death to Transmission. After about 2 minutes the user interface is completely locked up. I triggered forcequit and it took several minutes for a complete shutdown, usually I even have to restart my system to restart Transmission.

Are these torrents stored on an internal hard drive, or on a usb drive, or a drive connected via the network, or some other situation?