2012-07-10 9 views
9

Pracuję nad aplikacją, która rejestruje dane przez Bluetooth, ale z przerwami po godzinach zbierania danych (co utrudnia odnalezienie błędu).Aplikacja umiera z "Wysyłanie sygnału". ale bez wyjątków i innych informacji

Wyjście logcat nie jest bardzo pomocne:

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

Brak rzucone wyjątki i żadnych wskazówek na to, co spowodowało, że proces jest zakończony.

Jak mogę dowiedzieć się, co poszło nie tak? Czy jest wyrzucany wyjątek, którego nie pokazuje logcat? Jak mogę śledzić ten błąd?

Odpowiedz

8

Sygnał 9 to SIGKILL, który natychmiast przerwie proces (nie zostaną uruchomione żadne procedury obsługi w procesie). Z linii dziennika proces sam się zabija, więc nie jest zewnętrznym agentem, który wydaje SIGKILL.

Domyślam się, że kod zarządzania pamięcią działający wewnątrz twojego procesu (jako część infrastruktury, a nie kodu, który napisałeś) decyduje, że wyczerpałeś część zasobów i jedynym rozwiązaniem jest umrzeć. Spodziewam się, że pojawi się więcej komunikatów, zanim ten punkt zostanie osiągnięty w dzienniku, więc może warto przejrzeć historię dziennika, aby sprawdzić, czy istnieją użyteczne ostrzeżenia przed procesem.

Linia bezpośrednio przed tym jest logiem GC, co oznacza, że ​​jakiś zasób pamięci jest na wyczerpaniu. Wygląda jednak na to, że sterty nie są pełne, więc nieudane przydzielanie wydaje się mało prawdopodobne. Nadal można uzyskać awarie przydzielania, jeśli przydzielany obiekt był zbyt duży, aby zmieścił się na stercie, lub fragmentacja uniemożliwiła jego przydzielenie. Spodziewam się jednak, że w tym przypadku pojawią się bardziej odpowiednie komunikaty dziennika.

Wydaje mi się, że przechwycenie większej ilości dziennika (w razie potrzeby filtrowanie go za pomocą PID aplikacji) pomoże w osiągnięciu postępu.

+3

Miałeś rację, w dzienniku znajdowały się informacje, które przeoczyłem. Dzięki! – 9us

3

W moim przypadku nie było żadnych ostrzeżeń ani żadnych wskazówek w dzienniku.

Ostatecznie odkryłem, że moim problemem było to, że jednym z działań jadę do
(powiedzmy aktywny X) została rejestracji do odbiornika transmisji ale nigdy niezarejestrowany od niego.

Przeto zamykając aktywności (aktywność X) i powraca do niego spowodowane rejestracji ponownie do tego samego odbiornika transmisji - który spowodował bałagan!

Po prostu dodanie unregisterReceiver(mybroadcast); (w Działaniu X) rozwiązało to.
(Dodałem kopalnię do OnDestroy, upewnij się, że wyrejestrujesz się w right location).

A jeśli jesteś bardzo zdesperowany, polecam zobaczyć ten slajd, który wyjaśnia, że ​​twoje błędy to Android crash debugging.

+0

Dzięki. To nie rozwiązało mojego problemu "no exception", ale naprawiłem kolejny nieprzyjemny błąd, którego nie mogłem wykryć :) – goodfellow

Powiązane problemy