Opened 9 years ago

Closed 6 years ago

Last modified 6 years ago

#1201 closed Bug (invalid)

Mac OS X: Transmission causes system-wide freeze

Reported by: rlxbt Owned by:
Priority: Normal Milestone: None Set
Component: Mac Client Version: 1.61+
Severity: Normal Keywords:
Cc: gstein@…

Description

As several users have reported in this forum thread, Transmission will, under certain conditions, cause Mac OS X to completely freeze.

For me, at some point -- from a few minutes to a few hours after reboot -- the system becomes unresponsive. Menu Extras hang (clock frozen, beach ball), apps are still running, but no more network traffic from/to the machine (while other Macs on the same network are fine). Launching new apps will fail (keep bouncing in the dock), the dock may freeze eventually, open apps will hang during UI changes (switching panes, opening dialogs), terminal freezes after hitting return after any command, etc. (This may be consistent with several people's assumption, in the above forum thread, that apps hang on disk i/o.) Most of the times, even though not all of the times, DirectoryService? crashes. Apart from that, there's nothing too special in the logs. A hard reboot is the only way out.

For the last few days, I've been able to consistently reproduce the behavior on a Mac mini (Intel Core Duo), running Mac OS X 10.5.4, using Transmission 1.32 (6435), 100+ active transfers (100+ GB), DL and UL rate limited, connected via AirPort?, torrents and data on an external USB drive. The system is a fresh install, no other apps have to be running at the same time.

I'm aware that this may actually be an issue with OS X dealing with a router issue, but Transmission is definitely the app that triggers it.

Change History (109)

comment:1 Changed 9 years ago by rlxbt

Not that it'd make things much clearer, but just as i was filing this (on another machine), i was, for the first time ever, able to recover from the state described above, by killing the apparently hung SystemUIServer from the previously launched Activity Monitor. Within a minute or so, the system became responsive again.

comment:2 Changed 9 years ago by livings124

  • Resolution set to wontfix
  • Status changed from new to closed

Quite frankly, bittorrent is a relatively intensive protocol in terms of disk io. Having hundreds of transfers running, on an external usb disk, it just something that apparently your system can't cope with. Have you tried using the queue to only have a couple of torrents active at a time?

comment:3 Changed 9 years ago by rlxbt

  • Resolution wontfix deleted
  • Status changed from closed to reopened

If you take a look at the forum thread linked above, you'll notice that quite a number of mac users have the exact same issue, and that it occurs with a few transfers (vs. hundreds) as well, just as it occurs with internal (vs. external) drive or ethernet (vs. wireless).

My system was able to cope with hundreds of transfers running, on an external usb disk, for the last two years. For the last one year or so, Transmission was able to cope with it. Now it does no longer. Otherwise, I wouldn't have filed the ticket. It's a bug (even though OS X and the router may play a role in it).

Reopening (if I may), since it seems to affect a lot of people, not just me, and it's definitely a show-stopper.

comment:4 Changed 9 years ago by muks

livings124: I think charles knows about one similar issue (there's probably a duplicate bug filed no that) that close() fsyncs on that handle and causes a UI freeze.

comment:5 Changed 9 years ago by muks

The sync issue is at bug #651.

comment:6 Changed 9 years ago by rlxbt

muks: just to clarify... this is different from the issue that the Transmission UI becomes unresponsive during disk i/o. It's rather that the OS becomes unresponsive after Transmission creates some sort of i/o deadlock that seems to block the network stack. Transmission's UI remains as responsive as it can be under these circumstances.

comment:7 Changed 9 years ago by charles

I don't see any errors like this in the Linux version. Perhaps you should report this upstream to apple.com.

comment:8 Changed 9 years ago by livings124

  • Resolution set to fixed
  • Status changed from reopened to closed

As you said, this is the OS becoming unresponsive. If you could get us something to show what Transmission's doing, we can deal with the issue, but as of now there's nothing we can do.

comment:9 Changed 9 years ago by livings124

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:10 Changed 9 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:11 Changed 9 years ago by tyggy

  • Resolution invalid deleted
  • Status changed from closed to reopened

You could work with someone from the thread in your forum to clarify things and come closer to resolution. Because as of now a lot of people can not use transmission, and there are too few alternatives

comment:12 Changed 9 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

As I said, this looks to be at the OS level, and is not impacting most users. If you could get us something to show what Transmission's doing, we can deal with the issue, but as of now there's nothing we can do.

comment:13 Changed 9 years ago by azraeluk

I am also experiencing this problem, and would willingly help to provide whatever information I can to diagnose 'what Transmission is doing' ... but I'm going to need someone to tell me what to do to get that information.

thanks

comment:14 Changed 9 years ago by stouset

  • Resolution invalid deleted
  • Status changed from closed to reopened

I'm experiencing this problem as well. It's been going on for several months now, and only happens when Transmission is running.

Since you need more information to debug the problem, there seems to be an extremely high correlation of this happening if Transmission is left running after having to check the validity of partially-downloaded torrents.

For me, it's pretty easy to reproduce. Cause Transmission to die abruptly. Relaunch. Let Transmission finish checking the files. After it completes, within an hour or two, the system will become totally unresponsive. If you wait until it finishes checking them, then restart Transmission, the problem seems to be (mostly) avoided.

Marking this bug as invalid seems to be the wrong approach. I have several other friends with this exact same problem. Given that Transmission reliably causes this issue for a (seemingly) large number of people, it should at least be looked into. It's either a bug in Transmission, a bug in the way Transmission calls OS-level APIs, or a bug in the OS. Even if it _is_ a bug in the OS, it needs to be discovered, worked around for now, and escalated to Apple. Ignoring the problem will only cause that chain to be broken, and it likely never reported to Apple, causing the bug to persist.

Hopefully, the information I've given should be enough to narrow the problem down some. It's been maybe six months since I first noticed the problem, and it's likely tied to (or related to) the code that checks consistency of partial downloads after a crash. It "feels" like some kind of resource exhaustion problem. My first thought (before I narrowed it down to Transmission) was either the OS running out of PIDs or file descriptors. The network stops responding, the menu bar freezes, the dock freezes after the next action, no apps can be launched, and closing apps is impossible if they pop up a dialog asking for confirmation (the dialog is unresponsive). If you need anything more to narrow the issue down, I'm willing to help diagnose.

comment:15 Changed 9 years ago by charles

Does OS X's CrashReporter? generate a freeze log when this happens? Usually it will log not just crashes but also frozen programs.

comment:16 Changed 9 years ago by livings124

http://trac.transmissionbt.com/wiki/InactiveMemory

We allocate and free a lot of memory when this is being done, and the os should be able to handle this. Apparently inactive memory isn't being used as it should be, but it is completely out of our hands.

comment:17 Changed 9 years ago by stouset

charles: The CrashReporter? window never comes up. Nor, I suspect, does it have a chance to. The disruption caused by Transmission is severe enough to prevent anything that isn't already open from opening up.

livings124: How are you so sure this isn't a bug in Transmission? I don't mean that accusingly -- I've come pretty late into this discussion. If you're sure it's not a bug in Transmission, have you narrowed it down to anything specific in OSX? Is it something you've reported to Apple?

comment:18 Changed 9 years ago by livings124

Look at the forum thread: those that limit the number of download or number of connections appear to have better results; additionally, those that have slowdown have an increase in inactive memory, which, as shown in Apple's documentation, is memory available to the OS - we have no control over this. I have not reported this to Apple because the symptoms/conditions vary and I don't have any concrete information (although I have never been given any solid evidence that this is Transmission's fault, only vague anecdotes - all evidence points to the OS). Of course I do encourage you to open a ticket with Apple if you feel that this might help.

comment:19 Changed 9 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

I'm closing this until someone can give us any information to what the problem is in Transmission - all the information I have points to the OS and I have no control over that.

comment:20 Changed 9 years ago by stouset

I'm willing to help to gather more information -- just let me know what needs to be done.

comment:21 Changed 9 years ago by tempel

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 1.32 to 1.34

I've added some information to the thread the past 2 days. Mainly, I suspect a problem with address resolving (DNS). Would you please look into that.

comment:22 Changed 9 years ago by funkaoshi

A forum user has a pretty detailed account of what he thinks is the culprit here. Maybe a dev can look at the dtrace logs and confirm the findings? I was experiencing this problem as well, and ended up going back to Transmission 1.22.

comment:23 Changed 9 years ago by livings124

funkaoshi: can you try a nightly build (http://transmission.xpjets.com/) and see if it's any better?

comment:24 Changed 9 years ago by funkaoshi

The nightly won't actually launch for me. It's sits there eating up 99% of the available CPU, but doesn't seem to be doing anything. So I can't test it out, sorry.

comment:25 Changed 9 years ago by funkaoshi

The developers may want to comment in that forum thread, since i'm unsure users are aware of the wiki/trac system.

comment:26 Changed 9 years ago by marioestrada

This bug was also happening to me on my machine, running only one torrent, with limited peers and limited bandwidth. I was going crazy and found that if I downgraded to 1.22 (from 1.32) my system didn't die a few minutes after beginning the download. I noticed that this only happened with some torrents, the last one to cause my system to hang was a 7GB torrent.

When my system began hanging I found that on my console there where some vmnet related issues showing up, and found some related information on the web:

http://communities.vmware.com/message/1045817#1045817 Check rtgoodwin post.

http://discussions.apple.com/thread.jspa?messageID=8263721&tstart=0

Both of these posts show that the problems begin when using 'torrent' software.

comment:27 Changed 9 years ago by charles

funkaoshi: the "won't launch" error with the nightly has been sorted out now. Can you try it and see if it's any better?

comment:28 Changed 9 years ago by tempel

The vmware forum ref in marioestrada's comment mentions a "mbuf starvation" - that is right on track with my findings on the dying network stack.

Meaning you need to look into killing the network stack by having too many unresponsive connections open.

I had pointed out that an invalid (i.e. non-responsive) DNS IP address in my resolve.conf caused a very fast freeze of my Mac - that just sounds very much like it would cause this "mbuf starvation".

I suggest to the developer(s) that they try this themselves: Add bad DNS addresses to your OS X network interface, have a huge download active (I had it happen with two ~6GB downloads only), set the max conns to 500 and individuals to at least 100 as well. See if that causes the problem for you as well.

comment:29 Changed 9 years ago by livings124

http://forum.transmissionbt.com/viewtopic.php?f=4&t=4564&st=0&sk=t&sd=a&start=195#p30308

This post reaffirms my belief that this is a problem at the OS level (although Transmission clearly exacerbates the issue).

comment:30 Changed 9 years ago by marioestrada

It might be related to an OS issue, but the thing is it doesnt happen with 1.22. So ideally it should be looked at.

comment:31 Changed 9 years ago by livings124

marioestrada: Users have reported this with 1.22 as well. There isn't a consistent report of what the problem is or what causes it.

comment:32 Changed 9 years ago by charles

  • Resolution set to worksforme
  • Status changed from reopened to closed

This is a black hole of a ticket -- everyone's describing it in different ways, under different circumstances, like blind men describing an elephant. I really doubt that everything mentioned here is the same bug, or even all Transmission bugs.

Still, I do see some encouraging news in the thread mentioned above:

Lopoz writes:

please try the latest nightly. for me it seems to have fixed the problem.

AtTheAsylum writes:

As lopoz suggested, I tried the latest nightly build (134+ 7016 at the time)
and it seems to have fixed the problem. First I tried 3 torrents,
all downloading, and left them overnight. When they completed I set
up 6 more (3 downloading, 3 queued), left the original 3 to seed and
again left them overnight. They're still running and so far
I've had no issues :)

I'm going to close this ticket for now. Users are encouraged to reopen it if the problem reoccurs in 1.40b1 or higher.

comment:33 Changed 9 years ago by daBowmore

  • Resolution worksforme deleted
  • Severity changed from Critical to Blocker
  • Status changed from closed to reopened

I'm running now to this same Transmission+SystemUIServer system wide freeze with Transmission 1.42 (7494). Today I lost my nerves with four crashes within two hours and started googleing this more.

The descriptions discussed here & at the forums match my case well. System wide freeze, running applications remain running, already opened terminal responds to some commands (ps, kill etc), new applications cannot be launched. SystemUIServer cannot be killed, nor Transmission. Eventually the whole system freezes -- last time I had actually hard time even getting a hard boot (had to press power button for over half a minute...?). Crash has happened with at least following situations:

  • downloading one small (600 MB) torrent
  • resuming one (600 MB) torrent
  • downloading two huge torrents, total 26 GB
  • limitted bandwidth 600/600 kB/s
  • unlimitted 24/3 MB/s

Software running during the crash has varied from just

  • Quicksilver

To a broad selection like

  • Full Tilt Poker client (yes, I have lost the connection for a long while.... :)
  • Safari
  • Mail
  • UnRarX
  • iTunes
  • Excel/Word? etc
  • Skype

After one crash I managed to finish the one torrent downloading during the crash. Once finished the files were corrupt -- redownloading the same torrent worked --> so the crash + check didn't notice some corruption.

This actually started happening just some week ago, and started happening more often until eventually I cannot download a single file without crashes. Before this I have been using Transmission for long time without no problems. And I must emphasize I haven't had a crash a single time without Transmission running.

Running Leopard 10.5.6 on 2.4 GHz MacBook Pro (unibody).

Is there anything else I can provide? I didn't manage to find crashlogs (at least with Console application --> is there another way to look for them?)

Since this started just some time ago, maybe it has something to do with some Software Update received from Apple? I haven't added any components, software or new configuration whilst the problem started to occur.

To test something, can I "start from scratch" with Transmission -- what files/plists etc should I delete to make a COMPLETELY fresh install?

comment:34 Changed 9 years ago by livings124

  • Resolution set to worksforme
  • Severity changed from Blocker to Critical
  • Status changed from reopened to closed

Without crash logs there's nothing I can do. And as described above, all information points to it being the operating system that's crapping out. All the information to get a fresh install is on the wiki.

comment:35 Changed 9 years ago by daBowmore

Not very helpful I have to say. In any case this happens only with Transmission running. It could be something in the way Transmission & OS X communicate.

http://www.google.com/search?q=systemuiserver+transmission finds a whole bunch of same findings.

I couldn't find (and still can't) info for fresh install in wiki, sorry about that.

comment:36 Changed 9 years ago by daBowmore

Just as a side note quote from charles above "Users are encouraged to reopen it if the problem reoccurs in 1.40b1 or higher."

comment:37 follow-up: Changed 9 years ago by livings124

You have provided little I can use besides saying Transmission is causing slowdown, with no logs, system profiles, traces, etc. And as said above, everything points to this being an operating system issue. If the app crashes, and window will come up saying so - click sent report to apple, copy the log that reveals, and post it here. And you are currently the only user to report this issue in current trunk. Perhaps your system setup can't handle such large setups, you have a horrible router, etc.

http://trac.transmissionbt.com/wiki/ConfigFiles

comment:38 follow-up: Changed 9 years ago by daBowmore

Not a slowdown - freeze. Simply nothing starts up on the event of crash (not even the infamous "application has quit unexpectedly - report window" which I definitely would send to you if I could get it, believe me!!) --> very difficult to get any trace of this. Nothing is on console log files. I can just assume since the system freezes this completely it cannot write crash report, log files or anything. I can't imagine what component I have couldn't handle this "large setup" (2,4 GHz core 2 duo, 2GB, 7200 rpm disc...) and the network/router (Airport + ZyXEL ADSL) remains working during/after the crash

I guess you pointed the ConfigFiles for the uninstallation, thanks. I backed up these old configuration files and old Transmission.app, downloaded new one, now trying with it. Only things I modified in the new setup was the Speed Limit mode speeds + port (since the default is closed). Let's see if this has any effect.

I doubt average Transmission user even knows trac/forums or even if knows doesn't bother to register here. It's quite easy to download e.g. Vuze. Just for the sake of it, read for example this 2 weeks old thread http://discussions.apple.com/thread.jspa?threadID=1843827&tstart=-1

comment:39 in reply to: ↑ 37 Changed 9 years ago by tempel

@livings124 Your response is pretty lame as a programmer. "It's a system issue" is just an excuse - sure, it may be a lame OS issue, but still it's the app you're working on that exposes this.

Saying you need crash logs is showing that you have not even understood the problem. As many have pointed out, the IP stack dies, because of some kind of congestion. This is a case of internal "denial of service" - how can you expect a crash log from this? Nothing is crashing (isn't it obvious that some write "crash" when they mean "freeze"?)

On the positive side, I have seen this problem not recently while it was massively occuring for a while (during which I had a unresponsive NS server specified). Did you even ever look into the possibility that Transmission is causing a denial of service the way I had suspected in my previous mail?

I don' blame you if that kind of debugging is over your head, no one's perfect - but you seem to be ignorant of the hints others gave you before, as I cannot find any response from you commenting on those.

So, don't take offense, but please don't use excuses like that one. It's unprofessional and you're not doing anyone a favor that way. (Yes, I understand you're working for free on a free product, and I thank you for that, I'm just saying that your resonses are not helping to resolve the issue, either, and that you could do better).

comment:40 in reply to: ↑ 38 Changed 9 years ago by tempel

daBowmore,

Please check if your name servers are all valid - I had this problem while I had a unresponsive NS in there. Do you know how to check them?

Do you have a AVM router (Fritz Box) by any chance? The last OS X update is known to cause NS problems with them.

comment:41 follow-up: Changed 9 years ago by daBowmore

As far as I understand my DNS servers are ok. At least they both replied to two queries below. I have just anonymized the server IP addresses..

[22:52] ~> dig @NAMESERVER1 trac.transmissionbt.com

; <<>> DiG 9.4.2-P2 <<>> @NAMESERVER1 trac.transmissionbt.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7633
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;trac.transmissionbt.com.	IN	A

;; ANSWER SECTION:
trac.transmissionbt.com. 86400	IN	CNAME	concorde.lapsus.org.
concorde.lapsus.org.	26920	IN	A	91.121.74.28

;; Query time: 45 msec
;; SERVER: NAMESERVER1#53(NAMESERVER1)
;; WHEN: Thu Jan 15 22:52:49 2009
;; MSG SIZE  rcvd: 90

[22:52] ~> dig @NAMESERVER2 trac.transmissionbt.com

; <<>> DiG 9.4.2-P2 <<>> @NAMESERVER2 trac.transmissionbt.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42321
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;trac.transmissionbt.com.	IN	A

;; ANSWER SECTION:
trac.transmissionbt.com. 68800	IN	CNAME	concorde.lapsus.org.
concorde.lapsus.org.	51807	IN	A	91.121.74.28

;; Query time: 6 msec
;; SERVER: NAMESERVER2#53(NAMESERVER2)
;; WHEN: Thu Jan 15 22:52:57 2009
;; MSG SIZE  rcvd: 90

My ADSL Router is ZyXEL Prestige 600 Series.

Funny thing, the fresh installation of Transmission has been now running without problems since my last message. Could it be some configuration value in the old, deleted config files?

comment:42 follow-ups: Changed 9 years ago by stouset

As someone who previously reported this bug, I wanted to chime in that I have not experienced a recurrence since 1.40b. However, daBowmore's symptoms are identical to those I experienced when this bug was an issue for me.

On another note, though, I want to encourage the developers to please leave this bug open. We all realize that it's (probably) not an issue in Transmission proper. And we all realize that it's not something that progress can be made on until new information comes out, or a developer experiences it firsthand, or someone has deeper insight into the problem. And it's okay if the bug doesn't get assigned a milestone, or isn't marked as a blocker/critical, or isn't even actively worked on. But it's an issue that users are (apparently still) experiencing, and as long as that's the case, this ticket should remain an open issue.

Don't make your users feel like their problems are being shoved under the rug. What's the obsession with closing tickets for bugs that users are actively experiencing, anyway?

comment:43 in reply to: ↑ 42 Changed 9 years ago by livings124

Replying to stouset:

On another note, though, I want to encourage the developers to please leave this bug open. We all realize that it's (probably) not an issue in Transmission proper. And we all realize that it's not something that progress can be made on until new information comes out, or a developer experiences it firsthand, or someone has deeper insight into the problem.

You just described exactly the reason to close this ticket. Ticket are for developers to track and fix real issues - leaving this opens defeats the whole purpose of this.

comment:44 in reply to: ↑ 42 Changed 9 years ago by charles

Replying to stouset:

We all realize that it's (probably) not an issue in Transmission proper.

That's pretty much the reason to close it. If it's not something that we can fix or implement, it shouldn't be a ticket.

Problems related to transmission, but not of transmission, like this one are better off being archived & detailed in the forums IMO.

comment:45 Changed 9 years ago by stouset

But that's the thing. From your users' perspective, it _is_ a "real issue" affecting users, and it _is_ fixable by the Transmission developers. Even if there's not enough information to do so right now, and even if it's really just a workaround over an underlying OS bug.

If this same issue affected 100% of your users, would you still close it?

Does the proportion of users affected by an bug warrant closing it? Deferring, sure. But closing?

comment:46 Changed 9 years ago by livings124

If it is fixable, point us to a fix. Bug reports are not a support forum - we have a support forum. This is a vague issue that is not definitely caused by Transmission. These tickets are references for solid issues that we need to fix - quantitive, not anecdotes and vague descriptions.

comment:47 in reply to: ↑ 41 Changed 9 years ago by tempel

If it were a "unresponsive NS" issue, it would probably be caused by reverse-lookups to the connected clients. I had asked this before, but didn't get a response on this: Does Transmission resolve the IP addresses to get their host names? This would be a potential congestion if the names can't be looked up.

Assuming your NS resolving works fine, I wonder if anyone here knows how to check on the congestion of the IP stack? It would be nice to monitor the number of open IP connctions, and see if they increase over time before the system freeze. Probably it does. The question is what is causing it - NS lookups or something else.

I guess netstat might be able to help here, but I don't know how to use it efficiently for this purpose. Anyone?

comment:48 Changed 9 years ago by tempel

I have just done some testing with invalid NS addresses for my DSL interface, and could not see it causing any obvious trouble compared to using only the proper NS. Bummer. Oh well. Gotta find out how to unsub from this depressing thread. Luckily I'm not affected any more. Good luck, others!

comment:49 Changed 9 years ago by daBowmore

How on earth can you be so absolutely sure it is not Transmission? And how do you even assume that "point us to a fix?" I think I would be sitting on the other side of this table if I knew what fixes this problem.

You might be interested that the new copy (fresh start without any ConfigFiles) has been running now for 4 hours without a problem. Previous froze after max 30 min for the last 6 tries. Oh wait, I forgot -- it's not a problem with Transmission. I'd better call Steve but he's on a sick leave.

comment:50 Changed 9 years ago by thoughton

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Just wanted to add that I also suddenly started having this problem after allowing Transmission to update itself a couple of days ago. Prior to that I had torrents running 24/7 for several weeks without issue. Since the Transmission update my Mac locks up after 30 minutes or so, requiring a hard reboot. I have not updated my Leopard install in several months.

I have downloaded the latest nightly, which appears to have solved the problem, but having read through this whole ticket I feel compelled to comment on the completely juvenile behaviour exhibited by living124. Grow up, sonny. Refusing to accept your user's reports and constantly blaming OS X makes you look like a small-minded idiot.

comment:51 Changed 9 years ago by livings124

  • Resolution set to worksforme
  • Status changed from reopened to closed

Will do!

comment:52 Changed 9 years ago by daBowmore

Yeah still happens on my system. Switched to bits on wheels now permanently. Since Transmission is much better in so many aspects this really is a shame.

Whatever this livings124 says this IS transmission caused freeze. No other software causes this behaviour. Bit more constructive approach might help you in your life. Do you actually think we have tried to report this bug just to be mean, stupid, or blame you for something?

comment:53 follow-up: Changed 9 years ago by Gimp

  • Version changed from 1.34 to 1.50+

Alright, few things to ask here. I'm getting a problem similar to that described here however I have gone very far into figuring this out, and need a few things from others to confirm this.

Could someone with this problem please do the following: 1) Open Console.app 2) Click "All Messages" 3) Open Transmission 4) Start 2+ Torrents *downloading* 5) Watch Console.app.

