Skip to content
This repository has been archived by the owner on Jan 23, 2024. It is now read-only.
This repository has been archived by the owner on Jan 23, 2024. It is now read-only.

Gastly crashes GoIV #135

Closed
rpgrca opened this issue Aug 22, 2016 · 7 comments · Fixed by #164
Closed

Gastly crashes GoIV #135

rpgrca opened this issue Aug 22, 2016 · 7 comments · Fixed by #164
Labels

Comments

@rpgrca
Copy link

rpgrca commented Aug 22, 2016

  1. Start service
  2. Try to scan Gastly, 4 out of 5 times the IV button just disappears.
  3. Go back to GoIV screen, click STOP button, the application closes with "Unfortunately, GoIV has stopped.".

Samsung Note 5, 6.0.1, GoIV 2.1.0. It didn't happen with the last version from the Play Store, it would just fail to recognize the CP when the smoke covered it.

@aa8y
Copy link

aa8y commented Aug 22, 2016

Can confirm. Does the same for me. I see it happen when the smoke around it covers the CP number on the top of the screen. If it the CP is clearly visible, it works just fine and I didn't see this issue in the older version of GoIV as well.

@nahojjjen
Copy link
Collaborator

Are you running 2.1.0 or github version?
As far as I'm aware, I should have fixed all gastly crashes on git main branch.

@aa8y
Copy link

aa8y commented Aug 22, 2016

It's 2.1.0. How do I compile master to make an apk? I am sorry I've never
really worked with Android apps.

On 22 Aug 2016 4:00 p.m., "nahojjjen" notifications@github.com wrote:

Are you running 2.1.0 or github version?
As far as I'm aware, I should have fixed all gastly crashes on git main
branch.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#135 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFYYmNE0t9n1oBm8Md3fJUFv6dG29ncsks5qihvzgaJpZM4JqIDH
.

@rpgrca
Copy link
Author

rpgrca commented Aug 23, 2016

Tried the github version, and looks like it's been fixed for similar cases as well (Koffing, Weezing, etc). Thanks!

@rpgrca
Copy link
Author

rpgrca commented Aug 23, 2016

By the way, if you are in a Pokemon screen, scroll up the page (so that the CP goes out of scope) and press the IV button, it disappears and when you stop the service it crashes as it did with the Gastly problem.

@jehy
Copy link
Contributor

jehy commented Aug 23, 2016

Confirmed problem in 2.2.0 version with latest commit "Adjust Arc": when screen scrolled up - IV button disappears, nothing happens and when GoIV is closed, following error occures:

08-23 13:01:18.568 31750-31750/com.kamron.pogoiv.nointernet E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.kamron.pogoiv.nointernet, PID: 31750
java.lang.RuntimeException: Unable to stop service com.kamron.pogoiv.Pokefly@c5cb63d: java.lang.IllegalArgumentException: View=android.widget.ImageView{6a8b94 V.ED..... ......I. 0,0-0,0} not attached to window manager
at android.app.ActivityThread.handleStopService(ActivityThread.java:3116)
at android.app.ActivityThread.access$2300(ActivityThread.java:154)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1494)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:234)
at android.app.ActivityThread.main(ActivityThread.java:5526)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
Caused by: java.lang.IllegalArgumentException: View=android.widget.ImageView{6a8b94 V.ED..... ......I. 0,0-0,0} not attached to window manager
at android.view.WindowManagerGlobal.findViewLocked(WindowManagerGlobal.java:424)
at android.view.WindowManagerGlobal.removeView(WindowManagerGlobal.java:350)
at android.view.WindowManagerImpl.removeView(WindowManagerImpl.java:113)
at com.kamron.pogoiv.Pokefly.onDestroy(Pokefly.java:224)
at android.app.ActivityThread.handleStopService(ActivityThread.java:3097)
at android.app.ActivityThread.access$2300(ActivityThread.java:154) 
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1494) 
at android.os.Handler.dispatchMessage(Handler.java:102) 
at android.os.Looper.loop(Looper.java:234) 
at android.app.ActivityThread.main(ActivityThread.java:5526) 
at java.lang.reflect.Method.invoke(Native Method) 

