proot
proot copied to clipboard
proot-me
``apt-get install fp-compiler-2.6.0`` crashes in Debian noroot
Yes it is released (version 5.0.0), it crashes Free Pascal that worked before - apt-get install fp-compiler-2.6.0 crashes with segfault. I wonder if Gnuroot also suffers from this. I've patched PRoot to use /tmp inside chroot, but I'm not entirely sure that my patch works as expected.
-- https://github.com/corbinlc/gnuroot/issues/33#issuecomment-65201015
@pelya, could you please specify what the guest rootfs is? Do you have more information, like error messages?
Guest rootfs is Debian Wheezy armhf. There are no error messages, just 'Application terminated with signal SIGFAULT'. I'll try to debug it when I'll have time, maybe rollback proot and see which commit causes that. On Dec 2, 2014 12:35 PM, "Cédric VINCENT" [email protected] wrote:
Yes it is released (version 5.0.0), it crashes Free Pascal that worked before - apt-get install fp-compiler-2.6.0 crashes with segfault. I wonder if Gnuroot also suffers from this. I've patched PRoot to use /tmp inside chroot, but I'm not entirely sure that my patch works as expected.
-- corbinlc/gnuroot#33 (comment) https://github.com/corbinlc/gnuroot/issues/33#issuecomment-65201015
@pelya https://github.com/pelya, could you please specify what the guest rootfs is? Do you have more information, like error messages?
— Reply to this email directly or view it on GitHub https://github.com/cedric-vincent/PRoot/issues/74.
What I've discovered so far: fpc works with proot 4.0.3, and crashes with proot 5.0.0. I've attached console output when running "proot -v 100 fpc" with both versions of proot: https://gist.github.com/pelya/e4cfb2b18ad4efa27859 My patch for Android-specific /tmp location works okay. fpc itself is linked statically, in some convoluted way, that makes it crash during .elf loading stage, it seems like it does not execute anything from the .elf itself, because the crash log is very short. On my PC it tries to load ppcarm binary from /usr/bin, but on Android it does not even reach this stage. And I've failed to run GDB or strace with proot 5.0.0, both fail to launch even simple executables, like grep or ls.
You can download fpc binaries for different architectures here: https://packages.debian.org/wheezy/fp-compiler-2.6.0
On Tue, Dec 2, 2014 at 12:39 PM, Sergii Pylypenko [email protected] wrote:
Guest rootfs is Debian Wheezy armhf. There are no error messages, just 'Application terminated with signal SIGFAULT'. I'll try to debug it when I'll have time, maybe rollback proot and see which commit causes that. On Dec 2, 2014 12:35 PM, "Cédric VINCENT" [email protected] wrote:
Yes it is released (version 5.0.0), it crashes Free Pascal that worked before - apt-get install fp-compiler-2.6.0 crashes with segfault. I wonder if Gnuroot also suffers from this. I've patched PRoot to use /tmp inside chroot, but I'm not entirely sure that my patch works as expected.
-- corbinlc/gnuroot#33 (comment) https://github.com/corbinlc/gnuroot/issues/33#issuecomment-65201015
@pelya https://github.com/pelya, could you please specify what the guest rootfs is? Do you have more information, like error messages?
— Reply to this email directly or view it on GitHub https://github.com/cedric-vincent/PRoot/issues/74.
Thanks for the detailed information!
I ran fpc-2.6.0 from Debian Wheezy ARMhf under PRoot with success. I compared your logs against mine but they don't differ that much. That means I have to put more verbose messages in the loading stage to understand this issue.
Did you use QEMU, native Debian, or Android device? I know that QEMU executes code with misaligned memory access correctly, while such code will fail on an actual hardware.
Anyway, the crash seems to be limited to just one application, so no big impact. On Dec 3, 2014 11:23 AM, "Cédric VINCENT" [email protected] wrote:
Thanks for the detailed information!
I ran fpc-2.6.0 from Debian Wheezy ARMhf under PRoot with success. I compared your logs against mine but they don't differ that much. That means I have to put more verbose messages in the loading stage to understand this issue.
— Reply to this email directly or view it on GitHub https://github.com/cedric-vincent/PRoot/issues/74#issuecomment-65377338.
I used a STiH416 B2020 board (ARMv7) where the host system is STLinux 2.4 and /proc/cpu/alignment is set to "signal+warn" (nothing was reported).
Okay, so it seems to be Android-specific. Or maybe I compiled PRoot incorrectly, I will try the precompiled version from your site. On Dec 3, 2014 11:58 AM, "Cédric VINCENT" [email protected] wrote:
I used a STiH416 B2020 board (ARMv7) where the host system is STLinux 2.4 and /proc/cpu/alignment is set to "signal+warn" (nothing was reported).
— Reply to this email directly or view it on GitHub https://github.com/cedric-vincent/PRoot/issues/74#issuecomment-65382243.
https://github.com/pelya/cuntubuntu/blob/master/dist/proot?raw=true
It uses directory 'tmp' inside chroot to save it's files, so it should be created beforehand. On Dec 3, 2014 3:05 PM, "Cédric VINCENT" [email protected] wrote:
I'd like to test your binary too. Where can I download it?
— Reply to this email directly or view it on GitHub https://github.com/cedric-vincent/PRoot/issues/74#issuecomment-65403602.
I wonder if commit 54904cb6 fixes this issue (as I can see your binary has the .note.gnu.build-id section)
I tried the proot-arm prebuilt binary from your site, extracted proot-arm-loader, set PROOT_LOADER, and fpc launched fine with it. Magic! Cherry-picking that commit into my proot sourcetree did not help though, it seems like I'm compiling it somehow incorrectly.
On Wed, Dec 3, 2014 at 4:14 PM, Cédric VINCENT [email protected] wrote:
I wonder if commit 54904cb https://github.com/cedric-vincent/PRoot/commit/54904cb6a2a94f2cf5b3e81abcca964063007b2a fixes this issue (as I can see your binary has the .note.gnu.build-id section)
— Reply to this email directly or view it on GitHub https://github.com/cedric-vincent/PRoot/issues/74#issuecomment-65412581.
How are you building PRoot? Are you using QEMU ARM chroot, Virtualbox, or live development board? I'm cross-compiling it using arm-linux-gnueabihf-gcc 4.5 toolchain, downloaded from emdebian.org. I guess I'll just add tmpdir option as a commandline parameter to PRoot, ask you to merge the patch, and then use the prebuilt proot from your site, it's the only feature that is needed to use it on Android.
On Wed, Dec 3, 2014 at 11:34 PM, Sergii Pylypenko [email protected] wrote:
I tried the proot-arm prebuilt binary from your site, extracted proot-arm-loader, set PROOT_LOADER, and fpc launched fine with it. Magic! Cherry-picking that commit into my proot sourcetree did not help though, it seems like I'm compiling it somehow incorrectly.
On Wed, Dec 3, 2014 at 4:14 PM, Cédric VINCENT [email protected] wrote:
I wonder if commit 54904cb https://github.com/cedric-vincent/PRoot/commit/54904cb6a2a94f2cf5b3e81abcca964063007b2a fixes this issue (as I can see your binary has the .note.gnu.build-id section)
— Reply to this email directly or view it on GitHub https://github.com/cedric-vincent/PRoot/issues/74#issuecomment-65412581 .
How are you building PRoot?
I build static releases with PRoot, QEMU user-mode, and a Slackware-ARM-14.1 rootfs:
https://github.com/cedric-vincent/proot-static-build/blob/master/GNUmakefile#L13
Maybe I wrongly described register constraints for the ARM loader, that could explain why it doesn't work when built with another toolchain (extended inline assembly is sensitive to how the C code is translated down to instructions). I'll try to build PRoot using the same toolchain as yours.
I guess I'll just add tmpdir option as a commandline parameter to PRoot, ask you to merge the patch,
I agree to make tmpdir configurable at run-time, however I'd prefer not to add a new command-line parameter for such specific option. Instead, you could make it configurable with an environment variable, like other options oriented towards advanced usage (ex. PROOT_LOADER).
Cédric.
I'm cross-compiling it using arm-linux-gnueabihf-gcc 4.5 toolchain, downloaded from emdebian.org.
I tried this toolchain:
- it doesn't build the loader as-is because of unsupported comment format in the assembly code ("//").
- once comments are removed, it builds a working loader (tested with your binary).
I cannot conclude anything so far. Also, I wasn't able to extract the loader from your binary because all symbols were removed. Do you have a non-stripped version?
Hi. I've made another patch to read temp directory location from PROOT_TMPDIR env variable, sorry that it took so long. It uses attribute((constructor)) GCC extension and a bit of #define hackery, so probably not clean enough to merge.
https://github.com/pelya/cuntubuntu/blob/master/proot-android.patch
This sounds familiar to: https://github.com/proot-me/PRoot/issues/79, https://github.com/proot-me/PRoot/issues/87, https://github.com/proot-me/PRoot/issues/93
