Transmission causes leopard slow death

[kine]

Yeah well, we're in the Mac Support forum, so i figured restricting my scope to the Mac world would be given. :/

We've been using the 7803 build you suggested (with speed limit on and only one active transfer) for about 12 hours now, no crashes yet. So that's definitely an improvement over the two-crashes-in-6-hours experience we had with 1.50. However, that 12-hour period also coincided with us sleeping/doing other things (whereas the computer was in use during the previous 6-hour period) so there may be some other factors there that haven't been accounted for. Unfortunately i'm only here for another day or so, so i don't think i can do a proper long-term test, but it might at least tell us whether this is better than 1.50.

[TheBang]

Like others here, I too am disappointed that this issue hasn't been given more attention and priority. The fact that Jordan doesn't have a Leopard machine should not be an impediment for the developers to properly investigate this bug. As others have mentioned, Leopard is your single largest userbase, and as such you should be able to develop for and troubleshoot it properly.

I also think that distractions like external drives and routers should stop being the knee-jerk reaction to people reporting this problem. I think it's been pretty well established that the problem is localized to the Leopard computer where Transmission is running, and furthermore, localized to the network stack or buffers.

I did some pretty intensive troubleshooting when I was hit by this issue, as I detailed a few pages back:

http://forum.transmissionbt.com/viewtop ... 240#p33724

livings' response seemed to indicate that he thinks it's the OS, and implies that there's nothing that can be done about it. I find that difficult to believe, or at least difficult to believe that there isn't another way to do bandwidth limiting in a way that doesn't take down the system. After all, as mentioned, other BitTorrent clients like Vuze and uTorrent have rate controls without crashing the system.

In the meantime, I've been running my Transmission without using Speed Limit or Limit total bandwidth. I can try using rate limits again and see if it continues to crash my system, and I can try the latest nightlies too. But if I'm going to be subjecting my computer to crashes, I'd at least like to know that the problem is being given proper consideration when I try the suggestions given and give the feedback requested.

[guilherme]

Not that this is actually on topic, but uTorrent does crashes a lot of (Mac) systems. And in a fast death fashion. Try using it for downloading a few 5 GB torrents or a torrent with lots of files - spinning ball of death to the point where Finder crashes and you need a hard reset.
Search the uTorrent forums for it. A lot of users are complaining about this + 100% CPU usage (from 0.900 to the latest 0.904).

[brady8]

I'm having this same issue on Leopard as well, after switching back from uTorrent (I like Transmission's UI a lot more). I really hope this gets fixed, as I hate power-cycling my laptop all the time.

Thanks!

[oraguru]

Hi Jordan

I promised you an answer (on the bottom of page 17 of this thread )...

My Mac hangs with Transmission 1.50, freezes as all the others described here... so what I did was only to restore Transmission Version 1.42 and BAM ! It works since then perfectly, I'm downloading around 10 torrents in parallel, Files with minimum size of 2GB.. speed up and down is always more than 100K/s... So I'm happy again and hope you'll find the problem in 1.50.

Sorry can't tell you more, just that my whole environment works fine (Net, Router, NAS, iMAC) until I use Transmission 1.50, then I get the problems.

thanks a lot for your good work !

G

[husky]

Hi everyone,
just wanted to drop in to say that i've been having the same problems with 1.5. Actually the problems started before 1.5, but i have been running Transmission for over a year with earlier versions which gave no problems at all. Symptoms are the same as indicated by the first poster in this thread. Usually i can also track the crash back to the kernel logs with messages like these:

Code: Select all

2/19/09 10:31:55 PM kernel ctl_enqueuedata: m_allocpacket_internal(8) failed 
2/19/09 10:31:55 PM kernel ALF ALERT: sockwall_cntl_releasecachedpath ctl_enqueuedata rts err 55 

I'm not using the original drive that came with my MacBook. I upgraded my internal HD to a Western Digital 320GB drive.

I'll try 1.42 and some nightlies to see if those fix my problems.

[husky]

Well, no luck so far with r7800. After about 30 minutes i got a hang again which could only be resolved by a power cycle. I've got this from the kernel log:

Code: Select all

2/20/09 1:57:24 PM kernel npvhash=4095 

Some small details: i'm using speed limit mode with 50kb/s up and 200kb/s down, with about 57 transfer. Another funny detail: music keeps playing during the hang (i'm using Cog as my MP3 player).

I'm now going to try r7803.

[husky]

Well, that was short. I got a hang after about 7 minutes in testing r7903. First my system got very sluggish and slow after i saw these errors in the kernel log:

Code: Select all

2/20/09 2:14:46 PM kernel ctl_enqueuedata: m_allocpacket_internal(8) failed 
2/20/09 2:14:46 PM kernel ALF ALERT: sockwall_cntl_releasecachedpath ctl_enqueuedata rts err 55 
2/20/09 2:14:46 PM kernel ctl_enqueuedata: m_allocpacket_internal(8) failed 
2/20/09 2:14:46 PM kernel ALF ALERT: sockwall_cntl_releasecachedpath ctl_enqueuedata rts err 55 
2/20/09 2:14:46 PM kernel ALF ALERT: sockwall_cntl_releasecachedpath ctl_enqueuedata rts err 55 

Some applications stayed working, although the internet connection seemed to be unresponsive. After five minutes i got the spinning beach ball in more applications so that i power-cycled my Mac again. In the kernel logs i saw the familiair:

Code: Select all

2/20/09 2:19:22 PM kernel npvhash=4095 

Any other releases i can test?

[livings124]

What do users having this problem have their peer limits set to in preferences? How many active torrents? Try lowering both.

Also make sure you're running the latest version of Mac OS 10.5 with the latest security updates (make sure everything that shows up in Apple Menu -> Software Update is installed).

[Jordan]

I have just read this entire thread in an attempt to be marginally less ignorant when I post.

A quick summary of this thread so far:

1. This is probably a bug in the OS X kernel that is triggered by Transmission. Many users have posted kernel-level error dumps (1, 2, 3, 4).
2. The vmware kernel messages led to a very helpful post by mcui in this thread. If it's correct, what's happening is that OS X's socket mbufs are running out of space when Transmission is speed-limited, and Leopard fails to handle this gracefully.
3. Many users have reported that it only happens when speed limiting is on. This is right in line with mcui's theory.
4. Only Leopard users are reporting this bug. This, too, is right in line with mcui's theory.
5. It doesn't appear to be a router issue -- users with Airports and without them have reported this.
6. It doesn't appear to be a disk issue -- users with internal, external, and network drives have reported this.
7. There are a lot of posts that (IMO) are red herrings, particularly the "inactive memory" and TM digressions.
8. Nearly all major releases of Transmission have all been reported to trigger this behavior. However some users report that 1.22 is better than newer versions. I suspect this is a red herring too, but it might be plausible -- 1.22 was the last version to not use libcurl. I don't think libcurl is causing these errors, but if OS X's network memory is getting shredded, it's possible that Transmission's change from one http mechanism to another tickles the problem even more.
9. I shouldn't've been so thin-skinned when KidMidnight is rude to me -- he's been rude to lots of people in this thread. On the other hand, he's been pretty helpful in winnowing the issue's possible causes.

Things for Leopard Users to Test - Phase 1

mcui's theory is the most promising lead so far, so let's test it more fully and see how far we get.

1. Apple has a handful of network fixes in its security updates. Everyone who wants to help should go to Apple Menu -> Software Update and get up-to-date with the security updates. This probably won't solve anything (though who knows, maybe we'll get lucky) but it will eliminate any noise in the bug reports caused by testers running different revisions of Leopard.
2. If mcui's theory is correct, then the issue should be most likely to occur when down (or up+down) speed limits are enabled, less likely to occur when only download limits are enabled, and least likely (rarely or never) to occur when no speed limits are enabled. So after getting up-to-date with the security patches, please test those three conditions and see how long / how frequently the behavior crops up.
3. I'll try the same testing on Fedora and Ubuntu. If mezz is still reading this thread, I'd request he do the same on BSD, which might be more helpful because of its shared lineage with Darwin...

[husky]

Great work, thanks for summarizing it all. Just one question: do you want us to test with 1.50 or another version?

[Jordan]

Hm, I doubt that it matters. But just so that we're all on the same page, let's use 1.50.

[mofle]

I've been using Transmission for a year now, and everything has worked great until I upgraded from version 1.42 to 1.50. When use the Speed Limit i get the Slow death bug.

My specs:
MacBook Pro
10.5.6 (with all updates)

Here's my console output i anyone is interested.
Hope this get's fixed in 1.51.

And no I haven't tried the nightlies, because I only use private tracker, that don't allow this.

Console output (couldn't add it here because it's too long):
http://pastebin.com/f490e0edf

[Jordan]

I've been using Transmission for a year now, and everything has worked great until I upgraded from version 1.42 to 1.50. When use the Speed Limit i get the Slow death bug.

My specs:
MacBook Pro
10.5.6 (with all updates)

Thanks for that info.

Does the Slow Death issue show up when you only have upload speed limits turned on (no download limits)?

Does the Slow Death issue show up when you have no speed limits turned on?

[kine]

Cool, now we're getting somewhere!

I am back home now, so i won't be able to continue testing with my friend's machine (and he isn't really savvy enough to do so either). However, after downgrading him to r7803 he was able to have two or three active torrents (including the one he had had going when the problem occurred initially) running for a day or two without any lock-ups. No idea how long that might last, but it seems to have been a definite improvement over 1.50 in the 2 days we had to test, at least.

As far as further testing back home. As i said before, i haven't experienced this problem since limiting my active downloads to 4 at a time, so that seems to play some part. Just so we have as much information as possible, let me paste the relevant configuration information as i've had it set for the last several months:

- Download with maximum of 4 active transfers
- Seeding with maximum of 50 active transfers

Limit total bandwidth (always enabled):
- Download rate: 400 ko/s
- Upload rate: 40 ko/s
Speed Limit mode (almost always disabled):
- Download rate: 10 ko/s
- Download rate: 10 ko/s

- Global maximum connections: 200 peers
- Maximum connections for new transfers: 60 peers
- Enable peer exchange for public torrents (not sure if that's relevant, but i have maybe a 3:2 ratio of private:public torrents)
- Prefer encrypted peers (but NOT Ignore encrypted peers)

Since the download limit seems to have been the key factor in getting around the problem for me, i'm going to focus on that first and steadily increase the max active downloads (unless one of the devs has a better idea). I'll report back what i find.