"Dictionary lookup canceled" can be stuck

LittleBiG · 11-29-2020, 06: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.

pazos · 11-29-2020, 11:59 AM

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.../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.

LittleBiG · 11-29-2020, 12:35 PM

Quote:

Originally Posted by 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.../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.)

Frenzie · 11-29-2020, 01: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.

NiLuJe · 11-29-2020, 04: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).

Frenzie · 11-30-2020, 05:08 AM

Quote:

Originally Posted by 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.

NiLuJe · 11-30-2020, 10: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.

yparitcher · 11-30-2020, 07: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

NiLuJe · 11-30-2020, 07: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).

yparitcher · 11-30-2020, 07: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.

Frenzie · 12-01-2020, 03:40 PM

Quote:

Originally Posted by NiLuJe

@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.

I doubt it, but of course the program's usable enough for the most part and your CPU is faster than mine. I could give it a try on my work laptop, annoyingly it's actually noticeably faster than my desktop. (Of course my desktop has a 2014 CPU and my work laptop a 2019 or 2020 one.)

NiLuJe · 12-01-2020, 05:27 PM

The startup is painful, for sure, but once CRe is up and running, I'm getting ~50ms page renders and 30ms blits, which is barely worse than on a device ^^. (Well, it's worse because the default window size is way tinier than a device, but, still ;p).

LittleBiG · 01-19-2021, 11:31 AM

I have managed to catch the stuck dictionary search. However, thanks to the recent modifications, it stuck at the "searching dictionary..." message.
I first chose the "Since" to look up, but as fuzzy was not set, it didn't come up with anything. I chose the edit, and modified the capital S to small s, and did the search again. I flipped some pages among the dictionaries then closed the window. Then I chose another word "fiction" to search. But it never appeared, I had to tap the "searching dictionary" window to be able to continue reading. Please check the attached verbose debug log. Thanks in advance.
crash.txt

NiLuJe · 01-19-2021, 12:38 PM

@LittleBiG: This will be *much* easier to track on GitHub, I think.

LittleBiG · 01-19-2021, 01:28 PM

Quote:

Originally Posted by NiLuJe

@LittleBiG: This will be *much* easier to track on GitHub, I think.

Thanks. I have just opened #7173

11-29-2020, 06:46 AM	#1
LittleBiG Zealot Posts: 122 Karma: 10 Join Date: Nov 2014 Device: Kindle Oasis 3, K4NT, Kobo Mini	"Dictionary lookup canceled" can be stuck 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.

11-29-2020, 04:07 PM	#5
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	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). Last edited by NiLuJe; 11-29-2020 at 04:11 PM.

11-30-2020, 07:38 PM	#9
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	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). Last edited by NiLuJe; 11-30-2020 at 07:42 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
dictionary "Le nouveau Littré" (modern version of a french dictionary	akorx	Kobo Reader	18	05-15-2021 02:35 AM
Customize "Lookup/search word"?	Andy P	Library Management	2	04-26-2020 10:35 PM
E-book viewer: "Lookup words" window	iG0R	Calibre	26	04-18-2020 09:20 PM
Dictionary lookup in iBooks 1.1: "Dictionary not available for this language"	kjk	Apple Devices	71	09-18-2010 06:24 AM
potentially stupid "lookup" function question	rheostaticsfan	Bookeen	4	09-12-2008 06:30 PM

11-29-2020, 11:59 AM	#2
pazos cosiñeiro Posts: 1,271 Karma: 2200049 Join Date: Apr 2014 Device: BQ Cervantes 4	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.../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.

11-29-2020, 01:30 PM	#4
Frenzie Wizard Posts: 1,619 Karma: 724945 Join Date: Oct 2014 Location: Antwerp Device: Kobo Aura H2O	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.

11-30-2020, 10:26 AM	#7
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	@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.

11-30-2020, 07:08 PM	#8
yparitcher Connoisseur Posts: 52 Karma: 616590 Join Date: Feb 2019 Device: K4 KT4 PW4 PW5	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

11-30-2020, 07:59 PM	#10
yparitcher Connoisseur Posts: 52 Karma: 616590 Join Date: Feb 2019 Device: K4 KT4 PW4 PW5	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.

12-01-2020, 05:27 PM	#12
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	The startup is painful, for sure, but once CRe is up and running, I'm getting ~50ms page renders and 30ms blits, which is barely worse than on a device ^^. (Well, it's worse because the default window size is way tinier than a device, but, still ;p).

01-19-2021, 11:31 AM	#13
LittleBiG Zealot Posts: 122 Karma: 10 Join Date: Nov 2014 Device: Kindle Oasis 3, K4NT, Kobo Mini	I have managed to catch the stuck dictionary search. However, thanks to the recent modifications, it stuck at the "searching dictionary..." message. I first chose the "Since" to look up, but as fuzzy was not set, it didn't come up with anything. I chose the edit, and modified the capital S to small s, and did the search again. I flipped some pages among the dictionaries then closed the window. Then I chose another word "fiction" to search. But it never appeared, I had to tap the "searching dictionary" window to be able to continue reading. Please check the attached verbose debug log. Thanks in advance. crash.txt

01-19-2021, 12:38 PM	#14
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	@LittleBiG: This will be much easier to track on GitHub, I think.