Closed ladar closed 2 years ago
Posting details for all these devices would get get complicated, so I'll try to summarize instead
termux-info
output for at least the device(s) where it fails would be useful. I have no idea if Fire HD, Fxtec and Unithertz are arm or aarch64 devices, or what kernel version they are using.
It possible this issue isn't with the Android release, but rather some common property using to build these specific Android ROMs.
Rather than ROM specific it seems more likely that it has to do with the kernel version and available syscalls. Your previous fix solved the earlier issues by adding support to torsocks for handling additional syscalls. Unfortunately though the kernel version doesn't guarantee a certain set of syscalls, kernel developers might have backported additional syscalls to make kernel work with a newer android version.
This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
On Android 8.1.0 aarch64 I got the following stack trace:
Program received signal SIGINT, Interrupt.
0x0000007fb7b2042c in syscall () from target:/system/lib64/libc.so
(gdb) bt
#0 0x0000007fb7b2042c in syscall () from target:/system/lib64/libc.so
#1 0x0000007fb7adbd04 in handle_futex (args=...) at /home/builder/.termux-build/torsocks/src/src/lib/syscall.c:232
#2 0x0000007fb7adb18c in tsocks_syscall (number=number@entry=98, args=<error reading variable: Cannot access memory at address 0x89>) at /home/builder/.termux-build/torsocks/src/src/lib/syscall.c:572
#3 0x0000007fb7adccac in syscall (number=98) at /home/builder/.termux-build/torsocks/src/src/lib/syscall.c:659
#4 0x0000007fb7b7a1bc in __pthread_mutex_lock_with_timeout(pthread_mutex_internal_t*, bool, timespec const*) () from target:/system/lib64/libc.so
#5 0x0000007fb7baaea0 in je_malloc () from target:/system/lib64/libc.so
#6 0x0000007fb7b8504c in operator new[](unsigned long) () from target:/system/lib64/libc.so
#7 0x0000007fb7b89834 in __sfp () from target:/system/lib64/libc.so
#8 0x0000007fb7b89d88 in fopen64 () from target:/system/lib64/libc.so
#9 0x0000007fb7adf020 in config_file_read (filename=0x7fb7ad09bf "/data/data/com.termux/files/usr/etc/tor/torsocks.conf", config=config@entry=0x7fb7ae50c0 <tsocks_config>) at /home/builder/.termux-build/torsocks/src/src/common/config-file.c:546
#10 0x0000007fb7ad96d0 in init_config () at /home/builder/.termux-build/torsocks/src/src/lib/torsocks.c:163
#11 0x0000007fb7ad923c in tsocks_init () at /home/builder/.termux-build/torsocks/src/src/lib/torsocks.c:329
#12 0x0000007fb7ae01d4 in tsocks_once (o=0x7fb7ae5000 <init_once>, init_routine=0x7fb7ad91f8 <tsocks_init>) at /home/builder/.termux-build/torsocks/src/src/common/compat.c:94
#13 0x0000007fb7ad91d4 in tsocks_initialize () at /home/builder/.termux-build/torsocks/src/src/lib/torsocks.c:704
#14 0x0000007fb7adabf8 in close (fd=3) at /home/builder/.termux-build/torsocks/src/src/lib/close.c:71
#15 0x0000007fb7bb50b4 in je_pages_boot () from target:/system/lib64/libc.so
#16 0x0000007fb7bb451c in malloc_init_hard_a0_locked () from target:/system/lib64/libc.so
#17 0x0000007fb7bb09a4 in jemalloc_constructor () from target:/system/lib64/libc.so
#18 0x0000007fb7e97ac0 in __dl__ZL10call_arrayIPFviPPcS1_EEvPKcPT_mbS5_ () from target:/system/bin/linker64
#19 0x0000007fb7e97e00 in __dl__ZN6soinfo17call_constructorsEv () from target:/system/bin/linker64
#20 0x0000007fb7e97cfc in __dl__ZN6soinfo17call_constructorsEv () from target:/system/bin/linker64
#21 0x0000007fb7e97cfc in __dl__ZN6soinfo17call_constructorsEv () from target:/system/bin/linker64
#22 0x0000007fb7e93628 in __dl___linker_init () from target:/system/bin/linker64
#23 0x0000007fb7e9a8e4 in __dl__start () from target:/system/bin/linker64
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Looks like a deadlock wrt malloc routines. Probably we need an alternative to tsocks_initialize
that does not induce any of the malloc family.
Problem description
While setting up a couple of new Android 8.1 test devices, I realized that torsocks wasn't working. I inititally thought it might be an issue with the recent package updates, so I tested it on my other devices. It seems to work just fine on 7.0, 8.0, 10.0 and 11.0 but hangs (aka is broken) on 8.1 and 9.0.
It's worth noting that my 8.1 devices are actually both using Lineage 15.1. But I have two different Android 9.0 devices, from different manufacturers (Unihertz and Fxtec), and they are both failing in the same way (they just hang).
What steps will reproduce the bug?
Running:
torsocks curl api4.ipify.org
Will hang, until killed. On the other hand, running with
proxychains4
or havingcurl
connect to the TOR SOCKS5 proxy directly both work.What is the expected behavior?
The command should return the IP address of the TOR exit node.
System information
Posting details for all these devices would get get complicated, so I'll try to summarize instead. I tested torsocks using a Samsung with droid 7.0, a Motorola with droid 8.0, an Onn device with droid 10, and a Samsung with droid 11. I also tested torsocks using a Fire HD device with Lineage 18.1 (aka droid 11) and Gateway with droid 11, but both of those devices were using armeabi-v7a versions of Android, so not a great test case.
The devices that were failing/hanging were a Fire HD with Lineage 15.1 (aka droid 8.1), an Fxtec with Android 9, and a Unithertz device, also with Android 9.
So far I've tried recompiling torsocks on the Lineage 15.1 device without success. I haven't tried running it via a debugger yet. I wanted to open up the issue first. I'm hoping someone else can confirm my findings by testing torsocks on other devices with Android 8.1 and 9.0 so we can confirm the problem is specific to Android 8.1 and 9.0. It possible this issue isn't with the Android release, but rather some common property using to build these specific Android ROMs.
I thought the Termux team might have a bigger sample size to poll.
I also noticed that
lsof -n
was triggering a segmentation fault on the failing devices. And while torsocks was working on the 32 bit droid 11 devices it was also complaining about a missing system call.