Open GoogleCodeExporter opened 9 years ago
GoogleCodeExporter
commented
9 years ago i run Ubuntu tru the terminal with Ubuntu.sh file to port VNC using the
terminal it runs great but no javac nowOriginal comment by real8...@gmail.com on 4 Feb 2012 at 11:03
GoogleCodeExporter
commented
9 years ago i run Ubuntu tru the terminal with Ubuntu.sh file to port VNC using the
terminal it runs great but no javac nowOriginal comment by real8...@gmail.com on 4 Feb 2012 at 11:03
GoogleCodeExporter
commented
9 years ago I have the same problem =( Please give any advice.Original comment by MIIsmagi...@gmail.com on 20 Jul 2012 at 1:49
GoogleCodeExporter
commented
9 years ago I get the same issue when running the provided java and javac commands. Running
TermIDE on Nexus 7Original comment by jdw...@gmail.com on 28 Sep 2012 at 4:46
GoogleCodeExporter
commented
9 years ago Same problem on my HTC EVO View 4G: most java executables don't work; all give
segmentation violations, even jping.Original comment by geer...@gmail.com on 12 Nov 2012 at 4:51
GoogleCodeExporter
commented
9 years ago I ran into the same issue today while trying to adapt the supplied builder.sh
script for my application. I figured the problem quickly because I had both
working version of the script and the version which 100% caused the
"segmentation fault" error.
The problem appeared in a case I used default TerminalIde android.jar file to
build my application (it is of API level 10 and my application cannot be built
against it without errors anyway).
Once I found out a way to override that android.jar with my custom android.jar
( API Level 15) the build script completed successfully.
Please see
https://github.com/andstatus/andstatus/wiki/Building-the-Android-application-usi
ng-Bash-scriptOriginal comment by yvo...@gmail.com on 22 Mar 2013 at 12:39
GoogleCodeExporter
commented
9 years ago I can confirm this issue.
Utilities that use a dalvik virtual machine such as javac, jping, pm or su
crash with a segmentation fault. Native processes like vim, ssh, terminal-gcc
or programs compiled with gcc don't.
It occurs when connecting via terminal-ide's utelnetd or dropbear. It doesn't
occur when accessing the phone directly, using adb shell or busybox's telnetd.
But even if I connect using these latter methods, the bug reappears inside a
tmux session.
It is also device-specific, but for any device it behaves in a deterministic
way.
I have done some autopsy around this issue. The problem can be traced back to
the bootstrap class loader which is executed early in the startup sequence of
java-related programs and calls prepareCpe() for all classpath elements. This
will in turn call dvmJarFileOpen() and then dexOptGenerateCacheFileName() to
find the canonical location for the dex files in the dalvik cache. Most files
are cached under /data/dalvik-cache but anything on the /system partition gets
cached to /cache/dalvik-cache instead. Well, almost. On some devices, the
dalvik.vm.dexopt-data-only property is set and there even these files are
cached to /data/dalvik-cache.
The bug affects those devices that cache everything under /data/dalvik-cache.
There the /cache/dalvik-cache directory doesn't exist, but this is generally
not a problem until for some reason the dalvik.vm.dexopt-data-only property
gets turned off. And this is exactly what happens when using utelnetd, dropbear
or tmux. (There are actually two issues here. One of them is that the property
should be on, and the other one is that the vm shouldn't abort with a segfault
even when the cache directories are unavailable. I was more interested in the
former one, so I only debugged that.)
Android has a property system akin to the windows registry or gconf, but
accessed in a different way. On system boot, the init process creates a shared
memory region by mmap()-ing /dev/__properties__ (which is unlinked immediately
afterwards). Its file descriptor and size are saved to the environment variable
ANDROID_PROPERTY_WORKSPACE which is then passed, together with the file
descriptor, along every fork() to each process in the system. The property
values can only be read through this file descriptor.
This approach is incompatible with terminal multiplexers that follow the
traditional unix way. A program such as sshd offers shells that are (and should
be) unrelated from the environment in which the daemon was started. To do so,
it closes all file descriptors while forking off child processes, and
incidentally cuts off access to the android property system as well. Therefore,
property queries inside sshd or tmux will fall back to the default values, in
this case using /cache/dalvik-cache for the dex files.
I can imagine at least three ways around this problem:
1. The band-aid fix is to set ANDROID_CACHE=/data in .bashrc. This will not
restore the property system and may have unrelated side effects, so I don't
recommend adding it to terminal-ide, but it does work for me and it may also
help users who hit this bug report until a more permanent solution is found.
2. Save the file descriptor in the first bash instance started from
terminal-ide and reset it in later sessions if it is missing. Sounds easy, but
you can't just serialize a file descriptor in such a way that it can be
reopened later, you can't open it from /dev/__properties__ since it was
unlinked early in the startup sequence and you can't open it from /proc either
because it gives a permission error. The easiest way I found was to spawn a
server that sends the file descriptor over a unix domain socket using
SCM_RIGHTS ancillary data. Here is a proof-of-concept implementation:
https://gist.github.com/9109cbfd6cb39e253727
3. Patch the affected daemons not to close the property workspace file
descriptor. This seems like the cleanest approach to me, but it needs to be
done for each program separately and the user also has to take care when
compiling their own terminal multiplexers.Original comment by htam...@gmail.com on 22 May 2014 at 6:01
Original issue reported on code.google.com by
real8...@gmail.comon 4 Feb 2012 at 4:21