Error is here:

        if (arcPointer != null) windowManager.removeView(arcPointer);

Seems like arcPointer is not attached to windowManager that's why removeView fails. We can just wrap it with try/catch but it is better to solve the initialization problem which causes IV button to never appear again.

@Blaisorblade
Copy link
Collaborator

@jehy I'm working on that crash, I have identified something iffy which might cause it in part.
It seems like sometimes the MainActivity never replies to the Pokefly service?

Blaisorblade added a commit to Blaisorblade/GoIV that referenced this issue Aug 24, 2016
`infoShown` does not reflect correctly whether the `infoLayout` and
`arcPointer` were added or not; `infoShownReceived` is closer but is
cleared if `batterySaver`.

In particular, if the main activity hasn't replied yet to the request to
OCR the pokemon, then `infoShown` is true, while `infoShownReceived`
isn't true yet and `infoLayout` and `arcPointer` aren't shown, causing
the crash. This causes at least a race condition that this PR fixes.

This is the crash shown as `farkam135#3` and `farkam135#33` in Crashlytics.

https://www.fabric.io/goiv/android/apps/com.kamron.pogoiv/issues/57bc2435ffcdc042501dbfa7
https://www.fabric.io/goiv/android/apps/com.kamron.pogoiv/issues/57b57b39ffcdc04250dc0403

Now, not only we have a race condition here, but sometimes the main
activity never replies, making this bug *much* easier to hit. Next
commit fixes that, too.
Blaisorblade added a commit to Blaisorblade/GoIV that referenced this issue Aug 24, 2016
Fix farkam135#135, part 2. This simply ensure that we answer back with an intent
even when we found no pokemon, so that we reset the state of the various
state flags used by `Pokefly` and `MainActivity`.
Blaisorblade added a commit to Blaisorblade/GoIV that referenced this issue Aug 24, 2016
Use `try...finally` to ensure we answer with an intent no matter what.
ALso for farkam135#135.
Blaisorblade added a commit to Blaisorblade/GoIV that referenced this issue Aug 24, 2016
`infoShown` does not reflect correctly whether the `infoLayout` and
`arcPointer` were added or not; `infoShownReceived` is closer but is
cleared if `batterySaver`.

In particular, if the main activity hasn't replied yet to the request to
OCR the pokemon, then `infoShown` is true, while `infoShownReceived`
isn't true yet and `infoLayout` and `arcPointer` aren't shown, causing
the crash. This causes at least a race condition that this PR fixes.

This is the crash shown as `farkam135#3` and `farkam135#33` in Crashlytics.

https://www.fabric.io/goiv/android/apps/com.kamron.pogoiv/issues/57bc2435ffcdc042501dbfa7
https://www.fabric.io/goiv/android/apps/com.kamron.pogoiv/issues/57b57b39ffcdc04250dc0403

Now, not only we have a race condition here, but sometimes the main
activity never replies, making this bug *much* easier to hit. Next
commit fixes that, too.
Blaisorblade added a commit to Blaisorblade/GoIV that referenced this issue Aug 24, 2016
Fix farkam135#135, part 2. This simply ensure that we answer back with an intent
even when we found no pokemon, so that we reset the state of the various
state flags used by `Pokefly` and `MainActivity`.
Blaisorblade added a commit to Blaisorblade/GoIV that referenced this issue Aug 24, 2016
Use `try...finally` to ensure we answer with an intent no matter what.
ALso for farkam135#135.
Blaisorblade added a commit that referenced this issue Sep 18, 2016
The evolution spinner shows numbers next to each Pokemon's evolution, so
sorting them alphabetically gives us a strange order for Eevee, which
happens to be `#136 Flareon #135 Jolteon #134 Vaporeon` rather than
ascending order.
Blaisorblade added a commit that referenced this issue Sep 18, 2016
The evolution spinner shows numbers next to each Pokemon's evolution, so
sorting them alphabetically gives us a strange order for Eevee, which
happens to be `#136 Flareon #135 Jolteon #134 Vaporeon` rather than
ascending order.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants