[Help] D/Zygote ( 909): Process 7668 terminated by signal (11)

[Baodong Chen]

Hi All:
I have a android program using java and ndk, when i run my program
on device, it works well for a few hours, after that, it quit and in
logcat's output, i Got :

D/Zygote ( 909): Process 7668 terminated by signal (11)
I/ActivityManager( 1017): Process xxx (pid 7668) has died.

i have read logcat's output carefully but i did not find any usful
messages about why my program quit.
can anyone give me some suggestions?

best regards, thanks!

[David Turner]

Signal 11 is a segmentation fault. You should see a stack trace with a lot more details about this before the logcat message you show here.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Baodong Chen]

Hi David Turner:
thanks for your reply.
i have checked logcat's output, but there is no stack trace in it. i
also thought
there should be a stack trace.
i am wondering why???

[David Turner]

The only cases where a stack trace wouldn't be sent to logcat are the following:

- running a static executable (i.e. not a standard Dalvik process, or even a straight dynamic executable)

- the program has re-directed the SIGSEGV signal handler and fails to sent useful information to the log.

In all other cases, the dynamic linker sets up a default SIGSEGV signal handler before your process is being run, and this handler sends a signal to the debuggerd process to ptrace attach to the crashing process, extract information and dump a stack trace to the log.

What exactly is your program doing?

[Baodong Chen]

my program works as follows:
when it starts in java, it loads a .so file for JNI,than it create a
child process using fork() and execl(),
the child communicates using socket with it's parent.most parts of my
program are native C\C++ code. only a little java code.
java and native code communicates using JNI.
that is how my program works.

[alan]

I have seen occasional missing stack traces myself when just running a normal library inside a java app. As far as I can remember the problems were all memory corruption errors

[Baodong Chen]

what kinds of memory corruption can cause this?
stack overflow? invalid point dereference ? or what else ?

> --
> You received this message because you are subscribed to the Google Groups
> "android-ndk" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/android-ndk/-/SGx3OUJUTDRIR1lK.

[David Turner]

On Fri, Jun 3, 2011 at 12:10 PM, Baodong Chen <chenbd...@gmail.com> wrote:

my program works as follows:
when it starts in java, it loads a .so file for JNI,than it create a
child process using fork() and execl(),

Ah, fork() and execl(), what kind of program are you executing. If this is a static executable, then this is normal (and it is probably buggy).

[Baodong Chen]

my child process,as part of my app, built by ndk, is a executable program.
but even if it is buggy, i don't think it will cause my app to quit.
because it is
a child process, it should not affect it's parent, am i right?

[David Turner]

On Fri, Jun 3, 2011 at 3:54 PM, Baodong Chen <chenbd...@gmail.com> wrote:

my child process,as part of  my app, built by ndk, is a executable program.
but even if it is buggy, i don't think it will cause my app to quit.
because it is
a child process, it should not affect it's parent, am i right?

Not sure. Generally speaking, we do not support fork()/exec() in Android applications, so all bets are off.

(Which means we don't guarantee any behaviour in this case, nor do we guarantee that you'll be able to fork() or exec() from an application in the future).

[Olivier Guilyardi]

On 06/03/2011 04:28 PM, David Turner wrote:
>
>
> On Fri, Jun 3, 2011 at 3:54 PM, Baodong Chen <chenbd...@gmail.com
> <mailto:chenbd...@gmail.com>> wrote:
>
> my child process,as part of my app, built by ndk, is a executable
> program.
> but even if it is buggy, i don't think it will cause my app to quit.
> because it is
> a child process, it should not affect it's parent, am i right?
>
> Not sure. Generally speaking, we do not support fork()/exec() in Android
> applications, so all bets are off.
> (Which means we don't guarantee any behaviour in this case, nor do we
> guarantee that you'll be able to fork() or exec() from an application in
> the future).

Side question (and a possible alternative): is it ok to start a long running
process with Runtime.exec() ?

I mean, something which would act as an engine, with which the app would
interact using sockets and such. If I ever do that, I would start the process
from a service I guess.

--
Olivier

[Baodong Chen]

