search

frostwire / frostwire-jlibtorrent

A swig Java interface for libtorrent by the makers of FrostWire. Develop libtorrent based apps with the joy of coding in Java.
http://www.frostwire.com
MIT License
446 stars 137 forks source link

[crash/android] file::readv(std::int64_t file_offset, span<iovec_t const> bufs (1.2.0.6) #160

Closed gubatron closed 6 years ago

gubatron commented 7 years ago 
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'lge/m1_tmo_us/m1:5.1.1/LMY47V/163231727af82:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 14943, tid: 15034, name: Thread-6015  >>> com.frostwire.android <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
    r0 00000000  r1 00000000  r2 000ad962  r3 00000000
    r4 9e4f5b18  r5 00000000  r6 000ad962  r7 ffffffff
    r8 9e4f5b58  r9 00000001  sl 00000000  fp 9e4f5ae8
    ip a227fe8c  sp 9e4f5ab0  lr a2026860  pc a1fda1e0  cpsr 200f0010

backtrace:
    #00 pc 002631e0  /mnt/asec/com.frostwire.android-2/lib/arm/libjlibtorrent.so (_ZN10libtorrent4file5readvExNS_4spanIK5iovecEERN5boost6system10error_codeEi+20)
    #01 pc 002af85c  /mnt/asec/com.frostwire.android-2/lib/arm/libjlibtorrent.so (_ZN10libtorrent11read_fileop7file_opENS_3aux14strong_typedefIiNS1_14file_index_tagEvEExNS_4spanIK5iovecEERNS_13storage_errorE+264)
    #02 pc 002afef0  /mnt/asec/com.frostwire.android-2/lib/arm/libjlibtorrent.so (_ZN10libtorrent3aux10readwritevERKNS_12file_storageENS_4spanIK5iovecEENS0_14strong_typedefIiNS0_15piece_index_tagEvEEiRNS0_6fileopERNS_13storage_errorE+600)
    #03 pc 002af260  /mnt/asec/com.frostwire.android-2/lib/arm/libjlibtorrent.so (_ZN10libtorrent15default_storage5readvENS_4spanIK5iovecEENS_3aux14strong_typedefIiNS5_15piece_index_tagEvEEiiRNS_13storage_errorE+84)
    #04 pc 0024f3d8  /mnt/asec/com.frostwire.android-2/lib/arm/libjlibtorrent.so (_ZN10libtorrent14disk_io_thread7do_hashEPNS_11disk_io_jobERNS_9tailqueueIS1_EE+1112)
    #05 pc 0024c78c  /mnt/asec/com.frostwire.android-2/lib/arm/libjlibtorrent.so (_ZN10libtorrent14disk_io_thread11perform_jobEPNS_11disk_io_jobERNS_9tailqueueIS1_EE+132)
    #06 pc 00250a88  /mnt/asec/com.frostwire.android-2/lib/arm/libjlibtorrent.so (_ZN10libtorrent14disk_io_thread11execute_jobEPNS_11disk_io_jobE+40)
    #07 pc 00250e38  /mnt/asec/com.frostwire.android-2/lib/arm/libjlibtorrent.so (_ZN10libtorrent14disk_io_thread10thread_funERNS0_9job_queueERNS_19disk_io_thread_poolE+552)
    #08 pc 00257ef0  /mnt/asec/com.frostwire.android-2/lib/arm/libjlibtorrent.so (_ZNSt6__ndk114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_EEEEMN10libtorrent21pool_thread_interfaceEFvRNS7_19disk_io_thread_poolEN5boost4asio10io_service4workEEPS8_NS_17reference_wrapperIS9_EESE_EEEEEPvSL_+116)
    #09 pc 0001372f  /system/lib/libc.so (_ZL15__pthread_startPv+30)
    #10 pc 00011747  /system/lib/libc.so (__start_thread+6)

The comment on that function definition might be a clue

// this has to be thread safe and atomic. i.e. on posix systems it has to be
// turned into a series of pread() calls
std::int64_t file::readv(std::int64_t file_offset, span<iovec_t const> bufs

perhaps the crash is due to it being used in the wrong context

gubatron commented 7 years ago

so my guess is that readv is going in here:

std::int64_t file::readv(std::int64_t file_offset, span<iovec_t const> bufs
        , error_code& ec, int flags)
{
    if (m_file_handle == INVALID_HANDLE_VALUE)
    {
#ifdef TORRENT_WINDOWS
        ec = error_code(ERROR_INVALID_HANDLE, system_category());
#else
        // goes here because it's android vvvvvvvvvvvvvvvvvv
        ec = error_code(boost::system::errc::bad_file_descriptor, generic_category());
#endif
    return -1;
    }
...

then on storage.cpp, file_op(...)

I wonder if these TORRENT_ASSERT calls are causing the crash, do we build with TORRENT_ASSERT on?

                // we either get an error or 0 or more bytes read
            TORRENT_ASSERT(e || ret >= 0);
            TORRENT_ASSERT(ret <= bufs_size(bufs));
aldenml commented 7 years ago

no, we don't build with TORRENT_ASSERT

gubatron commented 7 years ago

I guess TORRENT_ASSERT is not on, since a SIGINT isn't raised by assert_fail, and we're getting a SIGSEGV

gubatron commented 7 years ago

think the crash is happening here, on that error_code() call?

                ec = error_code(boost::system::errc::bad_file_descriptor, generic_category());
#  define BOOST_NOEXCEPT noexcept
aldenml commented 6 years ago

Fixed with 1.2.0.13-RC14