System_server_crash

In this post I am going to discuss about system_server crash .

It is obvious to see the system server crash if you do some automated testing

the main reasons are
 1. component running in the system_server process has crashed
 2. something has caused the system_server's process primary looper
thread to deadlock


Ok,now lets take the first case component crash
   By seeing the logcat trace you can find out which component is crashing.
also you can get the call stack for this crash. you can take respective action .

lets move on to the second one , the deadlock situation
    The deadlock case is announced by a line in the
logcat buffer reading something very like this:

04-04 14:06:16.888   885  1089 W Watchdog: *** WATCHDOG KILLING SYSTEM
PROCESS: null  

when we talk about Deadlock , then we need thread's info
you can get this info in /data/anr/traces.txt

------ VM TRACES AT LAST ANR (/data/anr/traces.txt: 2011-04-04 14:06:14) ------

and the file holds *two* sets of system_process stacks.  One of them
starts like this:

----- pid 885 at 2011-04-04 14:05:42 -----
Cmd line: system_server

and the second starts like this:

----- pid 885 at 2011-04-04 14:06:12 -----
Cmd line: system_server

Note that the first was taken 30 seconds before the second, and the
second was just a few seconds before the watchdog message about
killing the system process to restart the system.  The watchdog takes
a thread snapshot after 30 seconds of the looper being unresponsive,
then another snapshot after a full minute of unresponsiveness; and
it's after that full minute that it declares the deadlock and restarts
everything.  You probably want to start with the later thread stacks,
the ones that reflect the state of affairs when the watchdog finally
gave up.

and remember , The primary system_process looper thread is titled "android.server.ServerThread"

Note:this post is crafted based on my experience and taken from some sources.