Does not wanna end process and freezes at 0% CPU Usage and Memory stays locked

[jefrotone]

OK, So I've already assessed that the problem was my memory. Scratch that. Changed all the sticks in and out, nothing. Did memtest, nothing. Reset bios, nothing. Still hangs on close. Just sits there, memory locked and slowly goes down. Cannot end process or end process tree. Will not disappear until I reboot and try again. I can still run other programs just fine and watch movies and continue any work. If I close it and run some torrents, it will not pop up. Let me know what you need and I'll throw it up here.

12GIGS RAM CPU i5 2700k Windows 7 x64 SP1 with all updates (which I think is the culprit as I'm reinstalling windows ATM) Install is on a SSD (not sure if that matters) Changed disk cache to 16MB instead of (AUTO) - still hangs and freezes

[sledgehammer999]

This has been reported before. Not actually a clue what happens here. I suspect that libtorrent deadlocks somewhere. What version of qbt do you use?

[jefrotone]

qbittorrent 3.1.5 ... I just re-installed windows and didn't update anything and it still does it, so updates are not breaking it... also , i disabled ipv6 and it somehow disappeared. I used these commands and it went away:

netsh interface ipv6 6to4 set state disabled default netsh interface ipv6 isatap set state disabled netsh interface ipv6 set teredo disabled

maybe ipv6 is causing it to freeze? Also, I have ESET NOD32 firewall running v7, Allowed all outgoing connections and still does it.. disabled and still does it.

====== EDIT ==== now it actually shuts down... weird, I guess it was IPV6 that was messing with it... it now ends when I exit the program, and also got incoming connections with port 6881, even with no torrents. But that's irrelevant to the situation.

===== EDIT 2 ====

Solution is to disable IPV6 completely using these commands.

netsh interface ipv6 6to4 set state disabled default netsh interface ipv6 isatap set state disabled netsh interface ipv6 set teredo disabled

Let me know if this works for anyone else...

[sledgehammer999]

Cool. Thanks for debugging. I'll need to forward this to the libtorrent author.

[sledgehammer999]

http://code.google.com/p/libtorrent/issues/detail?id=573

[arvidn]

there was a bug in windows (I forget which version vista or 7) for a long time where certain IPv6 interactions would cause a system call to hang in the kernel indefinitely. This has since been fixed in a service pack, iirc. is anyone that's seeing this not running the latest service pack? and which windows versions are you using?

[sledgehammer999]

Windows 7 x64 SP1 with all updates (which I think is the culprit as I'm reinstalling windows ATM)

and after a while he says:

I just re-installed windows and didn't update anything and it still does it, so updates are not breaking it

[jefrotone]

So, after a few torrents, it still isnt working properly. It worked temporarily using the ipv6 fix. But now upgrading to v3.1.8 its broken again. Very sad, I really liked this app. Let me know what I could use to see what the program is doing in real-time. I'll upload the debug info here.

[sledgehammer999]

Maybe getting a backtrace fixes this. Try this: Help me get a backtrace of what is actually happening.

1. Install ProcDump
2. In a command prompt: <path-to-proc-dump>\procdump.exe -x qbt.dmp <path-to-qbt>\qbittorrent.exe -h e.g .c:\procdump\procdump.exe -x qbt.dmp c:\program files\qbittorrent.exe

This may not create a minidump for you. Please play with the command line args mentioned in the procdump link. If you are not that advanced, tell me and I'll try to help you.

Send me the dump at sledgehammer999 at qbittorrent dot org

[alfrix]

dupe of #670

[KwikOne]

ok, I only started having this problem (difference = cpu and io usage looks normal for hours) after updating to 3.1.8 (portable) (Win 7 SP1 x64 all updates). One thing I tried was killing threads to see if it would shut down. Well, all threads could be killed except 1 thread (address = start_null_buffers_receive_op@win_iocp_socket_sservice_base@detail@asio@boost@@IAEXAAUbase_implementation_type@1234@HPAVreactor_op@234@@Z+0x133a79). That thread (of several with that address) was the only one that would not kill. I can take a mini-dump (or full if desired) and send it - but who should i send it to? (sledgehammer999 had indicated to someone else to send him a dump so should i send it there?)

[sledgehammer999]

Does disabling ipv6, as mentioned above, work? You could send me the dump but I am not sure I'll be able to make windbg display it...

[v6bit]

@sledgehammer999 Disabling ipv6 doesn't work on my computer. the qbt3.1.8 can't be killed and I have sent the dump to you

[jefrotone]

Still need me to send a crash dump to you? BTW, it completely stopped working now .It doesn't quit now and fails to quit . ipv6 fix doesn't work either.

[v6bit]

@jefrotone do you test the older version?

[jefrotone]

Going to update and report back in a bit

[arvidn]

sledgehammer, if you could provide a build with debug symbols, I believe TaskManager can take snapshots of stack traces, which is exactly what we want for a deadlock like this.

If it is a deadlock that is. It's also possible that libtorrent gets stuck waiting for all asynchronous operations. given that a thread was not killable, it may indicate a deeper deadlock-issue with the kernel however. A build with asio-debugging=on would help track that down (but that also requires a terminal for the output).

[v6bit]

@arvidn I can build the debug version libtorrent and qbittorrent on my computer, but I don't know how to analyze the deadlock issue

[jefrotone]

Tell us what we need to do and I'll do it

[v6bit]

Built libtorrent with vc2010 using bjam -q --without-python --toolset=msvc variant=debug encryption=openssl link=static runtime-link=shared logging=none geoip=static dht-support=on boost=source asio-debugging=on

don't know how to provide terminal for output:(

[v6bit]

set breakpoint at void MainWindow::shutdownCleanUp() { when execute delete m_instance; of QBtSession::drop(), the qbt freeze

continue and find in libtorrent

session_impl::~session_impl() { m_io_service.post(boost::bind(&session_impl::abort, this));

    // we need to wait for the disk-io thread to
    // die first, to make sure it won't post any
    // more messages to the io_service containing references
    // to disk_io_pool inside the disk_io_thread. Once
    // the main thread has handled all the outstanding requests
    // we know it's safe to destruct the disk thread.
    m_disk_thread.join();

---

when exectue m_disk_thread.join(); the qbt keeps waiting

[sledgehammer999]

For anyone only reading the emails github sends on this bug: The previous poster's comment may be partially hidden in the email(gmail hides part of it). It contains info on where the code blocks.

So arvidn, you may want to visit the actual bug report on github to see the full comment(if you already haven't done so).

[arvidn]

when waiting for the disk thread, what is the disk thread doing? i.e. switch thread to the one that's somewhere in disk_io_thread.cpp and possibly has disk_io_thread::thread_fun or something like that in its stack. the take a stack trace of where it is. in a previous post it looks like there may be a disk system call that hangs.

[jefrotone]

Wait a minute , I forgot to mention I was using a ssd. Does the disk system call have something to do with it ?

[v6bit]

I take a snapshot

PS. I use ssd too

[arvidn]

oh.. no, that just looks like a libtorrent bug. an annoying one. Is this reliably reproducible for you? you're on libtorrent 0.16.x I take it, right? This weekend I will instrument libtorrent to try to track down this issue.

[v6bit]

Yes, reproducible on my computer, just run qbt afte reboot computer and there it is. if you install qq(a chinese IM software), you can control my computer to debug remotely. my os is win8 and have SSD disk. boost 1.55 libtorrent 0.16.14 qbittorrent3.1.8 vc2010 qt4.8.5

[arvidn]

Here's a patch that adds the ability for libtorrent to log disk jobs as they are posted, processed and returned. I think this would help track down this issue. sledgehammer, could you please make a build for v6bit? (or maybe you can build yourself). You need to define TORRENT_JOB_LOGGING when building.

http://dpaste.com/1624431/plain/

please post the log from a run where you get the hang. if possible, try to keep the run as short as possible.

[sledgehammer999]

v6bit, if you can't build it tell me to do it.

[v6bit]

After patch -p0 <patch.log, I built libtorrent using

bjam -q --without-python --toolset=msvc variant=debug encryption=openssl link=static runtime-link=shared logging=none geoip=static dht-support=on boost=source asio-debugging=on define=TORRENT_JOB_LOGGING

when quit the qbittorrent, I got the disk_jobs.log

00:00:00.000 POST update_settings 00:00:00.000 POP update_settings 00:00:00.000 PERFORM update_settings 00:00:00.000 COMPLETE update_settings 00:00:10.431 POP abort_thread 00:00:10.431 PERFORM abort_thread 00:00:10.431 COMPLETE abort_thread 00:00:10.431 FLUSHING 00:00:10.431 RELEASING

00:00:10.431 THREAD-EXIT

the debug window continue output

==== Waiting to shut down: 215 ==== conn-queue: 0 connecting: 0 timeout (next: -227625.968750 max: 0.000000)

udp_socket::on_read: (1) 0: print_backtrace 1: libtorrent::add_outstanding_async 2: libtorrent::udp_socket::bind 3: libtorrent::aux::session_impl::open_listen_port 4: libtorrent::aux::session_impl::init 5: libtorrent::aux::session_impl::main_thread 6: boost::_mfi::mf0<void,libtorrent::aux::session_impl>::operator() 7: boost::_bi::list1<boost::_bi::value<libtorrent::aux::session_impl > >::operator()<libtorrent::upnp ,boost::_mfi::mf0<libtorrent::upnp ,libtorrent::aux::session_impl>,boost::_bi::list0> 8: boost::_bi::bind_t<libtorrent::upnp ,boost::_mfi::mf0<libtorrent::upnp ,libtorrent::aux::session_impl>,boost::_bi::list1<boost::_bi::value<libtorrent::aux::session_impl > > >::operator() 9: boost::asio::detail::win_thread::funcboost::_bi::bind_t<void,boost::_mfi::mf0<void,libtorrent::aux::session_impl,boost::_bi::list1<boost::_bi::value<libtorrent::aux::session_impl *> > > >::run

---

the whole output file is here http://pan.baidu.com/s/1bnd5PBT

[arvidn]

printing that stacktrace over and over again is caused by a bug in asio-debugging. it has been fixed in a later 0.16 release (0.16.14 iirc). Another thing worth trying is to build using libtorrent 1.0 (trunk, it isn't released as 1.0 yet), I believe the disk thread is a bit more robust there. I will take a look at the log file, the hosting site seems pretty slow for me though, hopefully I'll be able to download it.

[v6bit]

where can I find the libtorrent 1.0? I can build one again. I send the log file to your email address arvid#rasterbar.com, please check it out

[arvidn]

it's trunk in the libtorrent svn repository. you can find it on sourceforge and google code.

[v6bit]

I browser the svn of sourceforge and only find the latest version is 0.16.15

[sledgehammer999]

svn trunk is the libtorrent 1.0.0

[v6bit]

Sorry, I haven't used svn before. I run svn checkout svn://svn.code.sf.net/p/libtorrent/code/trunk libtorrent-code then how to switch to 1.0.0? Would you please give me the real command?

[sledgehammer999]

Just think trunk as another branch (the master branch).

With that command you used you already have checked out the correct code (check version.hpp to confirm)

Now apply the patch and build.

[v6bit]

Just svn checkout svn://svn.code.sf.net/p/libtorrent/code/trunk libtorrent-code and without patch, I compile and failed

bjam -q --without-python --toolset=msvc variant=debug encryption=openssl link=static runtime-link=shared logging=none geoip=static dht-support=on boost=source asio-debugging=on define=TORRENT_JOB_LOGGING

Error message is D:/boost/tools/build/v2/build\feature.jam:325: in validate-feature from module feature error: unknown feature ""

[sledgehammer999]

try dht=on

[v6bit]

new error comes out :(

    D:\6xvod\libtorrent\include\libtorrent/kademlia/item.hpp(96) : see refer

ence to function template instantiation 'std::pair<_Ty1,_Ty2>::pair<int,int>(_Ot her1 &&,_Other2 &&)' being compiled with [ _Ty1=const char *, _Ty2=int, _Other1=int, _Other2=int ] d:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\utility(163) : er ror C2439: 'std::_Pair_base<_Ty1,_Ty2>::first' : member could not be initialized

    with
    [
        _Ty1=const char *,
        _Ty2=int
    ]
    d:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\utility(1

66) : see declaration of 'std::_Pair_base<_Ty1,_Ty2>::first' with [ _Ty1=const char *, _Ty2=int ]

call "D:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"

x86 >nul cl /Zm800 -nologo @"bin\msvc-10.0\debug\asio-debugging-on\boost-source\encryptio n-openssl\geoip-static\link-static\threading-multi\src\session.obj.rsp"

...failed compile-c-c++ bin\msvc-10.0\debug\asio-debugging-on\boost-source\encry ption-openssl\geoip-static\link-static\threading-multi\src\session.obj... ...failed updating 1 target... ...updated 52 targets...

[arvidn]

I believe I fixed that already. I must have checked it in right after you checked out trunk. try "svn up" in your checkout.

[v6bit]

Built qbt 3.2.0alpha with libtorrent 1.0.0 and can quit successfully! It works well so far

[arvidn]

ah, right. This moved to being a flag instead. I'm guessing that this is only used for displaying of peers purposes, and that you can probably comment out any code that relies in this being set.

sledgehammer, sorry for changing this. I was expecting that nobody actually was using this field. What happened was that since the utp connection really is orthogonal to whether it's a bitorrent peer or something else, this was moved to the flags field, as utp_socket

On Mon, Feb 17, 2014 at 8:04 PM, v6bit notifications@github.com wrote:

libtorrent 1.0.0 built successfully, but qbittorrent failed

D:\6xvod\qBittorrent\src\properties\peerlistwidget.cpp:449: 错误:C2039: 'bittorrent_utp' : is not a member of 'libtorrent::peer_info'

I used the master of qbittorrent git

— Reply to this email directly or view it on GitHubhttps://github.com/qbittorrent/qBittorrent/issues/1332#issuecomment-35350709 .

Arvid Norberg

[arvidn]

that's great to hear. I'm a bit inclined to rather release 1.0 sooner than digging too deep into this issue. it may be pretty deep. Please let us know if what you think, if 1.0 works reliably.

On Mon, Feb 17, 2014 at 8:28 PM, v6bit notifications@github.com wrote:

Built qbt 3.2.0alpha with libtorrent 1.0.0 and can quit successfully! It works well so far

— Reply to this email directly or view it on GitHubhttps://github.com/qbittorrent/qBittorrent/issues/1332#issuecomment-35351638 .

Arvid Norberg

[v6bit]

Wow, 1.0 brings so many new things.

• improved support for web seeds that don't support keep-alive

Already support web seed redirecting for multi-files torrent?

[v6bit]

I find the problem is relevant with network environment. I have tested several times on the same notebook in different network. everythins is ok in this network

problem appears in this network

[arvidn]

actually, maybe it isn't the disk thread after all. that screenshot you had with libtorrent in the debugger. Could you do that again but look at the main thread? which thread is it waiting for?

If it's the main thread, running with asio-debugging=on may be helpful. Remember that there were some version before 0.16.14 iirc where asio debugging was broken on windows (with the symptom you posted earlier). Please try a later version. Does it point out any asynchronous operation that libtorrent is waiting for?

[v6bit]

I download libtorrent 0.16.15 and compile using bjam -q --without-python --toolset=msvc variant=debug encryption=openssl link=static runtime-link=shared logging=none geoip=static dht-support=on boost=source asio-debugging=on define=TORRENT_JOB_LOGGING

There is no debuging information output about the asio like before :(

[jefrotone]

Whats the status on this ? I haven't been at my computer for a while, had to do some networking out of country. Let me know what I can do to help. I'm about to download the latest 3.19 that you have on the site and test it. Will report back here briefly.

[CourtArtanis]

Issue still exists, I'm experiencing this also, as of 18/9/14, latest version of qbittorrent. Win7 x64

Also, this is not a Bitdefender ONLY related issue. I'm running avast :dancer:

[chrishirst]

Also, this is not a Bitdefender related issue. Nice attempt, but I'm running avast

Avast and BitDefender do the same kind of operation, they BOTH intercept incoming packets which slows them down and/or halts them completely.