Transmission causes leopard slow death

[albyrw]

It appears the bug has been fixed (and it's gone very quiet on this thread...) I've been using 1.40 since it was released and haven't had a singe crash in the last roughly two weeks. Anybody else see a marked improvement? And I've been running heavy duty DL too - up to 20 torrents, >200 peers, settings that would have been guarateed to make it fall over in an hour or so using 1.34. So this is one happy user. Anyone else wanna say "thanks, devs!"?

[livings124]

albyrw: That's good to hear.

Can anyone else confirm this? Everyone was quite vocal to complain about this, so it would be nice to know if we should even bother still looking into this.

[martin308]

Ill try putting my connections and things back up and post back here after a couple of days

[mfc]

albyrw: That's good to hear.

Can anyone else confirm this? Everyone was quite vocal to complain about this, so it would be nice to know if we should even bother still looking into this.

I haven't had time to read all the threads but I read some. The problem I have been experiencing with transmission is that it slows down or even stops all internet connections, including mail. I know this because after complaining to apple support about problems with mail and safari (I did not receive mail, could not load safari pages, could not send mail) for three months, I decided to stop transmission when sending mail or surfing the net and the problem stopped completely.

After the last transmission update, I still have to stop transmission when I need to send mail or surf the net, as with both Safari and Firefox, it slows down the loading of pages and some don't even load. I still can't receive or send mail when transmission is working.

I don't know, if this helps or not but since you ask that we confirm if we keep having problems, I thought I should let you know.

I have an iMac 2.8 GHz Intel Core 2 Duo with 4 GB RAM, Mac OS X 10.5.5 and Transmission 1.40 (7084).

Thanks for your help!

[livings124]

mfc: That is not this problem, and this has been discusses in other threads.

[aleph]

This problem had dropped off my radar because I mainly use the daemon now. However, I recently had the need to use the Mac client (1.40) to download several large torrents (4-8GB) at high speed (1-2mbit) with a reasonable amount of peers.

After 24 hours use I did not experience this issue once. I feel this bug may finally have been squashed. Thank to all the devs for the update!

[hardmaru]

Hi

I'm using version 1.40, on my mac 10.5.5 / 2.8GHz Intel core 2 Dual with 2 GB Ram, and this problem still persists. If transmission is not running my mac stays alive but once transmission is running and many torrents are active, it's only a matter of hours before my mac gets wiped out.

I use fibre internet in Tokyo so the download speed is reasonably fast, and I notice that when the speed hits the max the chance of crashing is higher. Usually the next time transmission gets restarted we don't see the same speed anymore and needs to wait a while to build up the bandwidth.

[livings124]

hardmaru: That clearly sounds like it's a result of your router being maxed out.

[verses]

albyrw: That's good to hear.

Can anyone else confirm this? Everyone was quite vocal to complain about this, so it would be nice to know if we should even bother still looking into this.

I don't normally have many torrents at the same time (partly to workaround this issue) but yesterday, using 1.40 (7084), I set up six (1 seeding 5 downloading+seeding), a scenario that would normally grind my Mac Mini to a halt. This morning, all seems fine!

So in my very limited scenario it seems fixed. Thanks guys. When I get chance I'll try some other tests and feedback here. It'd be good to hear from other users who had the problem too.

Cheers,

Ian

[ludivine]

Not fixed. This is a new problem for me, actually, and I'm using both the newest version of OS X and Transmission (1.42 now). It just started yesterday and I've been a fairly high-traffic torrent user with 0 incident for over a year. Even with only one small-sized active download and no other programs running, it freezes within 5 minutes. The HD makes noise for a while but when I let it stand for a couple hours it wasn't making noise any more (while the system was still totally unresponsive). It started when I tried downloading an 8 gig torrent, but then I've downloaded comparably-sized (and actually larger) ones in the past. What gives? I can't even figure out a temporary fix that isn't using a different client. I tried re-installing OS X to no avail as well.

[basse]

I have experienced the aforementioned problem with Transmission preventing hd read and thus pretty much hanging the whole machine. It passed by either updating to 1.42 or removing most of my seeding torrents, around 30 torrents totaling 20GB.

However, now I'm experiencing another problem with the newest Transmission. I'm downloading one 50GB torrent and seeding around ten smaller torrents. Transmission will take most of the time 30-50% of my CPU causing my 6 months old MBP's fans to spin at speeds up to 3500rpm. It doesn't exactly make the Mac slower, but before Transmission use was not noticeable either in Activity Monitor or fan noise. And I'm now a little worried to leave the computer dl for days.

Could this be caused by the large size of the torrent, not the program itself?

For reference, I'm using the newest Leopard.

[Zorg]

I've been away for about 3 months. Now that i've come back and updated to 1.42, the freezing seems to have stopped, no matter what my peer limit is. Thanks for whatever you did in this update.
Cheers
Zorg

[FUNKSTICK]

I have NEVER seen this happen until recently. I'm on Leopard 10.5.6. Intel MacPro.

I was running Bittorrent then Azureus and when that started acting up I gave up and went to Transmission. And I was SO very happy with Transmission for quite some time. At one point recently I had 1000 items seeding and 30 downloading and thats a modest assessment.

Then I believe JUST before the upgrade to 1.42 (or was it after?) things stopped downloading. I chalked it up to ANYTHING other than a problem with Transmission and tried numerous fixes with ports and the like to no avail.

Finally gave up on Transmission and started back with Vuze which proved better than I remembered (updated).

So I tried them in tandem and 1 on, then then just the other one, and maybe thats when I noticed the slow downs, the beachball, kernel panics and crashing.

Now I searched and found this thread. Sounds like what I'm dealing with.

Since I saw little to no actual fixes and varying systems dealing with similar problems with different versions of transmission, I just looked for an old version and started it. Transmission 1.40

All of a sudden things are connecting and downloading again. Just 10 things of various sizes, but still good. Better than the old red bar across all comers.

I thought 1.42 to be better. Just funked up my machine.

[FUNKSTICK]

CORRECTION

I suppose I was being hopeful in my last post.

I turned on Transmision 1.40 typed that post and went to bed. 3am here.
I woke up at 10 am to find the computer had frozen at 4:30 am
and everything had stopped.

Had to press and hold the power button to shut it off because the beachball kept popping up and soon nothing responded.

Is there any solution for this stuff?

[TheBang]

I have recently begun experiencing the symptoms described in this thread also. I have seen it while using Transmission 1.34 and 1.50b3. This is being used on Mac OS 10.5.6.

Posts #1, 4, and 5 in this thread accurately describe what I am experiencing.

I have not been able to find any meaningful error messages from Transmission in system.log or CrashReporter. I couldn't find anything by turning on Debug logging in Transmission either.

However, like two other reports in this thread, I did find a bunch of console messages from the vmnet kext. The appearance of these messsages in the system.log roughly corresponds with when I began experiencing these problems. In the system.log's from before I began experiencing these problems, these messages do not appear. The log entries are as follows (over and over):

Code: Select all

Jan 25 01:35:49 TheProfessional kernel[0]: vmnet: Failed to deep copy mbuf: 12.
Jan 25 01:35:49 TheProfessional kernel[0]: vmnet: bridge-en0: SendToVNet mbuf dup/copy failed: 12.
Jan 25 01:35:49 TheProfessional kernel[0]: vmnet: Failed to deep copy mbuf: 12.
Jan 25 01:35:49 TheProfessional kernel[0]: vmnet: bridge-en0: SendToVNet mbuf dup/copy failed: 12.
Jan 25 01:35:49 TheProfessional kernel[0]: vmnet: Failed to deep copy mbuf: 12.
Jan 25 01:35:49 TheProfessional kernel[0]: vmnet: bridge-en0: SendToVNet mbuf dup/copy failed: 12.

Once these messages start appearing in en masse is when the problems begin. Transmission will hang (and then sometimes recover). Network activity on other apps (like Safari) will cease. New programs launching (like Console or Activity Monitor) will hang. Try to quit running programs will hang them. When/if Transmission recovers, the other symptoms will cease.

Now, I've actually found a way to stop the hangs. Once the messages start showing up in the Console, if I go into Transmission's Preferences, and uncheck the Limit Total Bandwidth: Download Rate, it will stop the freezes. Additionally, as soon as I remove the download rate limit, it looks like a stream of data comes in from the network bufferes. The total Transmission download rate jumps up several Mbps for a few seconds.

So based on this and other reports in this thread, the freezes seem to be caused if the download rate is being throttled in any way, either by Total Bandwidth limit or by using Speed Limit. The messages from vmnet seem to be log-visible symptoms of the problem, but not the cause of the problem. I found this thread where the VMWare developers explain what is happening:

http://communities.vmware.com/message/1017578

This is with VMWare Fusion 2.0.1, btw. I also saw it with VMWare Fusion 2.0 (updated to 2.0.1 to try to stop it, but again, it appears to be symptomatic).

I found this console message intermittently sprinkled amongst the vmnet messages:

Code: Select all

Jan 25 02:01:17 TheProfessional kernel[0]: ctl_enqueuedata: m_allocpacket_internal(8) failed
Jan 25 02:01:17 TheProfessional kernel[0]: ALF ALERT: sockwall_cntl_releasecachedpath ctl_enqueuedata rts err 55

Another possible way to recover from the "slow spiral of death" (if, for example, Transmission is beach balling, and you can't get to the Preferences to unchoke the download limits), is to disconnect your network interface. I unplugged the ethernet on my Mac Pro, and after a few minutes, everything unfroze. The moment of unfreezing corresponded with the following log entries at 02:04:25 (earlier entries included for possible relevance):

Code: Select all

Jan 25 02:01:03 TheProfessional ReportCrash[4586]: Formulating crash report for process DirectoryService[11]
Jan 25 02:00:54 TheProfessional fseventsd[38]: client: 0x817600 : USER DROPPED EVENTS!
Jan 25 02:04:25 TheProfessional com.apple.launchd[1] (com.apple.DirectoryServices[11]): Exited abnormally: Abort trap
Jan 25 02:04:25 TheProfessional /usr/sbin/spindump[4574]: process 4477 is being monitored
Jan 25 02:04:25 TheProfessional /usr/sbin/spindump[4574]: process 4490 is being monitored
Jan 25 02:04:25 TheProfessional /usr/sbin/spindump[4574]: process 4537 is being monitored
Jan 25 02:04:25 TheProfessional /usr/sbin/spindump[4574]: process 4537 is being no longer being monitored
Jan 25 02:04:25 TheProfessional /usr/sbin/spindump[4574]: process 4490 is being no longer being monitored
Jan 25 02:04:25 TheProfessional /usr/sbin/spindump[4574]: process 4114 is being no longer being monitored
Jan 25 02:04:25 TheProfessional ReportCrash[4586]: Saved crashreport to /Library/Logs/CrashReporter/DirectoryService_2009-01-25-020102_localhost.crash using uid: 0 gid: 0, euid: 0 egid: 0
Jan 25 02:04:25 TheProfessional DirectoryService[4590]: Launched version 5.6 (v514.24)
Jan 25 02:04:25 TheProfessional DirectoryService[4590]: Improper shutdown detected
Jan 25 02:04:25 TheProfessional DirectoryService[4590]: WARNING - dsTouch: file was asked to be opened </var/run/.DSRunningSP1>: (File exists)