2012-07-10 9 views
9

Estoy trabajando en una aplicación que está grabando datos a través de Bluetooth, pero se bloquea intermitentemente después de horas de recopilación de datos (por lo que es difícil rastrear el error).La aplicación se cierra con "Señal de envío". pero no hay excepción u otra información

La salida Logcat no es muy útil:

http://i.imgur.com/EalnX.png

No hay excepciones lanzadas y no hay indicios de lo que causó que el proceso se termina.

¿Cómo puedo averiguar qué salió mal? ¿Hay una excepción lanzada que logcat no muestra? ¿Cómo puedo rastrear este error?

Respuesta

8

La señal 9 es SIGKILL, que dará por terminado un proceso inmediatamente (no se ejecutarán manejadores dentro del proceso). Desde la línea de registro, el proceso se está matando a sí mismo, por lo que no es un agente externo que está emitiendo el SIGKILL.

Mi suposición (y es realmente una suposición) es que el código de gestión de memoria que se ejecuta dentro de su proceso (como parte de la infraestructura, no del código que escribió) está decidiendo que ha agotado algún recurso y el único recurso es morir. Esperaría que hubiera más mensajes antes de que se llegue a este punto en el registro, por lo que puede valer la pena examinar el historial de registro para ver si hay advertencias útiles del proceso antes de este punto.

La línea inmediatamente anterior es un registro de GC, lo que implica que algún tipo de recurso de memoria se está agotando. Pero parece que los montones no están llenos, por lo que las asignaciones fallidas parecen poco probables. Todavía puede obtener fallas de asignación si el objeto asignado es demasiado grande para caber en el montón, o la fragmentación impide que se asigne. Aunque esperaría ver mensajes de registro más relevantes en este caso.

Creo que capturar más log (quizás filtrándolo por el PID de su aplicación si es necesario) lo ayudará a progresar.

+3

Tenías razón, había información anterior en el registro que estaba pasando por alto. ¡Gracias! – 9us

3

En mi caso no hubo advertencias ni pistas en el registro.

Finalmente me encontré con que mi problema era que una de las actividades que iba a
(digamos Actividad X) se registra a un receptor de radiodifusión, pero nunca sin registrar de la misma.

Por lo tanto, al cerrar la actividad (Actividad X) y volver a ella causó el registro De nuevo al mismo receptor de difusión, lo que provocó el desastre.

Simplemente agregando unregisterReceiver(mybroadcast); (en la Actividad X) lo resolvió.
(Agregué el mío a onDestroy. Asegúrese de anular el registro en el right location).

Y si está súper desesperado, le recomiendo ver esta diapositiva compartir que explica Android crash debugging sus errores.

+0

Gracias. Esto no solucionó mi problema de "no excepción", pero solucionó otro error desagradable que no pude detectar :) – goodfellow

Cuestiones relacionadas