What you're looking for are lines involving "kernel" and or "AppleYukon2". You should start seeing those lines BEFORE the computer locks up. As soon as you see two or three lines involving those, quickly pause the torrents that transmission is downloading. The lockup should cease.

I'd also like to know, Whether you do or don't get these messages, what computer are you on? (exact model please), how are you connected to the internet? (wireless? wired? what type? (802.11g, 802.11n, 10mbit, 100mbit, 1000mbit?)

From the people that I have spoken too all here indicates a hardware / kernel driver issue. Transmission itself is not the culprit, but it is something that transmission triggers. Hopefully what I learn here will help me find that trigger.

comment:54 in reply to: ↑ 53 Changed 9 years ago by gstein

  • Cc gstein@… added

Replying to Gimp:

Alright, few things to ask here. I'm getting a problem similar to that described here however I have gone very far into figuring this out, and need a few things from others to confirm this.

More than happy to help. As a fellow developer, I can help dig in where/when needed.

Another avenue to consider is instrumenting Transmission. Have it start recording more stats about its connections, response times, etc. And just keep logging those out. When the system locks up, then we can just look at the last logs it wrote out.

I'm on 1.51 (r7958).

...

What you're looking for are lines involving "kernel" and or "AppleYukon2". You should start seeing those lines BEFORE the computer locks up. As soon as you see two or three lines involving those, quickly pause the torrents that transmission is downloading. The lockup should cease.

Well, I'm not running it right now, but my system froze up an hour ago (again), and so I came looking to see why Transmission was doing that (yes, suspicious w.r.t. because my system never locks until I start Transmission; tho weirdly only in the past month).

Anyways, from /var/log/syslog, I have the following lines:

Mar  9 13:38:33 MBT kernel[0]: AppleYukon2: 00000000,00000001 sk98osx sky2 -  - sk98osx_sky2::replaceOrCopyPacket tried N times

These occur maybe every 30 seconds. That 00000001 looks like possibly a packet size and the timing leads me to believe it is a heartbeat. Probably from Adium. At 13:48:20, I started to get a huge swath of these:

Mar  9 13:48:20 MBT kernel[0]: AppleYukon2: 00000000,00000020 sk98osx sky2 -  - sk98osx_sky2::replaceOrCopyPacket tried N times

I get 19 of those messages up thru 13:48:28, with various values in that second 32-bit value. Several of 1d7, and the last is the largest at 3e8. Then I get two more lines:

Mar  9 13:52:32 MBT kernel[0]: ctl_enqueuedata: m_allocpacket_internal(8) failed
Mar  9 13:52:32 MBT kernel[0]: ALF ALERT: sockwall_cntl_releasecachedpath ctl_enqueuedata rts err 55

That's it for syslog. Nothing more until the first message of the (re)boot sequence.

I'd also like to know, Whether you do or don't get these messages, what computer are you on? (exact model please), how are you connected to the internet? (wireless? wired? what type? (802.11g, 802.11n, 10mbit, 100mbit, 1000mbit?)

MacBook Pro. 2.6 GHz Intel Core 2 Duo. 4GB RAM. OS 10.5.6. Connected via 100mbit to a hub to a cable modem.

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
media: autoselect (100baseTX <full-duplex,flow-control>) status: active

From the people that I have spoken too all here indicates a hardware / kernel driver issue. Transmission itself is not the culprit, but it is something that transmission triggers. Hopefully what I learn here will help me find that trigger.

Happy to help you dig into this. I can reproduce it quite reliably. Just start Transmission :-( ... feel free to email me about the problem (I'm at gmail; if you can't derive it from this post, just google for my address; I'm easy to find).

Cheers,
-g

comment:55 follow-up: Changed 9 years ago by stouset

I haven't experienced this freeze in awhile, but just had it occur on my system. Onset appeared "slower", with me able to open terminals and start new processes for a short while before some of the more debilitating effects kicked in. Internet access was the first thing to go, then starting new processes, then opening new windows for running new processes. Then running shell commands.

Some hopefully helpful notes:

  • I turned on Speed Limit today for the first time in a significant while. I believe there's a strong correlation here.
  • My hostname had been changed by the DHCP server to that of another machine on the network's. I am unsure of any potential correlation, but it seems worth noting. This fact does not seem to get in the way of pinging that box by its own hostname, nor is that box participating in any torrent traffic.
  • I have limited Console logs from the time of the event:
3/13/09 10:41:10 AM Unknown[16] Client application bug: DNSServiceResolve(mmanning@dev1._presence._tcp.local.) active for over two minutes. This places considerable burden on the network. 
3/13/09 10:51:08 AM /usr/sbin/ocspd[1994] starting
3/13/09 11:08:47 AM login[2058] USER_PROCESS: 2058 ttys000 
3/13/09 11:13:55 AM /Applications/Safari.app/Contents/MacOS/Safari[1939] write() failed: No buffer space available 
3/13/09 11:20:42 AM kernel ctl_enqueuedata: m_allocpacket_internal(8) failed 
3/13/09 11:20:42 AM kernel ALF ALERT: sockwall_cntl_releasecachedpath ctl_enqueuedata rts err 55 

comment:56 Changed 9 years ago by stouset

Also of interesting note. While I could still run console processes, I attempted to do a ps aux. This hung, but I was able to Ctrl+C and try again. ps ax did work, which tells me that username lookups on processes run into this apparent resource starvation bug. How helpful that is, I am unsure, but it still seems worth noting.

comment:57 in reply to: ↑ 55 Changed 9 years ago by gstein

Replying to stouset:

  • My hostname had been changed by the DHCP server to that of another machine on the network's. I am unsure of any potential correlation, but it seems worth noting. This fact does not seem to get in the way of pinging that box by its own hostname, nor is that box participating in any torrent traffic.

This is unrelated. I have had no changes in my IP in months, yet the freeze still happens.

comment:58 Changed 8 years ago by jfanelli

So, I have been having this identical problem (transmission locks up, entire OSX system locks up as a result). As it turns out, the culprit for me was NOT Transmission but my Seagate 1 TB hard disc and associated 'bad firmware'.

As I test I switched from Transmission to uTorrent. With uTorrent, my system would never lockup, but my torrents would completely stop every 5-10 minutes, requiring a restart of the application and often times a 'remount' of the USB drive containing my data volume (the Seagate drive).

After updating my Seagate firmware to the recommended version for my drive, Transmission is working flawless now. I hope this helps someone else..

FYI, my Seagate is an ST31000333AS that shipped to me in late 2008 with firmware version CC1F.

comment:59 Changed 8 years ago by azraeluk

My main drive is a seagate ST3500641AS P. And this is an issue that I have been seeing too.

comment:60 Changed 8 years ago by stouset

I'm using the MacBook? Pro built-in hard drive: a Fujitsu MHY2120BH.

comment:61 Changed 8 years ago by cornelius

I'm having this same problem too (beach ball, frozen OS X interface after I try to start programs from the dock, etc.). It happens with the built-in MacBook? Pro hard drive here too (mine is Hitachi HTS723225L9SA62). What I saw was trying to download this particular torrent (on its own with no other active downloads or uploads) consistently results in this problem:

http://releases.ubuntu.com/9.04/ubuntu-9.04-desktop-amd64.iso.torrent

I looked at Console.app (and clicked on All Messages), and there were no messages whatsoever after I started Transmission. I'm connected via wireless (802.11g) and this is a late-2008 15.4" MacBookPro5,1 @2.53 GHz.

The freeze happens no matter how much I change the settings (speed limits, number of connections, etc.) and it happens as early as within 1-2 minutes of starting Transmission. I haven't seen the problem with other torrents before. So that makes me think the issue could be specific to certain torrents. Hope that helps.

comment:62 Changed 8 years ago by cornelius

Can anybody confirm having this freezing problem with the above torrent?

In (only) one of the freezes (with that torrent), I got these kernel messages:

4/27/09 5:47:12 PM kernel ctl_enqueuedata: m_allocpacket_internal(8) failed
4/27/09 5:47:12 PM kernel ALF ALERT: sockwall_cntl_releasecachedpath ctl_enqueuedata rts err 55

These were the last messages on the log before the restart. BTW, this is with Transmission ver. 1.52 (8222).

comment:63 Changed 8 years ago by geneg1

FWIW, I had this freezing issue but followed the directions of a previous poster (namely: start Transmission, wait until the torrents finish verifying i.e. change from yellow to blue, then QUIT TRANSMISSION COMPLETELY, finally start Transmission again) and this completely resolved the issue for me.

It looks like when Transmission starts up after a crash and verifies torrents, something "very bad" happens that could ultimately lead to a system freeze unless Transmission is allowed to gracefully exit and restart again.

I hope that helps.

comment:64 Changed 8 years ago by self.pity

  • Cc aidan.kell.wigger@… added
  • Priority changed from Normal to Highest
  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Version changed from 1.51+ to 1.61+

well despite livings blowing me off on IRC and everyone else on this ticket i'm going to persist.

i dont know why livings is throwing his hands up and putting his head in the sand but the problem is real, its Transmission's fault (albeit an apple bug), and it is severe. i am not using this fucking app until this is fixed. i'm tired of watching my system writher in pain, putting it out of it's misery via power button, only do endure it again and again. this is retarded how unhelpful and rude livings is being with this. People have VOLUNTEERED to help if given instructions yet he just sidesteps it like it is some kind of vanity bug. ITS KILLING THE WHOLE FUCKING SYSTEM! so screw it. until this is fixed Transmission is toast.

comment:65 Changed 8 years ago by azraeluk

I am also suffering this problem frequently, and it is very painful and frustrating. I do want to see this bug fixed.

livings: I appreciate all your hard work, and I won't appreciate you any less if you don't fix this bug - though I might appreciate you more ;)

self.pity: I feel your frustration, and sympathise. But that doesn't excuse the inappropriate language and aggression.

comment:66 Changed 8 years ago by azraeluk

um.. that was supposed to be 'I might appreciate you more if you did fix it' (memo to self: preview is there for a reason)

comment:67 Changed 8 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

We were in the middle of a conversation in the irc room about this bug. I said it was an Apple bug and asked you what you want me to do. You then responded by quitting your client. That's not much of a conversation at all. You said yourself that it's an Apple bug, and even those in this thread agree (http://forum.transmissionbt.com/viewtopic.php?f=4&t=4564&start=375). So what is it I can do about it?

comment:68 Changed 8 years ago by livings124

  • Priority changed from Highest to Normal

comment:69 Changed 8 years ago by daBowmore

Well I still receive these ticket changes to my email and the little voice in my head wanted to return and say something.

Over three months without transmission and not a single freeze or whatsoever. Apple bug or not, but at least I can assume I'm now on the safe side by not using transmission.

Rather funny Apple bug that only comes up only with a single third party application :)

Cheers, I hope some day I can blame my product's bugs on the OS

comment:70 Changed 8 years ago by tempel

I really wish I could get off this mailing list because the maintainer of this bug clearly shows that he has no interest in looking into this, despite so many different suggestions. He can't even acknowledge the fact that it's transmission that is causing this apparently denial-of-service attack on the OS. Does someone know how to unsub from this report?

comment:71 Changed 8 years ago by livings124

If you read the thread I posted it does confirm that this is caused by the OS and what steps can be taken to ameliorate it. But then again, all OS's are bug free, so who knows, maybe I just like everyone attacking me.

There is proof on this being an OS problem and no one has given me any information otherwise. What do you want?

comment:72 follow-up: Changed 8 years ago by charles

self.pity: that irc conversation ended when livings asked you what you wanted him to do about it, and you disconnected without answering. What is your answer?

azraeluk: It is an OS X bug. Short of livings moving to Cupertino, how do you expect him to fix it?

daBowmore: re "I hope some day I can blame my product's bugs on the OS" ... No, you don't. It's rare, but when it happens, you're powerless to do anything but nod sympathetically when users start screaming.

tempel: you can unsub from this report by removing yourself from the CC list in the form.

comment:73 follow-up: Changed 8 years ago by tempel

to answer this one by livings: "I said it was an Apple bug and asked you what you want me to do."

What to do? To find out the _reason_ for Transmission triggering this supposed Apple bug so that it can be reported to Apple and getting fixed. Or so that you understand what is causing it in detail so that you can AVOID it.

Gosh, isn't that obvious?

What keeps you from investigating this? Can't you reproduce it? It should be fairly easy to reproduce by upping the limits to ridiculously high values and staring a busy torrent download. Works for me every time.

@charles: I cannot figure out how to subtract me here. There is a "add to cc" checkbox, but that's disabled already. I cannot find a command to remove me directly - is there one?

comment:74 in reply to: ↑ 73 Changed 8 years ago by livings124

Replying to tempel:

It should be fairly easy to reproduce by upping the limits to ridiculously high values and staring a busy torrent download. Works for me every time.

Don't set limits to ridiculously high values. This is what causes the problems. Your network and OS can't handle it. It is out of our hands.

comment:75 Changed 8 years ago by azraeluk

charles: I don't expect livings to fix it. I don't have the right to expect livings to do anything. But I would like if someone amended Transmission to not trigger the bug.

I'm not aware I have anything set to a ridiculously high value, if I can change some of my settings to never see this problem, that makes me happy. What do I need to change?

comment:76 in reply to: ↑ 72 ; follow-up: Changed 8 years ago by self.pity

  • Priority changed from Normal to Highest
  • Resolution invalid deleted
  • Status changed from closed to reopened

Replying to charles:

self.pity: that irc conversation ended when livings asked you what you wanted him to do about it, and you disconnected without answering. What is your answer?

well there must be some mistake because i did respond, many times in fact, and livings never responded. I thought he was just ignoring me. i must have been disconnected by an outside influence. I thought he was being childish. But if i was disconnected and didn't know it, then i am sorry for the attack on livings.

livings, sorry for the attack. i thought you were just ignoring me.

however, this bug is legitimate and it is Transmission's fault, despite being an Apple bug. No other app does this in my collection. That means this is a Transmission issue. Final. My answer? i don't know crap about writing code for applications or anything else for that matter so i cannot be specific. But i have common sense and i am rational. Common sense should dictate if there is a problem, fix it. You guys should work with someone who has this issue and knows what they are doing to find a solution. If that solution i re-writing some lines of code then so be it. Try. Try something. The rational thing to do is not throw your hands up and give up, leaving all of us with this issue out to dry.

comment:77 Changed 8 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

For the hundredth time, this is an issue with the operating system that is triggered by the network intensiveness of the bittorrent. As you said in our discussion, decreasing the number of peer connections helped - that is the best solution until Apple fixes it on their end. There is not much we can do besides forcing you to not use a lot of connections and torrents at once. I'm getting sick of the people that don't know the first thing of programming, computers, network connections, etc. telling us that it's our fault - it has been essentially proven that it is not.

comment:78 Changed 8 years ago by self.pity

That does not matter... but fuck it. you are obviously no damn help at all.

comment:79 Changed 8 years ago by livings124

It's like talking to a wall...

comment:80 Changed 8 years ago by self.pity

same goes for you.

comment:81 in reply to: ↑ 76 Changed 8 years ago by charles

Replying to self.pity:

If that solution is re-writing some lines of code then so be it. Try. Try something. The rational thing to do is not throw your hands up and give up, leaving all of us with this issue out to dry.

What is wrong with you? We've had 2600 svn commits in the last twelve months. That's about 7 commits per day. You're telling me with a straight face that we're afraid to write and rewrite code?

comment:82 follow-up: Changed 8 years ago by self.pity

No, no i'm not. I'm saying please fix something or give a reasonable solution. The only option left without completely handicapping Transmission, is to move to a new client.

I understand this is an Apple bug. I do. There must be a way around it.

comment:83 in reply to: ↑ 82 Changed 8 years ago by charles

comment:84 Changed 8 years ago by self.pity

i'm not the coder here.

comment:85 Changed 8 years ago by livings124

Did you even look at that forum post? It both proves it's an OS problem and gives a stop-gap solution.

comment:86 follow-up: Changed 8 years ago by self.pity

i don't care anymore. this is a standstill. i agree to disagree. sorry if i was an asshole, but i am very frustrated and tired of this issue.

*puts out hand for a shake*

comment:87 in reply to: ↑ 86 ; follow-up: Changed 8 years ago by charles

Replying to self.pity:

i don't care anymore. this is a standstill. i agree to disagree. sorry if i was an asshole, but i am very frustrated and tired of this issue.

*puts out hand for a shake*

Not a chance.

You've spent a lot of time cursing and yelling and basically saying we could fix this OS X bug in our code if only we would work harder. You registered for trac 'specifically' under the name self.pity to curse at us.

I just gave you a link that shows you exactly the OS X configuration changes that need to be made on your system to work around this problem. Your response was that you're "not the coder here". WTF? So coding this program for free isn't enough; livings and I also need to Geek Squad over to your house to change your OS X settings too?

WE HAVE GIVEN YOU THE WORKAROUND YOU REQUESTED

THE ONLY WAY THAT IS "A STANDSTILL" IS IF YOU ARE TOO MUCH OF AN IDIOT TO USE IT

No, I'm not ready to shake your hand.

comment:88 Changed 8 years ago by charles

To clarify: I'm used to being yelled at by users. I don't like it, but there are always a few unsatisfied customers no matter what business you're in, and the net magnifies that side of people, too.

What boggles me though is that, after your long temper tantrum, after I shoved the workaround under your nose so that you couldn't not see it anymore -- that's when you decided we were at an impasse and walked away. It's as if you didn't really want a fix, you just wanted to yell. That makes no sense to me.

comment:89 Changed 8 years ago by tempel

If I learn of a bug in my software, I find out the exact source of it, and if it is clear that it's a bug outside my responsibility, then I make an effort to report this bug to the responsible party, usually with a demo that shows the bug clearly in a way that rules out any errors on my side.

This is what we expect you to do. Why can't you do that? My and other people's impression is that you believe it's not your fault, yet you seem to have no proof other than saying: well, it works if we change these parameters, and that is enough to deduct it's not something we do wrong. Sure, a perfect OS would not even go down when it gets a denial-of-service attack like this appears to be one of. Still, to just say: it's not our fault, the OS is crappy, yet not making any efforts to remedy this, e.g. by reporting this to Apple in a way that Apple can reproduce and fix it, is, well, something I think we have a right to complain about.

If you do not have the resources or even the experience and understanding to do this, then say so. Then we can say: Oh, bummer, maybe someday someone will be able to grasp this.

However, the impression you give us is that you are just blaming others. And that doesn't put you in a good light. Seriously.

comment:90 in reply to: ↑ 87 Changed 8 years ago by self.pity

Replying to charles:

Replying to self.pity: *puts out hand for a shake*

Not a chance.

You've spent a lot of time cursing and yelling and basically saying we could fix this OS X bug in our code if only we would work harder. You registered for trac 'specifically' under the name self.pity to curse at us.

I just gave you a link that shows you exactly the OS X configuration changes that need to be made on your system to work around this problem. Your response was that you're "not the coder here". WTF? So coding this program for free isn't enough; livings and I also need to Geek Squad over to your house to change your OS X settings too?

...

No, I'm not ready to shake your hand.

okay another screw up on my part. i never saw that link. sorry again and i feel pretty fucking stupid for not seeing it. thanks.

*hand is still out*

comment:91 Changed 8 years ago by charles

  • Cc gstein@… aidan.kell.wigger@… removed

comment:92 Changed 8 years ago by jah

if it is an Apple issue, has a bug been filed on radar?

http://bugreport.apple.com

comment:93 Changed 8 years ago by gstein

  • Cc gstein@… added

comment:94 Changed 7 years ago by mandersen

Many of these comments are farcical. I don't know where the problem lies; it seems clear to me OSX should handle the situation better, certainly the Force Quit Application window should always be able to come up and be able to terminate applications causing problems, whatever the underlying cause. Windows handles this better. At any rate, I recently experienced this freezing problem after installing a security update on snow Leopard, relating the the PDF vulnerability in Preview I believe, and on restart, Transmission caused the freeze as soon as the "Turtle" (speed limit) mode was enabled. I am not certain if it has caused certain occasional slowdowns in the past, as I did not associate Transmission with it at the time. But now it is very clear and repeatable. On reading the forum post Transmission Causes Leopard Slow Death ( https://forum.transmissionbt.com/viewtopic.php?f=4&t=4564 ) and this ticket, I downloaded the latest stable overnight build (11187), turned off DHT (which was turned on recently to see if it would bring any more seeders; it is an advertised feature of various P2P clients, so must have some value), and reduced the Global and New Transfer limits to 100/10, and avoided the Turtle although I could even use that without trouble for the short periods I tried it. This seemed to work, Transmission and the system was stable. I ran iFreeMem to keep an eye on memory usage to see if posts suggesting Transmission was eating up memory when it occurred was true. I gradually increased the limits, and got the freeze again with Turtle mode at the Limit of 180/40. iFreeMem (which like other open apps kept working) showed no sudden decrease in free memory, and subsequent tests showed the same. Currently I have the limits set to 160/40 and avoid the turtle, and have no problems. I have not applied the sysctl fix, as I wish to avoid messing with deep and hidden system settings like this and would prefer if Transmission not apply it either, as it is not clear what the optimal settings for the socket buffers are and if other network utilities and services (eg just accessing external drives or networked computers) might be adversely affected. Upon reading up on what it is, I did apply some other settings not throttling the socket buffers. On the advice of this article ( http://www.macgeekery.com/tips/configuration/mac_os_x_network_tuning_guide_revisited ) I set the TCP Maximum Segment Size to 1440 for instance. This article provides some good info on sysctl in OSX in general. For now I am happy with this; Turtle Mode is risky and I will avoid it, other than that things are stable. I don't know if the Mac uTorrent client has the same issue, as I'm not even sure if it currently supports throttling like the Windows version does. There is no cute Turtle icon to click. I never had a problem with either in my modest Torrenting needs until now. I hope the issue is resolved wherever the problem exists (somehow I didn't have the issue until the security patch).

comment:95 Changed 7 years ago by georg123

I added about 30 torrents of about 7GB each to download last night, and my iMac has completely frozen 5 times since. I've had to hard reboot every time.

comment:97 in reply to: ↑ 96 Changed 6 years ago by x190

Shouldn't Transmission try to control its peer socket buffer size using "setsockopt" in fdlimit.c (tr_fdSocketCreate--Line 664 r13023)? Leaving this entirely up to the OS may result in much larger than necessary buffers and thus contribute to this issue. For example, in Line 691 "getsockopt" returns 131070 for "SO_SNDBUF" and Line 693 "SO_RCVBUF" is 262140 on my system.

Please see forum link for additional info.

Last edited 6 years ago by x190 (previous) (diff)

comment:98 Changed 6 years ago by x190

  • Priority changed from Highest to Normal
  • Resolution invalid deleted
  • Severity changed from Critical to Normal
  • Status changed from closed to reopened

Reopened so that comment:96 and comment:97 can be evaluated.

comment:100 Changed 6 years ago by x190

  • Component changed from Mac Client to libtransmission

comment:101 Changed 6 years ago by livings124

  • Owner livings124 deleted
  • Status changed from reopened to new
  • Summary changed from Mac OS X: Transmission causes system-wide freeze to Transmission causes system-wide freeze

comment:102 follow-up: Changed 6 years ago by jordan

  • Component changed from libtransmission to Mac Client
  • Resolution set to invalid
  • Status changed from new to closed
  • Summary changed from Transmission causes system-wide freeze to Mac OS X: Transmission causes system-wide freeze

This ticket is three years old, uTP support is five months old. comment:96 and comment:97, even if valid, are not the root cause of this ticket.

Restoring this ticket to its previous state.

comment:103 in reply to: ↑ 102 ; follow-up: Changed 6 years ago by x190

Replying to jordan:

This ticket is three years old, uTP support is five months old. comment:96 and comment:97, even if valid, are not the root cause of this ticket.

And what is the root cause of this problem? The issue continues to manifest itself.

https://forum.transmissionbt.com/viewtopic.php?f=4&t=12446

comment:104 in reply to: ↑ 103 Changed 6 years ago by jordan

Replying to x190:

And what is the root cause of this problem? The issue continues to manifest itself.

Beats me, I've never seen this happen on Linux in the 4.5 years I've been using Transmission. Because of that, my guess is that OS X has problems with the network or disk IO load generated by P2P, but that doesn't explain why that happens to only a subset of users.

comment:105 follow-up: Changed 6 years ago by x190

Jordan replying to x190:

This ticket is three years old, uTP support is five months old. comment:96 and comment:97, even if valid, are not the root cause of this ticket.

Jordan replying to x190:

And what is the root cause of this problem? The issue continues to manifest itself.

Beats me

Arglebargle!

http://www.linuxforums.org/forum/suse-linux/67790-p2p-torrent-hangs-suse-10-10-1-a.html

All I'm saying is that we know that reducing global connections helps, so why not force the OS to use less memory per connection. You already do this for trackers (web.c) and (partially) for isSeed (net.c). Aside from the fact that you have an unhealthy relationship with Apple, I would think that you would want to try a fairly easy possible improvement. Or not. :-) Also I suggested in the forum, some time ago, trying to slow down the rate of connections by changing the following in peer-mgr.c.

/* max number of peers to ask for per second overall.
     * this throttle is to avoid overloading the router */
    MAX_CONNECTIONS_PER_SECOND = 12,

Then again, maybe the real money's in linux...

Last edited 6 years ago by x190 (previous) (diff)

comment:106 in reply to: ↑ 105 Changed 6 years ago by jordan

Replying to x190:

Jordan replying to x190:

This ticket is three years old, uTP support is five months old. comment:96 and comment:97, even if valid, are not the root cause of this ticket.

Jordan replying to x190:

And what is the root cause of this problem? The issue continues to manifest itself.

Beats me

Arglebargle!

That seems like a random thing to say, and something that you keep saying in the forums. You seem to keep saying it because I once used it as a placeholder in the code when IIRC I needed a nonsense string.

http://www.linuxforums.org/forum/suse-linux/67790-p2p-torrent-hangs-suse-10-10-1-a.html

Okay, so someone encountered firewall-related system freezes when using KTorrent and Azureus... in 2006. And that's relevant because...?

All I'm saying is that we know that reducing global connections helps, so why not force the OS to use less memory per connection. You already do this for trackers (web.c) and (partially) for isSeed (net.c).

We reduce the socket's buffer size when we know the relationship between the peers before connecting -- when we're a seed, we know we don't need as much of a read buffer. When we're connecting to a tracker to scrape or announce, we don't need much of a write buffer. Reducing the buffer size for all sockets in general, though, is a bad idea. Go back and look at Juliusz' rationale for the buffer size he chose.

Aside from the fact that you have an unhealthy relationship with Apple,

Another random thing to say. I don't have any relationship with Apple at all -- I've never been there, haven't ever spoken to anyone there, and don't own any Apple products. On the other hand, I admire their focus on usability and their ability to create new markets... not that any of this has anything to do with this ticket.

I would think that you would want to try a fairly easy possible improvement. Or not. :-)

Possible is the key here. If uDP/uTP buffer sizes were materially contributing to this issue, we would have seen a large increase in people reporting this problem over the last six months since we added uTP enabled by default. That hasn't happened.

Also I suggested in the forum, some time ago, trying to slow down the rate of connections by changing the following in peer-mgr.c.

/* max number of peers to ask for per second overall.
     * this throttle is to avoid overloading the router */
    MAX_CONNECTIONS_PER_SECOND = 12,

This is a more realistic suggestion, but that number is already a tradeoff. Lowering that number significantly slows down the time it takes for torrents to reach a good speed after being added to Transmission.

Also, you can already lower that number by at least four ways in the preferences: (1) lowering the per-session maximum peers, (2) lowering the per-torrent maximum peers, (3) setting the top speed limit per torrent, and (4) setting the top speed limit per session.

Even IF this were the problem -- and I don't think it is -- should we make things slower for everyone, just so that a dozen people don't see this problem anymore? And if we do, will you be here in another ticket six months from now telling me that the number needs to be higher? :)

