grote / Transportr

Free Public Transport Assistant without Ads or Tracking
https://transportr.app
GNU General Public License v3.0
1.04k stars 187 forks source link

Return to trip results freezes app #662

Closed ialokim closed 4 years ago

ialokim commented 4 years ago

Describe the bug At least on emulators, returning from a trip details view to the trip results list causes the app to freeze on current master.

To Reproduce Steps to reproduce the behavior:

  1. Search for a connection
  2. Click on one displayed result
  3. Try to go back using the arrow in the top-left corner or using the phone's back button
  4. See app freezing

Expected behavior It should not freeze.

Versions (please complete the following information):

This might be due to some library upgrade, perhaps also connected to Mapbox rendering problems on emulators?

ialokim commented 4 years ago

adb logcat reports:

D/OpenGLRenderer( 3669): endAllStagingAnimators on 0x9fc41400 (RippleDrawable) with handle 0x9fd90850
I/InputDispatcher( 1541): Application is not responding: Window{dd65784 u0 de.grobox.liberario.debug/de.grobox.transportr.trips.search.DirectionsActivity}.  It has been 5005.8ms since event, 5005.5ms since wait started.  Reason: Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago.  Wait queue length: 49.  Wait queue head age: 5512.4ms.
I/WindowManager( 1541): Input event dispatching timed out sending to de.grobox.liberario.debug/de.grobox.transportr.trips.search.DirectionsActivity.  Reason: Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago.  Wait queue length: 49.  Wait queue head age: 5512.4ms.
I/Process ( 1541): Sending signal. PID: 3669 SIG: 3
I/art     ( 3669): Thread[3,tid=3676,WaitingInMainSignalCatcherLoop,Thread*=0xb3c26c00,peer=0x12c000a0,"Signal Catcher"]: reacting to signal 3
I/art     ( 3669): Wrote stack traces to '/data/anr/traces.txt'
I/Process ( 1541): Sending signal. PID: 1541 SIG: 3
I/art     ( 1541): Thread[3,tid=1546,WaitingInMainSignalCatcherLoop,Thread*=0xb3c25c00,peer=0x12c020a0,"Signal Catcher"]: reacting to signal 3
I/art     ( 1541): Wrote stack traces to '/data/anr/traces.txt'
I/Process ( 1541): Sending signal. PID: 1770 SIG: 3
I/art     ( 1770): Thread[3,tid=1779,WaitingInMainSignalCatcherLoop,Thread*=0xb3c26000,peer=0x12c000a0,"Signal Catcher"]: reacting to signal 3
I/art     ( 1770): Wrote stack traces to '/data/anr/traces.txt'
I/Process ( 1541): Sending signal. PID: 1670 SIG: 3
I/art     ( 1670): Thread[3,tid=1678,WaitingInMainSignalCatcherLoop,Thread*=0xb3c26000,peer=0x12c000a0,"Signal Catcher"]: reacting to signal 3
I/art     ( 1670): Wrote stack traces to '/data/anr/traces.txt'
W/AudioFlinger( 1160): write blocked for 41524 msecs, 4 delayed writes, thread 0xb58ac000
E/audio_hw_generic( 1160): Error opening input stream format 1, channel_mask 0010, sample_rate 16000
I/AudioFlinger( 1160): AudioFlinger's thread 0xb5938000 ready to run
W/AudioTrack( 1541): AUDIO_OUTPUT_FLAG_FAST denied by client
I/MicrophoneInputStream( 1979): mic_started gzi@55f44a
W/art     ( 1979): Long monitor contention event with owner method=int android.media.AudioRecord.native_setup(java.lang.Object, java.lang.Object, int, int, int, int, int[]) from AudioRecord.java:4294967294 waiters=0 for 879.313s
I/MicrophoneInputStream( 1979): mic_close gzi@55f44a
W/ConcurrentUtils( 1979): Task ThreadChanger: gwy.nE(String) took 879324ms, which is over the 300000ms threshold
I/HotwordRecognitionRnr( 1979): Hotword detection finished
I/HotwordRecognitionRnr( 1979): Stopping hotword detection.
E/ActivityManager( 1541): ANR in de.grobox.liberario.debug (de.grobox.liberario.debug/de.grobox.transportr.trips.search.DirectionsActivity)
E/ActivityManager( 1541): PID: 3669
E/ActivityManager( 1541): Reason: Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago.  Wait queue length: 49.  Wait queue head age: 5512.4ms.)
E/ActivityManager( 1541): Load: 0.24 / 0.19 / 0.31
E/ActivityManager( 1541): CPU usage from 3485ms to -1746ms ago:
E/ActivityManager( 1541):   7% 1541/system_server: 3.8% user + 3.2% kernel / faults: 3827 minor
E/ActivityManager( 1541):   0.3% 1156/debuggerd: 0% user + 0.2% kernel / faults: 863 minor
E/ActivityManager( 1541):   1.1% 1770/com.android.phone: 0% user + 1.1% kernel / faults: 1396 minor
E/ActivityManager( 1541):   0.7% 1670/com.android.systemui: 0.3% user + 0.3% kernel / faults: 883 minor
E/ActivityManager( 1541):   0.7% 3669/de.grobox.liberario.debug: 0.7% user + 0% kernel / faults: 1021 minor
E/ActivityManager( 1541):   0.1% 1154/adbd: 0% user + 0.1% kernel / faults: 84 minor
E/ActivityManager( 1541):   0.3% 3690/kworker/1:2: 0% user + 0.3% kernel
E/ActivityManager( 1541): 5.7% TOTAL: 2.7% user + 2.7% kernel + 0.2% iowait
E/ActivityManager( 1541): CPU usage from 1237ms to 1740ms later:
E/ActivityManager( 1541):   4% 1541/system_server: 4% user + 0% kernel / faults: 38 minor
E/ActivityManager( 1541):     4% 1554/GCDaemon: 4% user + 0% kernel
E/ActivityManager( 1541):     2% 1551/FinalizerDaemon: 0% user + 2% kernel
E/ActivityManager( 1541):     2% 1560/ActivityManager: 2% user + 0% kernel
E/ActivityManager( 1541): 1% TOTAL: 1% user + 0% kernel
I/OpenGLRenderer( 1541): Initialized EGL, version 1.4
D/EGL_emulation( 1541): eglCreateContext: 0xae62f160: maj 2 min 0 rcv 2
D/EGL_emulation( 1541): eglMakeCurrent: 0xae62f160: ver 2 0
D/EGL_emulation( 1541): eglMakeCurrent: 0xae62f160: ver 2 0
I/Choreographer( 1541): Skipped 31 frames!  The application may be doing too much work on its main thread.
W/ActivityManager( 1541): Activity destroy timeout for ActivityRecord{1348f833 u0 de.grobox.liberario.debug/de.grobox.transportr.trips.detail.TripDetailActivity t100 f}
ialokim commented 4 years ago

This behavior first happens with commit 9a9e64799a13bf0dae8388d8694309e9693b073b.

May be connected to RecyclerView 1.0.0 > 1.1.0 or Lifecycle 2.1.0 > 2.2.0 update.

ialokim commented 4 years ago

Changing back lifecycle libs to 2.1.0 indeed fixes the issue.

grote commented 4 years ago

That's why we should update libraries directly after a release and never right before it ;)

It would be interesting to know why this happens, after all it might be our fault. One way to find out could be to set strict mode for UIThread access to fatal, so we might get a stack trace and can see where it comes from.