-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Android support #2
Comments
I'm not submitting a Pull Request by the way, so you can merge it yourself from the Patch version if you want. |
The issue is confirmed when using When stopping the session:
The stack is empty, it seems the program loops. |
Relevant line: https://github.com/steeve/libtorrent/blob/libtorrent-0_16_12/src/bt_peer_connection.cpp#L200
|
Thanks for the patch! It looks good. This line you ifdefed out could index f614531..7c3921d 100644
+#ifndef TORRENT_ANDROID #if TORRENT_USE_IOSTREAM Also, I'm pretty sure you'll run into issues with large files (>2GB or syscall(__NR_pread64, fd, buffer, size, 0, boost::uint32_t(offset), On Tue, Nov 26, 2013 at 3:04 AM, Steeve Morin notifications@github.comwrote:
Arvid Norberg |
Yeah I should probably have done it from the 0.16.12 branch. I'll do that if you want. |
Also, I'm getting abysmal performance if I download to the sdcard ( So I guess more patches are needed to announce Android support ;) |
Here's my guess:
to verify it, you could try to enabling sequential download mode. If this turns out to be the case, there's a technique I've been thinking
On Tue, Nov 26, 2013 at 3:00 PM, Steeve Morin notifications@github.comwrote:
Arvid Norberg |
Wow that is a spot on guess. Nice one. Here is my mount, for reference:
|
Could using full allocation work in that case? I've tried to switch full allocation, but after allocation, libtorrent pretty much stopped doing anything, so I'm not sure |
Okay so after much much more checking, I think I found the cause of the memory corruption issues I had. If I build libtorrent without pool allocators, everything works fine :) So I guess it should be made somewhere to disable pool allocators on Android. Wether in the code or in autoconf :) |
an alternative would be to fix the bug. would you mind building with it only works if you also disable the pool allocators, but it will add On Thu, Nov 28, 2013 at 5:50 PM, Steeve Morin notifications@github.comwrote:
Arvid Norberg |
I already did, and appart from the message shown at #2 (comment) nothing was really apparent... Here's what I did for the last week trying to hunt down the bug:
Is there something else I can do? |
Also, most people will want to download to the sdcard, which is indeed FAT32 on most (all?) Android systems. So first of all, it does work, thankfully I'm using sequential mode, but it is there a way to limit the number of "outer" chunks? I'm asking because sometimes it stalls because the driver is zerofilling the missing space, so I was wondering if I could limit that "outer-reach" somehow. |
Because as it is, it should be said to people not to download to the SD card, or any FAT32 device. I also tried to create a EXT4 disk image on the FAT32 fs, but it seems loopback device support is at best spotty on Android :( |
Does the EXT4 image on top of FAT32 work? i.e. does it mitigate the if you're downloading sequentially, snubbed peers will be downloading This is controlled from peer_connection::picker_options() (a function that On Sat, Nov 30, 2013 at 7:38 AM, Steeve Morin notifications@github.comwrote:
Arvid Norberg |
Hi @arvidn, Thanks for hint to use syscalls. This looks to be a solution for large files on android. I was able to call it successully in case of ftruncate, but have troubles with _NR_pread64 and _NR_pwrite64. |
Fyi, I believe Android support was merged a few months ago already (in the svn, not here which is a mirror) |
@mandrazhoid do you have a patch with those system calls I can take a look at, to see if I can spot anything? I would be happy to merge a fix for this. |
@arvidn apparently there is a |
@steeve I don't think that lseek64 is the only 64 bit function which is necessary. @arvidn Sorry, trying to solve this I've put so many debug and comments as well as not using #ifdef while debugging , so it would be too dirty for patch. I'm calling
instead of
I get EFBIG error. |
I would expect readv and writev to be the same entrypoints regardless of whether the file is large or not. In libtorrent_aio, I'm also using pread/pwrite though (and even preadv and pwritev if on linux). @mandrazhoid My understanding is that the 64 bit version takes a 64 bit fd argument too. I'm not sure how what you do will be implemented through ellipsis. Essentially, on a little-endian system, you have to push 4 words (a word is 4 bytes). fd, 0, offset-low-word, offset-high-word. you could try to either cast fd into a uint64_t or insert the zero-padding and split up the offset manually. Or maybe it's enough to just insert the zero padding with what you have right now. |
Apparently, looking https://github.com/tatsuhiro-t/aria2/blob/master/src/android/arm-ftruncate64.S they use the syscall too |
@arvidn isn't fd argument always int, even for 64 bit functions? |
@mandrazhoid it is:
|
Ok. I guess the zero should be considered padding then.
|
still struggling with this syscall. got it partially working... works fine for small files, still doesn't work for > 2gb. uint32_t low = length & 0xffffffff ; |
that looks right to me. what's the symptom when it fails? I take it file_descriptor is an "int", right? |
yes, file_descriptor is int. |
hey @arvidn,
Here's my patch for Android support, in the
android
branch: 10ad404As you can see it's pretty simple.
Patch version: https://github.com/steeve/libtorrent/commit/10ad4044383f4c0af7a7e00326a2a4d943449db3.patch
However, I think there is a buffer overflow somewhere. If I let it use
valloc
, sooner or later I end up with memory corruption, and pretty much never (rarely, but did happen) ifmemalign
is used.The text was updated successfully, but these errors were encountered: