segmentation fault

[GoogleCodeExporter]

i had an issue with terminal ide with trying to use javac and get segmentation 
fault, vim busybox etc works but when i input javac to see if the compiler work 
i get this. i had reboot, factory reset and reinstall the app and nothing 
please help thank you 

Original issue reported on code.google.com by real8...@gmail.com on 4 Feb 2012 at 4:21

[GoogleCodeExporter]

i run Ubuntu tru the terminal with Ubuntu.sh file to port VNC using the 
terminal it runs great but no javac now

Original comment by real8...@gmail.com on 4 Feb 2012 at 11:03

[GoogleCodeExporter]

i run Ubuntu tru the terminal with Ubuntu.sh file to port VNC using the 
terminal it runs great but no javac now

Original comment by real8...@gmail.com on 4 Feb 2012 at 11:03

[GoogleCodeExporter]

I have the same problem =( Please give any advice.

Original comment by MIIsmagi...@gmail.com on 20 Jul 2012 at 1:49

[GoogleCodeExporter]

I get the same issue when running the provided java and javac commands. Running 
TermIDE on Nexus 7

Original comment by jdw...@gmail.com on 28 Sep 2012 at 4:46

[GoogleCodeExporter]

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]

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-script

Original comment by yvo...@gmail.com on 22 Mar 2013 at 12:39

[GoogleCodeExporter]

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