I am debugging memory corruption issue and I want to check whether SF is accessing invalid memory or not but I don't know how to launch SF using command line. Please help.
SurfaceFlinger is started by the system fairly early on, and isn't usually launched by the user from the command line.
One approach would be to insert the valgrind command into the initd control script, modifying init.rc. This is harder than it sounds because of the way the rootdir is mounted.
Replacing the surfaceflinger binary with one that launches SurfaceFlinger running under valgrind should work; just make sure you wait() for it to finish or initd will assume it died when the launcher exits.
Of course, the best way to tell whether or not SurfaceFlinger is accessing invalid memory is to see if it crashes, though perhaps your definition of "invalid" extends beyond "unmapped or mapped incompatibly".
You'll get some complaints out of valgrind from various ioctl()s, particularly where the Hardware Composer is concerned.
Related
I'm using DDMS to monitor threads in my app, and I see that my app has a bunch of native threads as shown in follow picture. And time to time, the number of native threads increased as user interact with my app, which cause my app sometime does not serve as I expect. Is there anyway to kill these native threads?
There is no such thing as a "native thread" on Android, although some people might use that to refer to threads that are not attached to the VM (which would also make them invisible to DDMS). The threads happen to be executing (or waiting) in native code at the time you did a thread dump, but may spend most of their time executing bytecode. (A list of Dalvik thread states is available here.)
The names of the threads suggests that they were created without being given an explicit name. The one thread with a name, NsdManager probably exists because you're using NsdManager, which "responses to requests from an application are on listener callbacks on a seperate thread" [sic].
It's possible that you can glean some useful information from a stack trace. In DDMS, double-click the thread to get a backtrace. On a rooted device, you can kill -3 <pid> to get a full dump, including native stack frames.
Killing arbitrary threads is not allowed, as they might be holding locks or other resources. If you can determine what is starting them, and that they are unnecessary, you can prevent them from being started in the first place.
My application has come c++ code and many pthreads. I close application with exit(0);. After that, I listed running process with adb shell ps. This command shows me current running processes on device.
Output shows there are still some processes related my application (their names are my applicaiton name). After running application several times, these garbage processes number increases. At some point, device cannot response, because of there is small memory left.
I realized some issues. When application starts, it has a pid and I can see that on process list (with adb shell ps). Also, I see some processes that theirs parent process is application processes. And, if I exit from application, application process is removed from list but previous child processes still remaining. And, their parent processes become 1 (I think it is main OS process or something like that).
This problems occurs on HTC One. it doesnt occur on Samsung Note 2. After close app, all child processes are killed automaticly on Samsung.
How can I prevent this child processes remaining?
I want to know why you have not use fork just use pthread,it can make a new process??(my linux program is not good)
mybe you can try the code before application exit
Runtime.getRuntime().exec("killall " + applicationName);
I'm investigating the possible ways of obtaining superuser privileges in a Java Android application and/or its own JNI. The well-known answer seems to be that it's only possible to run a "su" subshell and command line commands from there, which is neither neat nor very practical. I am willing to accept this resolution but still I'd like to hear an opinion on this "what if" scenario.
Reading through Android sources near java.com.android.server.am.ActivityManagerService, java.android.os.Process and the dalvik_system_Zygote.cpp file, it seems to me that during application launch, the application record is examined for the UID and (a list of) GID(s) and all these values are passed to the Zygote through a socket. Z subsequently picks the data up and passes it, without further checks, to setuid() posterior to a fork() call. Therefore, it seems to me that if the Activity Manager pathway was altered, a simple passing of --setuid=0 and perhaps --setgid=0 to the Zygote socket should result in running my Activity with the root UID.
It all seems almost too simple, I suspect that something would go wrong along the way. Unfortunately, there's too much code and new stuff for an inexperienced programmer like me to actually go and try. Has anyone gone this way, or is there any obvious reason why this would NOT work?
I think I just found the answer to my own question. Credits go to #Chris Stratton who pointed me at using the emulator and also pointed out how ridiculous a situation this would be.
The key was in one place where I did not look, between sending commands through the Zygote socket and the Zygote binary itself. The point where the check takes place is com.android.internal.os.ZygoteConnection, method applyUidSecurityPolicy. If the caller process belongs to root, the UID of the spawn may be indeed requested to be zero (or anything else, for that matter). A regular user may use the socket as well but asking for a new UID or GID results in a ZygoteSecurityException.
I knew there are some ways to get the call stack
using "dalvik.vm.stack-trace-file" to get the stack of kernel thread
or using backtrack to get the stack of current process.
But now I need to trace a user space process, with many child process (thread) only when some special event happened, by another process (we can treat it as a temporary debugger). Is there any way to do such things?
ptrace (http://linux.die.net/man/2/ptrace) is a good suggestion but seems no way to trace thread?
update
http://man7.org/linux/man-pages/man2/ptrace.2.html It seem "every thread can be individually attached to a (potentially different) tracer"!?
I have tried to use ptrace to get the stack of the process. but I found I have no permission? I use
ptrace(PTRACE_ATTACH, tid2, NULL, NULL);
but -1 is return, and errno is 1(Operation not permitted)
Do I miss something?
I work on an android platform. It seems I have no permission to attach some process? (gdb tool is root, but my app is not.)
If you want to attach to a process, there MUST be a parent/child relationship between you process and that to be attached, or your process run as root.
My native process runs under root on Android device. Is it possible to modify UID of another process in order to give it the root?
The reason is to give an access to some Android "features" that inaccessible for non-root processes.
If you have a rooted phone, you can run processes explicitly using (usually) /system/xbin/su. You can't change the uid of a program that's already running, though. (In theory you could poke at kernel memory and change all the various stored uids, but this is a really bad idea because you can't lock the things you're modifying and if they change or move you could cause a kernel panic.)
No. If another app needs root access it needs to gain permissions itself.
You need make a exec bin(A) run as root and do:
attach to the process which you want to change the uid
get the state of the process and save
call the setuid system call remote
use the saved state to detach the process.
All above can be done by ptrace.
More info can be found here:
http://www.linuxjournal.com/node/6210/print
http://www.phrack.org/issues.html?issue=59&id=12&mode=txt