Hi, I reuploaded my debug log because I think I got multiple duplicates in the last review items.
Could you try uploading again? When I look on the server, I got an upload from Reyki, but not from you.
I reuploaded just now.
According to the log, youâre still on 1.17.2. Could you update to the latest? Iâve added some logging specifically for this issue.
Not sure if this is normal or not, but when I do an ignore, it often ignores the current item plus the previous one. Is that supposed to happen? Am I doing it wrong? This occurs if I ignore an item prior to answering for it.
Had the crash issue again when I opened the app - uploaded my debug log before checking and realizing I hadnât updated to the latest version yet ^^â Weâll see if it still happens with the latest update, hasnât yet but Iâve only opened the app once since updating, soâŠ
Crash bug happened again just now. Uploaded debug log.
No, thatâs not supposed to happen. How have you set up the ignore/undo buttons, and when this happens, are you using them after giving a correct or an incorrect answer? Do you have lightning mode enabled?
It could be different things. Maybe youâre tapping the ignore/undo button twice in quick succession, or maybe the previous question isnât really undone and it just looks that way. Or it could be a bug.
I could look at your debug log and see if I can tell what happened (upload from the Settings screen), but you have to make sure youâre on the latest version (1.17.3) and Iâll need to know roughly when it happened.
1 Like
Unfortunately your log doesnât tell me what caused the crash⊠I have a 1.17.4 coming in that should protect against most possible crashes.
Version 1.17.4, 2019-11-11:
- Long clicking on a subject title / quiz question text will allow copying the text to the clipboard.
- Adding more debug logging for investigation of bugs I canât reproduce.
- Bug fix for correct answers being counted as incorrect.
- Heavy armoring against crashes. It should be much more difficult for the app to crash, and instead the app will log error messages instead. Many possible errors will be ignored now, but at least they should leave a more useful debug log now instead of hard-crashing the app.
2 Likes
Just wanted to let you know that I have found and fixed this bug. I have pushed 1.17.4 to the Play Store, once itâs approved it should fix this problem permanently.
1 Like
Yeah i updated and havenât had it happen so I figured you found it.
Thanks for fixing it.
Was it a problem with some kind of whitespace character or what was the bug?
Well, I donât want to bore you with technical details that may or may not mean anything to you, but hereâs the general idea: it was a subtle timing issue, also known as a race condition.
A lot of the work the app does is done in the background to make sure the app doesnât (for example) freeze up when it talks to the API. Parts of the app send messages to each other to get all the necessary work done. For example, when you correctly answer both reading and meaning for a subject:
- The foreground tells the background to process the review result in the database, and schedule your next review for the subject.
- The background tells the foreground that the subject has changed (new SRS stage, new ânext reviewâ date, âŠ) so that the foreground can show the changes immediately.
- The foreground chooses the next question and tells the background to load the new subject from the database.
- The foreground tells the background to schedule a sync task to sync the review result to the API.
- And a bunch moreâŠ
The problem is/was that steps 2 and 3 can happen at exactly the same time if your device is not too fast and not too slow, but exactly a particular speed. If that happened, the foreground got confused and mixed up the work for steps 2 and 3. And in the worst-case scenario, that means the app is now presenting a question for a new subject, while itâs judging the answer against the old subject that you just finished.
So the app might quiz you on æš which you answer correctly, and then show you ć±±. You type âmountainâ, but the app still thinks youâre on æš so it expects you to answer âtreeâ, so it says âmountainâ is wrong. But the answer is still marked as âincorrectâ on ć±±.
This only goes wrong if the timing is exactly the worst it can possibly be. And thatâs why I canât reproduce it for myself: all of my physical devices are too fast, and all of my emulated devices are too slow, so I never saw that bad timing happen.
The solution is that the foreground now waits until it is done with its own messages before it will pick up new messages from the background. I was a bit sloppy there and I basically had the background just shove a couple of its messages down the foregroundâs throat, whether it was ready for it or not. Usually that works fine, but it turns out it can also go wrongâŠ
4 Likes
Hi,
first of all let me say thank you for all the work you put into this app. I use it every day since the end of August and I really love it. Looking forward to every new option added in the updates.
Quick question about how vocabulary kana is displayed (and sorry if this was asked before).
It seems that, at the moment, all vocubulary kana is displayed in hiragana on the Info page, even if the reading uses the onâyomi readings.
Is it possible to change the ăăă〠to ăżă€ă»ă in this case? As Iâm a visual learner, this would help me greatly.
Thanks again!
Yes, thatâs correct. For kanji, you can set the app to show onâyomi in Katakana via the settings. But for vocab, as far as I know, showing the reading in Katakana is simply incorrect, except for a few cases like foreign loan words and for added emphasis. So if the WaniKani database shows the reading in Hiragana, I show it in Hiragana as well. Iâm prepared to be corrected by more experienced folks, but I donât want to deliberately show incorrect information.
Apart from that, it would be pretty complex to do correctly. The WK data doesnât tell me what readings are used in vocab, so Iâd have to go through the reading character by character, analyzing all possible kanji readings including exceptions, rendaku, and shortened forms using small tsu. Iâd have a hard time knowing when to show Hiragana and when to show Katakana. Let alone situations where vocab uses onâyomi for one kanji and kunâyomi for another. Those situations are somewhat rare, but they do happen occasionally.
1 Like
Did we reach this point? 
Iâm actually having this same crash each time I open the app while itâs already open in the background. From a quick look on the info Android provides on the exception, it seems to be the same thing error each time.
Itâs only a bit annoying, doesnât render the app useless or anything else (the app is great!) but Iâd be happy to look into it if possible 
1 Like
Ha! You canât outsmart me! 
If thereâs text selected in a description, long pressing another part of the text results in a crash.
but only when longpressing on something in the same textbox. When longpressing on a different textbox it doesnât happen
If Android is giving you information about the exception, can you post it (screenshot or copy/paste)? Iâd love to be able to pinpoint whatâs happening there.
Okay, I can reproduce it, but the stack trace doesnât reference any of the appâs own code at all. In fact, based on some googling this seems to be an Android bug that happens when you combine selectable text with text that can contain links.
Iâll have to experiment a little, but I can probably work around this in some way.
I actually have the same thing happening to me. It crashes about 1/2/3 times before it allows me to open the app. Where could I find the exception information?