Jump to content

Greg Hazel

Established Members
  • Posts

    725
  • Joined

  • Last visited

Everything posted by Greg Hazel

  1. "Fluent"? Anyway, sounds like 1.8 is behaving correctly.
  2. Is this a mutlifile torrent? 1.8 is smart enough to disconnect from another 1.8 if the clients would not download from each other (for example one peer is a seed, and the other has all the incomplete files skipped). 1.7.7 and other clients will stay connected.
  3. Nope, not the "Vista bug". You have the now most common cause of crashes in uTorrent - nvLsp.dll (NVIDIA Application Filter).
  4. well, i'm up, and µtorrent is still running BUT, i must say, upgrading is the first thing i did when these crashes were occuring so i already was running build 12495, and the crashes still happened ... Can you post your crash dumps? How do you know it's the "Vista bug"?
  5. The newest version (12495) should fix this, even if UPnP is enabled.
  6. uTorrent mostly protected against this - if an outgoing connection was made and a previous connection (incoming or outgoing) to the same peer ID already existed, it would drop the new connection. The missing piece was if two incoming connections from the same peer ID arrived, it would not drop one of them. So in some cases two connections to the same peer, one over IPv4 and one over IPv6 for example, could be made. The new behaviour is to always enforce one connection per peer ID. This is in addition to allow_same_ip.
  7. These are mostly the "Vista bug". Try disabling UPnP, let us know if that helps. Also, you have "Lingvo Keyboard Hook" - could you try disabling or uninstalling that? Btw, this thread is for 1.8.1, so you should at least run that if you are going to report bugs here.
  8. It sounds like WINE is correctly parsing IPv6 addresses with WSAStringToAddressA (which is how I detect that the IPv6 stack is enabled), but WINE is failing to format with WSAAddressToStringA. File a bug with them?
  9. Well, those are different IPs, which is why this occurs. I'll add protection against it in the future.
  10. Try disabling "UPnP port mapping" and see if that helps. Let us know.
  11. That minidump was not a uTorrent crash, it was a Windows crash. Yes, I believe the "sr" module, whatever that is, was involved in the Windows crash.
  12. f7981a40 8054a583 nt!KeBugCheckEx+0x1b f7981a90 f722dac9 nt!ExFreePoolWithTag+0x2a3 f7981aa0 f7235b46 Fastfat!FatFreeFcb+0x10 f7981aac f723201a Fastfat!FatDeleteCcb_Real+0x15 f7981b3c f723185c Fastfat!FatCommonClose+0x1b2 f7981ba0 804eeeb1 Fastfat!FatFsdClose+0xbd f7981bb0 f7250459 nt!IopfCallDriver+0x31 WARNING: Stack unwind information not available. Following frames may be wrong. f7981bb8 804eeeb1 sr+0x459 f7981c0c 804eeeb1 nt!IopfCallDriver+0x31 f7981c1c 805827bc nt!IopfCallDriver+0x31 f7981c54 805b9e2d nt!IopDeleteFile+0x132 f7981c70 805257b8 nt!ObpRemoveObjectRoutine+0xdf f7981c88 804e1b6e nt!ObfDereferenceObject+0x4c f7981c8c 804e1ab6 nt!CcPerformReadAhead+0x330 f7981d34 804e7062 nt!CcPerformReadAhead+0x278 f7981d7c 80537757 nt!CcWorkerThread+0x150 f7981dac 805ce794 nt!ExpWorkerThread+0xef f7981ddc 805450ce nt!PspSystemThreadStartup+0x34 00000000 00000000 nt!KiThreadStartup+0x16 What is "sr"? sr.dll? Do you have that on your system? Anyway, not a uT issue.
  13. We found a bug in that area that will be resolved in the next version. Here's hoping this is fixed!
  14. Yes, please submit some more as you get them.
  15. Fantastic! Can you narrow down the build where it started?
  16. Interesting finding jsillup, gLes! We may find a work around for this yet!
  17. Indeed, this dump is a "Vista bug" crash. See "Fault Module Name: hnetcfg.dll_unloaded" there as well.
  18. What are your per-torrent and global connection limits? How many torrents are running?
  19. Well, the problem is there was a significant amount of outstanding disk IO. So much that 10 seconds was not sufficient for it to complete. bt.graceful_shutdown waits until it has all finished, but that could take a very long time. It's a trade-off between updating fairly fast and then rechecking, vs. taking a long time to update then not needing to recheck.
  20. Have you tried enabling bt.graceful_shutdown?
  21. Yes, it was added for the performance benefits. There is a slight hesitation with making it on by default. It goes something like this:
  22. This problem is still present. I have program settings stored along with executable. .torrent files downloaded via magnet links are also stored there instead of directory specified in Preferences. Er, yeah. There was a bug there - fixed, thanks!
  23. The button is greyed out if you have a valid Teredo address. As Firon said, it stays lit if you do not, to allow you to reset the Teredo settings.
×
×
  • Create New...