Mobileread
"Dictionary lookup canceled" can be stuck
#1  LittleBiG 11-29-2020, 07:46 AM
I am really into the dictionaries, I have many on my readers. There is a KOreader feature: on dictionary lookup you can tap the "Seraching dictionary for:" message and the lookup will be cancelled immediately.
But this could happen quite unexpectedly. When you search for a common word and many dictionaries are searched, the result window appears, and you switch back and forth between dictionaries to check all results. But sometimes when you close the results and choose another word to look up, instead of the results the "Dictionary lookup canceled" message appears immediately. After that, you are not able to look up anything because you will constantly get that message until you restart KOreader.

I know this is a very special bug, and could be huge work to locate. Everything could affect it: slower reader, a lots of big dictionaries and so on, so I don't ask for really eliminate this bug. Rather I am wondering if somebody could do a simple workaround: when the dictionary search is starting, please empty out the variable or something which indicates that the search is cancelled. Or maybe when a search starts, KOreader thinks incorrectly, that a tap happened and cancels the search, so maybe the stack of taps should be emptied out. I think this kind of reset on start could prevent this bug. Thanks, if sombody could do anything about.
Reply 

#2  pazos 11-29-2020, 12:59 PM
No bug is special (or all of them are ). Some of them are tricky to reproduce.

A bug report requires a test case or, at least, the steps to reproduce it (see https://github.com/koreader/koreader/blob/master/.github/ISSUE_TEMPLATE/bug_report.md).

Github is probably the best place to talk about bugs. The forum is *ok* as long as you fill the same info (device, program version ...)

So, the steps you'll need to do:

1. Reduce your paragraph to a test case or a number of steps to trigger the bug.
2. Check that you can reproduce the bug against the very last version of the program.
3. Attach a bug report (here or github) with all the info needed, including a debug log and your current settings.

Also, please don't mix bug reporting with guesses about how the program works or how the bug could be fixed. It usually doesn't help to understand the bug. Much better to stick with bug templates.
Reply 

#3  LittleBiG 11-29-2020, 01:35 PM
Quote pazos
No bug is special (or all of them are ). Some of them are tricky to reproduce.

A bug report requires a test case or, at least, the steps to reproduce it (see https://github.com/koreader/koreader/blob/master/.github/ISSUE_TEMPLATE/bug_report.md).

Github is probably the best place to talk about bugs. The forum is *ok* as long as you fill the same info (device, program version ...)

So, the steps you'll need to do:

1. Reduce your paragraph to a test case or a number of steps to trigger the bug.
2. Check that you can reproduce the bug against the very last version of the program.
3. Attach a bug report (here or github) with all the info needed, including a debug log and your current settings.

Also, please don't mix bug reporting with guesses about how the program works or how the bug could be fixed. It usually doesn't help to understand the bug. Much better to stick with bug templates.
Yes, you are right, correcting a bug is relaltively easy if you have these pieces of information. (I am actually a developer but unfortunately in very different environment, otherwise I would do my contribution to KOreader for sure, and would chase this bug by myself.) But as I mentioned, I do not have a definite step sequence to trigger the bug. It seems to be random, which rather means there are too much factors (or think of a bug which only happens when a limit in a code is exceeded, you cannot always say when it happens exactly, like when something would run out). You can easily do the same steps again and you will get stuck on a very different point, or it is even possible that it won't happen in a reading period, then more times in the next.
OK, so this bug will remain with us for a while.

Then please, answer a question. this kind of problem could be seen in the debug log? So if I keep using my dictionaries and when the "directory lookup canceled" will be stuck again, could it be something in the debug log which couls show what triggered the "directory lookup canceled" at the very beginnign of the search? (Because it is not something which ends up in an error message or a crash of the application.)
Reply 

#4  Frenzie 11-29-2020, 02:30 PM
If you enable verbose logging, at the very least the word(s) you're looking up will show up in the log. You'll then presumably also see a touch event right after that canceled the lookup.
Reply 

#5  NiLuJe 11-29-2020, 05:07 PM
Without checking anything, my wild guess would be this is probably happening in/because of Trapper, which means it's probably going to be extremely nasty to deal with in any sane way, and an actual reliable repro would alleviate the hair pulling by a moderate factor.

And the good news is that, yes, it logs.

(This also may be far easier to repro on older/slower devices, which doesn't help).
Reply 

#6  Frenzie 11-30-2020, 06:08 AM
Quote NiLuJe
(This also may be far easier to repro on older/slower devices, which doesn't help).
Just run the emulator in Valgrind. It's plenty slow.
Reply 

#7  NiLuJe 11-30-2020, 11:26 AM
@Frenzie: I was going to say that I was actually surprised by how CRe manages, but, actually I'm currently running it under callgrind, which probably has a lower overhead ;p.
Reply 

#8  yparitcher 11-30-2020, 08:08 PM
I have had this issue also on my PW4.

I tried running the emulator in valgrind to slow it down but my computer is too new and the AVX-512 generated by --march=native crashes valgrind
Reply 

#9  NiLuJe 11-30-2020, 08:38 PM
Huh. Well, that leaves rebuilding with -march=skylake (I can vouch for that one being AVX512-free ^^), or trying under GDB, or an instrumented build for perf, or ASAN/MSAN & friends ^^.

EDIT: Except I'm guessing the AVX comes from the libc's memset/memcpy, so, nope on the rebuild ;p. (__memcpy_avx_unaligned_erms is certainly getting a good workout over here ;p).
Reply 

#10  yparitcher 11-30-2020, 08:59 PM
I am not building libc with --march=native it is only the default for koreader, it is in luajit and mupdf, i am just too lazy to delete each library and rebuild.
Reply 

  Next »  Last »  (1/2)
Today's Posts | Search this Thread | Login | Register