Closed GoogleCodeExporter closed 9 years ago
This is part of a larger project with 8 full-time developers.
We have a subset of the TOR protocol operational on Android.
Key is trying to get Libtorrent downloads stable.
We also invested 4 months into the old RuTracker port of Libtorrent to Android,
https://github.com/javto/Tribler-streaming#rutracker
Anonymous downloading on Android specs:
https://github.com/Tribler/tribler/wiki/Anonymous-Downloading-and-Streaming-spec
ifications
Original comment by peer2p...@gmail.com
on 5 Jun 2014 at 9:26
that's an assert. those line numbers in torrent.cpp don't line up for me.
what's the output?
Original comment by arvid.no...@gmail.com
on 6 Jun 2014 at 4:36
Thank you for your quick response!
The line torrent.cpp:858 is inside torrent::~torrent() and contains the
following assert:
TORRENT_ASSERT(m_abort);
I'm currently working on obtaining the assertion output, since android phones
tend to be very restrictive about writing log files for applications... I will
get back to you about this as soon as I can.
Original comment by rjager...@gmail.com
on 6 Jun 2014 at 7:59
Dear arvid,
Thanks for the response. We have redirected the stderr from libtorrent to
logcat, and we get the following output:
V/stderr (22152): assertion failed. Please file a bugreport at
http://code.google.com/p/libtorrent/issues
V/stderr (22152): Please include the following information:
V/stderr (22152):
V/stderr (22152): version: 1.0.0.0
V/stderr (22152): $Rev: 9739 $
V/stderr (22152):
V/stderr (22152): file: 'torrent.cpp'
V/stderr (22152): line: 858
V/stderr (22152): function: virtual libtorrent::torrent::~torrent()
V/stderr (22152): expression: m_abort
V/stderr (22152):
V/stderr (22152):
V/stderr (22152): stack:
V/stderr (22152):
Do you have any idea why this assert could possibly fail?
Thanks!
Original comment by mdmartij...@gmail.com
on 6 Jun 2014 at 10:08
For clarity's sake, here is how we compiled libtorrent RC2 for android:
1) We have set up the official android NDK toolchain and created a custom
toolchain at /usr/local/gcc-4.8.0-arm-linux-androideabi/
We set PATH, CC and CXX to point to this toolchain and set some other variables
that we can use during our build process:
export SYSROOT=$ANDROIDNDK/platforms/android-14/arch-arm
export PATH=/usr/local/gcc-4.8.0-arm-linux-androideabi/bin:$PATH
export CC=arm-linux-androideabi-gcc
export CXX=arm-linux-androideabi-g++
export CROSSHOST=arm-linux-androideabi
export CROSSHOME=/usr/local/gcc-4.8.0-arm-linux-androideabi
2) After downloading boost 1.55.0, we have compiled boost-system and
boost-filesystem using the NDK toolchain. This results in libboost_system.a and
libboost_filesystem.a, which are installed in
/usr/local/gcc-4.8.0-arm-linux-androideabi/lib
3) Next, we download openssl-1.0.1g and compile it using the NDK toolchain.
This results in libcrypto.a and libssl.a, which are also installed in
/usr/local/gcc-4.8.0-arm-linux-androideabi/lib
3) We've downloaded and extracted "libtorrent-rasterbar-1.0.0-RC2.tar.gz" from
http://sourceforge.net/projects/libtorrent/files/libtorrent/
4) To configure libtorrent, we run:
./configure --host=$CROSSHOST --prefix=$CROSSHOME --with-boost=$CROSSHOME --with-boost-libdir=$CROSSHOME/lib --enable-shared --disable-static --enable-debug=yes --enable-logging=yes
A side note here, we modify src/Makefile on line 576 so it removes the
versioning information in the .so file which doesn't play nice with Android:
libtorrent_rasterbar_la_LDFLAGS = -avoid-version
5) And to finally compile libtorrent, we use:
make && make install
Which results in a libtorrent.so for Android that we can use in our application.
Original comment by rjager...@gmail.com
on 6 Jun 2014 at 12:26
This assert makes sure that every torrent object is properly shut down before
being destructed. This is meant to happen by torrent::abort().
This is called by session_impl::abort() or session_impl::remove_torrent().
Those are the main paths through which a torrent should be destroyed. In your
case, it doesn't sound like you intend to remove the torrent.
Is it possible that the chip you run on or its compiler has a bug with atomic
operations? I have seen this on embedded devices before. If so, that could
explain this error by the boost::shared_ptr<> failing to keep the reference
counter consistent, and deleting the object prematurely.
try to build with "BOOST_SP_USE_PTHREADS" to test this theory. That will make
boost::shared_ptr use a mutex instead of atomic operations.
Original comment by arvid.no...@gmail.com
on 6 Jun 2014 at 2:12
Dear Arvid,
Thanks for the helpful comment. We're going to try that and we will post our
findings!
Original comment by mdmartij...@gmail.com
on 6 Jun 2014 at 2:15
We tried to compile it with the BOOST_SP_USE_PTHREADS define but that dit not
work, our application still crashes with the same stack trace. Do you have any
other idea what we could try to get it working? Maybe there is another cause
that deletes the object prematurely.
Thanks!
Original comment by mdmartij...@gmail.com
on 8 Jun 2014 at 9:27
are you adding torrents by URL? there is a kind of "dummy" torrent object added
to represent the download, and it's then replaced by the actual one once it's
downloaded, parsed and we know the info-hash. That is the only other place a
torrent object is deleted I can think of.
Original comment by arvid.no...@gmail.com
on 8 Jun 2014 at 9:23
No, we have a .torrent file on the Android device which we load in our code.
(for testing we are using the Ubuntu 14.04 torrent file).
Could this mean that the issue is indeed caused by Boost's shared pointers
failing to hold a reference to the Torrent object? Are there any other known
issues with that, especially on mobile devices?
Original comment by mdmartij...@gmail.com
on 8 Jun 2014 at 9:34
We have probably fixed the issue.
It was indeed caused by the shared pointers but somehow it kept using the
sp_counted_base_spin.hpp file for it's include while it should use
sp_counted_base_pt.hpp. We simply changed the #include statements of the
sp_counted_base_spin.hpp by sp_counted_base_pt.hpp. It seems to run stable now
on the Android device.
So your theory was right indeed, using the BOOST_SP_USE_PTHREAD flag should fix
this issue, however, we had to modify the code in Boost itself which is not a
good style, but it works for us. Thanks for your help with this. If we run into
any other problems, we come back to you. Thanks for your help.
Original comment by mdmartij...@gmail.com
on 9 Jun 2014 at 4:35
when building libtorrent, you can specify (on the bjam command line):
define=BOOST_SP_USE_PTHREAD and you would also have to specify -a to force a
rebuild all. you would probably also have to specify this in your own code,
that may interact with shared_ptr
Original comment by arvid.no...@gmail.com
on 9 Jun 2014 at 11:16
I ran into the same issue on my Nexus 5. What threw me off for a little bit was
the #define suggested is missing an "S" at the end.
BOOST_SP_USE_PTHREADS is the correct one.
Line 29 of sp_counted_base.hpp
#elif defined( BOOST_SP_USE_PTHREADS )
# include <boost/smart_ptr/detail/sp_counted_base_pt.hpp>
Original comment by d...@doog.us
on 10 Nov 2014 at 4:09
[deleted comment]
does libtorrent have any setpiecepriorities() functions? for sequential
download / torrent streaming.
i see popcorn time is using it in their application - is this their custom work?
thanks!
Original comment by ole.stub...@gmail.com
on 10 Nov 2014 at 2:45
yes:
http://libtorrent.org/reference-Core.html#prioritize_pieces()
but for streaming, you should use:
http://libtorrent.org/reference-Core.html#set_piece_deadline()
Original comment by arvid.no...@gmail.com
on 10 Nov 2014 at 3:58
Original issue reported on code.google.com by
rjager...@gmail.com
on 4 Jun 2014 at 9:11