Open tmm1 opened 4 years ago
Looks like loaded binary mapping has clashed with loader (loader address is defined in arch.h
, this value is referenced from GNUMakefile
).
Probably either LOADER_ADDRESS
should be raised or EXEC_PIC_ADDRESS
should be lowered, but I don't know what these values should actually be.
Thanks! Really appreciate the pointer.
I see the EXEC_PIC_ADDRESS
being mmap'd in the verbose output above, but no indication of LOADER_ADDRESS
. Did you see something in there that suggested overlap, or just a hunch based on the segv that the binary was being corrupted?
Either way, you were correct and the following works for me now:
--- a/src/arch.h
+++ b/src/arch.h
@@ -101,7 +101,7 @@ typedef unsigned char byte_t;
#define OFFSETOF_STAT_GID_32 0
#define EM_ARM 40
- #define LOADER_ADDRESS 0x10000000
+ #define LOADER_ADDRESS 0x20000000
#define EXEC_PIC_ADDRESS 0x0f000000
#define INTERP_PIC_ADDRESS 0x1f000000
Not sure if this is something that should be merged, or if there would be other unintended consequences. Now that the binary runs maybe I can look at /proc/pid/maps
and see where the overlap was and how much extra space is actually needed..
I discovered there is an old WIP branch upstream that tries to remove LOADER_ADDRESS
: https://github.com/proot-me/proot/compare/position_independant
Hi, i pointed to this issue where i needed to run Chromium on 32-bit environment, and it got segfaults, somehow running chromium works by setting LOADER_ADDRESS
to 0x20000000
in proot
's source, so far i didn't get any strange side effects from time to time when using armhf distro and it only fixes chromium segfaults after using armhf distro for like a month now
I guess it's time that LOADER_ADDRESS
should be set to 0x20000000
?
@WMCB-Tech, may be best to apply changes from the position_independant branch to the Termux proot repository?
just to be safe then probably yes
I'm trying to run headless chromium via proot. It works on
arm64-v8a
devices, but onarmeabi-v7a
I'm getting a segfault: