lock in session_impl destructor

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Prerequisite 1: Have DHT enabled
2. Prerequisite 2: Have a paused torrent added to the session with params 
(p.paused = true; p.auto_managed = false;)
3. Never start this torrent download (just leave it in pause)
4. Destroy the session and it will lock (never exit)

What is the expected output? What do you see instead?
Should exit normally

What version of the product are you using? On what operating system?
v0.15.4 on Linux

Please provide any additional information below.
I hit CTRL+C and got a backtrace for all threads: http://pastebin.ca/2003542

If I disable DHT, then libtorrent exits correctly (and really fast). If the 
torrent is ever started during the session, it will exit correctly (it must 
stay paused after adding it to the session in paused state). Having other 
running torrents does not change anything, it will lock on exit as long as 
there is one such torrent that was paused the whole time.

I tried to look at my code to understand what could happen but I'm running out 
of ideas so I thought I would file a ticket and see if you have an idea.

Original issue reported on code.google.com by dch...@gmail.com on 27 Nov 2010 at 8:49

[GoogleCodeExporter]

Also note that I'm using the following session setting:
sessionSettings.use_dht_as_fallback = false;

Original comment by dch...@gmail.com on 27 Nov 2010 at 8:51

[GoogleCodeExporter]

Thanks, I'll take a look right away. This is almost always caused by some timer 
or other async operation which is not properly cancelled on shut down.

Original comment by arvid.no...@gmail.com on 27 Nov 2010 at 5:53

• Changed state: Accepted

[GoogleCodeExporter]

I can't reproduce this. I tried modifying client_test.cpp in the RC_0_15 
branch, both on mac and linux, with DHT enabled, adding one torrent in paused 
mode and then quitting. It quits immediately.

Is there any way you can provide a minimal code snippet that causes this freeze?

Original comment by arvid.no...@gmail.com on 28 Nov 2010 at 1:28

[GoogleCodeExporter]

I just tested the actual 0.15.4 tag as well, same result. It exits immediately. 
Does it reproduce consistently for you?

Original comment by arvid.no...@gmail.com on 28 Nov 2010 at 3:23

[GoogleCodeExporter]

I just checked in some debugging code to trunk, which is enabled by defining 
TORRENT_ASIO_DEBUGGING.

If this happens in trunk as well, that would probably be a simple way to figure 
out why it hangs (it will be printed to stdout)

Original comment by arvid.no...@gmail.com on 28 Nov 2010 at 4:55

[GoogleCodeExporter]

Yes, I can reproduce it consistently so do a few other qBittorrent users. This 
makes me think it is qBittorrent related but I really have no idea of the 
origin.

I will test trunk and see if it provides useful output.

Original comment by dch...@gmail.com on 28 Nov 2010 at 8:10

[GoogleCodeExporter]

qBittorrent does not compile against trunk, see:

In file included from ./misc.h:45:0,
                 from ./filesystemwatcher.h:23,
                 from qtlibtorrent/qbtsession.cpp:41:
/usr/include/libtorrent/torrent_info.hpp:59:35: fatal error: 
libtorrent/copy_ptr.hpp: No such file or directory
compilation terminated.
In file included from ./misc.h:45:0,
                 from qtlibtorrent/qtorrenthandle.cpp:37:
/usr/include/libtorrent/torrent_info.hpp:59:35: fatal error: 
libtorrent/copy_ptr.hpp: No such file or directory
compilation terminated.

Could you please look into it?

Original comment by dch...@gmail.com on 28 Nov 2010 at 8:19

[GoogleCodeExporter]

Are you sure you properly checked out all of trunk?

$ svn ls include/libtorrent | grep copy_ptr
copy_ptr.hpp

either way, copy_ptr isn't used anymore (afaik), so it should be safe to just 
uncomment that include as well.

Original comment by arvid.no...@gmail.com on 28 Nov 2010 at 8:51

[GoogleCodeExporter]

oh, it is actually still in use.

Original comment by arvid.no...@gmail.com on 28 Nov 2010 at 8:52

[GoogleCodeExporter]

Arvid, the files are in the source. They are just not installed by the makefile.

I'm currently porting qBittorrent to libtorrent v0.16 (quite a lot of work...)

Original comment by dch...@gmail.com on 28 Nov 2010 at 10:21

[GoogleCodeExporter]

Ok, so the interesting thing is that I cannot reproduce the issue with 
libtorrent trunk. If I go back to latest RC_0_15, I can still reproduce it 
consistently though.

Original comment by dch...@gmail.com on 28 Nov 2010 at 10:29

[GoogleCodeExporter]

It seems the following file is not installed either:
libtorrent/sliding_average.hpp

Original comment by dch...@gmail.com on 28 Nov 2010 at 2:49

[GoogleCodeExporter]

ok, thanks. I'll try that.

would you mind taking some notes of things you have to change to work with 
0.16? Some of those might be unintentional and I might want to fix them.

Original comment by arvid.no...@gmail.com on 28 Nov 2010 at 6:34

[GoogleCodeExporter]

Changes:
- At several places you replaced boost paths by strings 
(torrent::handle::save_path(), two torrent creation functions).
- The biggest change is that torrent_info no longer provides the file path and 
you need to use file_storage::file_path(file_entry fe) to get the file path 
instead. I heavily depended on torrent_info::path so this was very annoying.
- torrent_info::creation_date() now returns a time_t instead of a ptime
- lazy_bdecode() has an additional parameter (error_code)

I think that's it.

Original comment by dch...@gmail.com on 28 Nov 2010 at 8:00

[GoogleCodeExporter]

those are some good points. I've restored the previous lazy_bdecode() function, 
and I'll restore the file_entry API as well, at least for the most part. (This 
might mean you have to change a few things back).

Original comment by arvid.no...@gmail.com on 29 Nov 2010 at 2:58

[GoogleCodeExporter]

Original comment by arvid.no...@gmail.com on 29 Nov 2010 at 3:03

• Changed title: lock in session_impl destructor

[GoogleCodeExporter]

hydri. I have fixed it in qBittorrent.

Due to a bug I introduced in the development version of qBittorrent, the 
libtorrent session was configured *after* the torrents were added to it.

Apparently this causes some issues. I believe that libtorrent should not lock 
in any case but still I have to admit that it is logic the configure the 
session before adding the torrents.

Original comment by dch...@gmail.com on 29 Nov 2010 at 5:06

[GoogleCodeExporter]

I'm still interested in reproducing it or seeing your hang-logs from trunk 
(TORRENT_ASIO_DEBUGGING)

Original comment by arvid.no...@gmail.com on 29 Nov 2010 at 8:47

[GoogleCodeExporter]

hydri, as I said previously, it does not hang with trunk.

Original comment by dch...@gmail.com on 29 Nov 2010 at 8:53

[GoogleCodeExporter]

any info on how to reproduce this?

Original comment by arvid.no...@gmail.com on 6 Dec 2010 at 6:02

[GoogleCodeExporter]

No, sorry. All I know is that I was configuring the session after having added 
the torrents. However, this behavior is wrong so I guess you can close the 
report if the issue if not obvious.

Original comment by dch...@gmail.com on 6 Dec 2010 at 6:09

[GoogleCodeExporter]

Hello,I use the libtorrent-resterbar v0.15.5 make to dll and use it in 
application,when the application closed,it still in the processmanger.i Debug 
it and found the class funcation is error,session::~session(),it in 
session::session() new a target,but can't delete it.how can i release this 
error?if you have a good ider please tell me.my email is:vcbug@126.com
thank you very much....

Original comment by tangqinx...@gmail.com on 8 Jan 2011 at 6:15

[GoogleCodeExporter]

Have the same issue with 0.16.5 
(master/70a6df6d811ffddaa778f00d5594d23305f347a1)
OS Windows 8
Boost 1.54.0
Compiling command:
b2.exe toolset=msvc-11.0 boost-date-time=on boost=source encryption=openssl 
link=static boost-link=static geoip=off
Call stack for each thread: http://pastebin.com/AD9bc3hk

Relevant code (note that I don't have DHT enabled):
m_session.set_alert_mask(alert::error_notification | 
alert::status_notification);
add_torrent_params tp;
tp.auto_managed = false;
tp.url = url_to_torrent_file;
tp.save_path = writable_path_to_save_downloaded_files;
error_code ec;
m_session.add_torrent(tp, ec);

If after all alerts have been processed I close the application (i.e. try to 
destroy the session) I'll get the aforementioned call stack.

Original comment by p1hi...@gmail.com on 23 Sep 2013 at 9:15

[GoogleCodeExporter]

Could you build with asio-debugging=on ?

That will print out which async operations are still outstanding when trying to 
shut down. it's quite verbose, it will print out all remaining ones every 
second.

The ones that are left after 10 seconds (assuming there were torrents that 
needed stopping and timing out) are the one(s) causing the stall.

Original comment by arvid.no...@gmail.com on 23 Sep 2013 at 2:52

[GoogleCodeExporter]

Well, it appears that it won't be as easy as I wanted.
Here is a couple of facts:

1. Apparently I should've used version 0.16.0 as mentioned in qBittorrent 
building guide. I've tried to use one from the repo and it turned out to be 
broken in some way - it did not start the download, stats_alert's were filled 
with zeros. And the version 0.16.0 works well with the same compilation option 
(well, except for the boost-date-time=on for the one from repo - it fixes link 
error "unresolved asio_handler_allocate). Probably it should be put into 
another issue - I don't know.

2. So before I've read your answer I switched to version 0.16.0. As you asked 
I've built libtorrent with asio-debugging=on and launched app. The results so 
far are disturbing: if I close the app in a few seconds after adding the 
torrent (from 0 to 3 stats_alert have arrived) there won't be any asio's 
output. The app just hangs there, just as before. And if I wait a little longer 
before closing the app, asio gives me its output and the app exits normally 
within ~50 seconds. Here is the output: http://pastebin.com/QqybK13A

Original comment by p1hi...@gmail.com on 23 Sep 2013 at 6:57

[GoogleCodeExporter]

Another thing: when I add torrent which already has been started but not 
finished, it goes to queued_for_checking state. And for some reason (probably 
because it's paused) sits there forever. If I try to call 
session::get_torrents() to save torrents before exiting, it will hang.

Original comment by p1hi...@gmail.com on 26 Sep 2013 at 10:52

[GoogleCodeExporter]

looking closer at the stacks in your first post. it looks really suspicious 
that atexit() is called from within the network thread when aborting a torrent. 
If you can reproduce that, could you look closer at the stack frames around 
that?

        mclt.exe!atexit(void (void) * func) Line 175
        mclt.exe!libtorrent::get_libtorrent_category() Line 340
        mclt.exe!libtorrent::errors::make_error_code(libtorrent::errors::error_code_enum e) Line 362
        mclt.exe!boost::system::error_code::error_code<enum libtorrent::errors::error_code_enum>(libtorrent::errors::error_code_enum e, void * __formal) Line 330
        mclt.exe!libtorrent::torrent::abort() Line 3498
        mclt.exe!libtorrent::aux::session_impl::abort() Line 1814

Is that stack really correct?

Original comment by arvid.no...@gmail.com on 26 Sep 2013 at 3:53