frequent crashing for first game results in disconnect loss

[smemsh]

Very often (more than half the time, but not every time), the app crashes as soon as someone accepts my seek, if I haven't played in a while (a day or sometimes hours). Phone doesn't have to reboot, but the app has to be well gone from memory. Subsequent games once the first crash happens (and app starts again) are totally fine.

This seems to happen more often when I'm in another app waiting for the match accept. I get the accept vibrate, it foregrounds chess, and immediately crash occurs. I restart, go online again, everything is fine.

I have submitted many crash dumps -- which presumably contain stack unwinds -- to no avail. This has been going on a while, at least many months. I don't remember if it ever didn't happen.

I've lost a lot of points this way. It's lost in the noise if I play a bunch of games in a row, but if I don't have time for a lot of games, I suffer net loss merely by playing.

Let me know if anything besides the crash dumps are needed. They should be under the email used to file this ticket. Thanks.

[TimmyT123]

I remember I had a phone that acted similar. When I had too many apps in the background, I believe Android would need resources (memory) for the foreground app and take away from the background apps. I would close some background apps that I didn't need and everything was fine. I think there may be a way to make chess priority over the other background apps. It would be nice to duplicate the problems that you are having. I'll chat with Jeroen about it. Thank you.

[jcarolus]

Yes, it's most probably a problem with resources. My opinion is that the way the app is put to the foreground seems a bit intrusive (both system-wise and from user experience view).
I suggest we implement a notification to the user that a challenge was accepted, and by clicking on it, open the activity. This way, Android will do the switching of processes and I suspect this will work without crashes. We can also remove the 'app history' rights, which makes the also more appealing to users who do not understand why an app would need these rights.

[smemsh]

It has happened before when the app is in the foreground, it's just that I don't usually sit and wait for someone to accept a seek. I used to think it had to be in the background too but it happened when I was in the app staring at the board also, and more than once. It depends more on how long has elapsed since last playing... if it's been a while then it will crash when the seek is accepted even when only a few seconds have elapsed since switching out of the app (when the app is still fully in memory, presumably, so I take back that it has to be "well gone from memory"). Once it happens, I can start another seek, happily go use a bunch of apps, and once it gets foregrounded it will not crash. It just needs to be "primed" by this first crash.

Now sometimes the app just vanishes from memory under memory pressure and when I switch back to it, the app starts anew and I have to login. This happens when I use a bunch of apps and probably Chess falls off Android's LRU. I think that is normal and expected behavior and not related to this bug. Usually when this bug happens I only go to one other app, the last one used, because I want to keep Chess in memory and expect a game soon. I think this bug is different than just having gotten evicted due to memory pressure.

I actually like the current behavior of buzzing and quickly foregrounding the app... anything to reduce latency of making the first move. Most people only wait a few seconds before concluding you are not present and aborting. However, reducing permissions is a powerful motivation on its own... but, I think this behavior choice is orthogonal to this bug.

Why not look at the stack dump? I marked them clearly in comments that should be attached to the crash reports. Doesn't it inform of the exact exception point?

[jcarolus]

Looking at the stack trace marked "crashes frequently now when accepting a match. never used to a months ago. no changes on my end" it is indeed not a memory issue, just a plain null pointer exception which can be fixed easily. Is that your comment?

I'll go with good fast usability over reducing permissions.

[smemsh]

yes, there were a number of them I submitted, sometimes several in a row. that sounds like mine. but there were many others which might be more clearly marked as belonging to this bug such as including words "foreground" or "background" or "memory." I probably submitted 5-10 with additional comments and 10 more without. later ones would be from this email, earlier ones from a different one with my fullname as the address.

I did look at most of them to see that they were NullPointerException and not a memory exception, which I typically don't submit because the app can't do anything about those.

[jcarolus]

Then something is wrong with reporting or fetching crash reports in the Google Play store. There are only 7 Nullpointer exception reports with user messages attached, none including your key words. Anyway - I think we found the problem.

[smemsh]

it's possible I've exaggerated the number in my memory over time due to frustration with lost points. in future (after next app update) I will submit issue with time of crash report submission and what the exception was.

thanks very much for looking into it...

[TimmyT123]

We believe a NullPointerException has been fixed and using a notification instead of bringing the app to front may be better for Android resources.

[smemsh]

to verify it's really same one, it just happened to me again moments ago, I submitted crash report with subject "instance of bug #110 crash" (oops, wrong bug number, but that's the right crash)

[TimmyT123]

The application version is on 8.7.1, now. It looks like you have 8.7.0.

[TimmyT123]

I'll be able to keep an eye on crashes and ANRs, now. Thanks to Jeroen.

[smemsh]

I didn't realize the update had been pushed, thanks. Just updated and will know within a few days if it's fixed because the crash is pretty reliable.

What I meant though was to check that the recent crash was the same as the one that got fixed, to make sure it isn't a different bug.

In any case, I'll close the bug after a week if I don't see it again with the update. Thanks again for taking a look.

[smemsh]

has not reappeared. thanks.