you mean, i should not use fork() and execl() in my program? but the NDK have
this headers and i use them in my native code, and they works. these
will not supported
in the futrue? if so, how can my app(using java and native c/c++) to
create another process
and communicate with? what is the best way to do this?

[Dianne Hackborn]

On Fri, Jun 3, 2011 at 7:42 AM, Olivier Guilyardi <li...@samalyse.com> wrote:

Side question (and a possible alternative): is it ok to start a long running

process with Runtime.exec() ?

No, the correct way to perform long-running background operations is with a Service.  The system may freely kill any processes you fork yourself, at any time, at its whim.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[David Turner]

On Fri, Jun 3, 2011 at 5:19 PM, Baodong Chen <chenbd...@gmail.com> wrote:

you mean, i should not use fork() and execl() in my program?  but the NDK have
this headers and i use them in my native code, and they works.

The headers come from the system's C library which does support fork() and exec().

However, applications are different from other parts in the system in Android in various ways.

One issue with child processes is how they interfere with the per-application resource accounting performed by the kernel.

Another issue is that on Android, the system is free to force-kill any application process to make room for other ones when there is a need for it.

There is a complicated algorithm used to determine which processes to kill in this case, and it doesn't account for child processes liberally created by applications.

In other words, under certain conditions, the system could simply decide to kill your child processes at any time, while it considers it should keep your main application process (e.g. because it is currently displaying an activity and interacting with the user). Your code might better be ready to handle this.

The behaviour of the system with regards to application child processes is thus not fixed and may change in the future.

We may also decide to simply disallow fork() from application processes one day (I could imagine several reasons to do that).

these
will not supported
in the futrue? if so, how can my app(using java and native c/c++)  to
create another process
and communicate with? what is the best way to do this?

There is absolutely no recommended way to do this, period. This doesn't fit the Android application lifecycle model.

You could still define services in your application and declare them to run in their own process in your application manifest (read the documentation).

But these will be started through Dalvilk / Zygote like other app processes, not through explicit fork()/exec()/

[Baodong Chen]

Thanks for these helpful information. I will check when i do not
create the child process,
whether my program will quit or not. if it will still quit, i think it
is not the child procss which
cause my program to quit, maybe some other reasons cause this.

[Olivier Guilyardi]

On 06/03/2011 08:43 PM, Dianne Hackborn wrote:
> On Fri, Jun 3, 2011 at 7:42 AM, Olivier Guilyardi <li...@samalyse.com
> <mailto:li...@samalyse.com>> wrote:
>
> Side question (and a possible alternative): is it ok to start a long
> running
> process with Runtime.exec() ?
>
>
> No, the correct way to perform long-running background operations is
> with a Service. The system may freely kill any processes you fork
> yourself, at any time, at its whim.

Is this still true if the process is started by a service, and gets cleanly
terminated by the service when it's destroyed? I mean, if the process is
completely managed by a service.

--
Olivier

[David Turner]

Yes, of course. Processes are managed by the system, not by services.

 

--
 Olivier

[niels]

Hi all,

I also mentioned a similar problem in this thread and unfortunately
didn't receive any answers:
http://groups.google.com/group/android-ndk/browse_thread/thread/85cf36461213e7b4

Finally I was able to fix my problem. Please see the appropriate
thread, maybe it helps.

Regards,
Niels

[Baodong Chen]

thanks for this information, I will check my sources to see whether there is
a stack overflow.

[Baodong Chen]

last night,i run my program on device again, this time I do not create
the child process
and it still quit this morning, but i got a different logcat's output
as follows from last time:

E/dalvikvm-gc(15315): Could not create 3207168-byte ashmem mark stack:
Too many open files
E/dalvikvm-heap(15315): dvmHeapBeginMarkStep failed; aborting
E/dalvikvm(15315): VM aborting
I/ActivityManager( 991): Process xxx (pid 15315) has died.
I/WindowManager( 991): WIN DEATH: Window{45123898
com.mansiontech.mxnavi/com.mansiontech.mxnavi.MXNavi paused=false}
D/Zygote ( 909): Process 15315 terminated by signal (11)

I think it is out of memory, and there are bugs in my program that
open files and do not close them.