Then again, maybe the real money's in linux...

Another random statement. Unless you're trying to needle me or to play some mind game, I don't really understand the point of these.

Last edited 6 years ago by jordan (previous) (diff)

comment:107 Changed 6 years ago by x190

My apologies for the somewhat tangential references. My purpose is only to offer suggestions for improving the interaction between Transmission and macosx. I do want to make it clear that comment:96 and comment:97 have nothing at all to do with µTP. A more appropriate reference might be "the parodyr fix" from the "leopard slow death" forum thread. This was a concept endorsed by yourself at the time, however, from what I can gather, whether one messes with system defaults or not, nothing would be effective without the corresponding appropriate coding in Transmission.

For users of µTP, perhaps none of the above is applicable, as that is, at least as I understand it, based on a total buffer size, unless macosx is getting carried away with soft vs. hard limits.

comment:108 Changed 6 years ago by x190

"net.inet.tcp.recvspace and net.inet.tcp.sendspace control how much buffer space is allotted per socket connection, per direction. This is how much data the kernel will cache on a socket while the application chews on it. For data streams over a slow link (even 10Mb enet) this won’t matter as the processor can keep up rather well. On really fast links like gigabit, this is essential."

"Just be very sure to update kern.ipc.maxsockbuf to match the total of both settings before changing these settings, especially in sysctl.conf. If you do not, then the kernel will attempt to allocate the buffer space for the two buffers and run out of space, preventing essential services like NetInfo? from making a loopback connection and preventing startup and/or login."

http://www.macgeekery.com/tips/configuration/mac_os_x_network_tuning_guide_revisited

The quotes are talking about making sysctl settings adjustments, but still might describe what happens with a lot of connections being made while torrenting.

comment:109 Changed 6 years ago by pathetic_loser

If modern multi-tasking system freezes due to just usual user-mode application, this is clearly bug in that operating system itself. The idea of multitasking OS with division to kernel and user modes is that in no way user mode code should be able to harm kernel, even if user mode code goes mad. In *nix like the only exception is root processes, who may ask kernel to do some harmful things on their behalf.

Note: See TracTickets for help on using tickets.