which KOreader has chances on PB631?

[nhedgehog]

Just recognized it myself and run bt.
But what happend after I quit gdb was that I got a message about not having registered an Adobe ID with the device, this message I have not seen before and it is true, I did not have registered it with Adobe.

[nhedgehog]

New crashlog, did a "where" and a "bt" command.

[pazos]

Originally Posted by nhedgehog

Just recognized it myself and run bt.
But what happend after I quit gdb was that I got a message about not having registered an Adobe ID with the device, this message I have not seen before and it is true, I did not have registered it with Adobe.

The adobe ID stuff is very fishy, but I have no idea.

The backtrace points to the garbage collector failing to free some memory. Not sure if it is a bug in the code because that will affect all models and all other platforms.

Anyways, could you try to reproduce with:

diff --git a/frontend/device/pocketbook/device.lua b/frontend/device/pocketbook/device.lua
index 84c76061..8f36586e 100644
--- a/frontend/device/pocketbook/device.lua
+++ b/frontend/device/pocketbook/device.lua
@@ -10,6 +10,13 @@ require("ffi/posix_h")
 require("ffi/linux_input_h")
 require("ffi/inkview_h")
 
+ffi.cdef[[
+    void *mmap(void *addr, size_t length, int prot, int flags, int fd, size_t offset);
+    int munmap(void *addr, size_t length);
+]]
+
+
+
 -- FIXME: Signal ffi/input.lua (brought in by device/input later on) that we want to use poll mode backend.
 -- Remove this once backend becomes poll-only.
 _G.POCKETBOOK_FFI = true
@@ -17,6 +24,14 @@ _G.POCKETBOOK_FFI = true
 local function yes() return true end
 local function no() return false end
 
+local function isModelBroken()
+    local model = ffi.string(inkview.GetDeviceModel())
+    if model == "PB627" or model == "PB631" or model == "PocketBook 631" then
+        return true
+    end
+    return false
+end
+
 local ext_path = "/mnt/ext1/system/config/extensions.cfg"
 local app_name = "koreader.app"
 
@@ -36,8 +51,28 @@ local PocketBook = Generic:new{
 
     -- all devices that have warmth lights use inkview api
     hasNaturalLightApi = yes,
+
+    should_restrict_JIT = isModelBroken,
 }
 
+function PocketBook:restrictJIT()
+    -- reservation enough mmap slots for mcode allocation
+    local reserved_slots = {}
+    for i = 1, 32 do
+        local len = 0x10000 + i*0x1000
+        local p = ffi.C.mmap(nil, len, 0x3, 0x22, -1, 0)
+        table.insert(reserved_slots, {p = p, len = len})
+    end
+    -- free the reservation immediately
+    for _, slot in ipairs(reserved_slots) do
+        ffi.C.munmap(slot.p, slot.len)
+    end
+    -- and allocate a large mcode segment, hopefully it will succeed.
+    -- 64KB ought to be enough for everyone with 10000 loop threshold
+    require("jit.opt").start("sizemcode=64","maxmcode=64", "hotloop=10000")
+    for _=1,20000 do end  -- Force allocation of one large segment
+end
+
 -- Make sure the C BB cannot be used on devices with a 24bpp fb
 function PocketBook:blacklistCBB()
     -- As well as on those than can't do HW inversion, as otherwise NightMode would be ineffective.
@@ -70,6 +105,10 @@ local function tryOpenBook()
 end
 
 function PocketBook:init()
+    if self.should_restrict_JIT then
+        self:restrictJIT()
+    end
+
     -- Blacklist the C BB before the first BB require...
     self:blacklistCBB()

Bear with me if the diff breaks the code, because it is very untested

[nhedgehog]

Thanks for your effort ... and here comes the but .... now my problem is that I don't have a working compiling environment to do the changes.


Edit:Sorry I'm a little slow today. Did the change manually in device.lua, will test it soon.

[nhedgehog]

I did a quick test with an epub and it really worked at the beginning. I was soo happy but at the end it just took a lot of more clicks, to crash Koreader. I'll do some more thorough tests till tomorrow and provide the logfile if it crashes again.

[nhedgehog]

I did a thourough test with a difficult epub (lots of pages and lots of chapters) and a very difficult pdf (hundreds of svg on one page). Both files are known to be difficult to handle.
Couldn't bring it to crash easily but after same page turning opening the menu finally did it! There is a pattern going through it:
1) It is allways the menu opening or changing, that provokes the crash. Even the Koreader inbuild fileopener crashes after some directory changes.
2) The menu handling crashes Koreader easier after reading some pages.
3) The behaviour seems not to be affected by the size or complexity of the epub or pdf.

[pazos]

Originally Posted by nhedgehog

I did a thourough test with a difficult epub (lots of pages and lots of chapters) and a very difficult pdf (hundreds of svg on one page). Both files are known to be difficult to handle.
Couldn't bring it to crash easily but after same page turning opening the menu finally did it! There is a pattern going through it:
1) It is allways the menu opening or changing, that provokes the crash. Even the Koreader inbuild fileopener crashes after some directory changes.
2) The menu handling crashes Koreader easier after reading some pages.
3) The behaviour seems not to be affected by the size or complexity of the epub or pdf.

Yup, the crash is still the same. But if you find it harder to trigger I would suggest a different way:

rename /mnt/ext1/applications/koreader as /mnt/ext1/applications/koreader.old
download last nightly from http://build.koreader.rocks/download/nightly/ and copy just the applications folder
edit /mnt/ext1/applications/koreader/reader.lua:

the first line should look like:

#!./luajit -joff

That should disable the JIT compiler all together, so it is expected to be sloooow (and thus better to try with a release build).

If you still manage to get memory corruption with the JIT compiler off there are probably other things involved. If you cannot then please compare performance (it is 10x worst or 100x worst?)

Don't get me wrong. I'm not sure what I'm doing here, just blindy testing. Anyways the intent here is not disabling the JIT, but testing that we're unable to trigger the segfault without the JIT enabled.

[nhedgehog]

Did as you proposed. With nightly build, your changes to:device.lua&

#!./luajit -joff

Koreader is slower (2-3times) in the menus, pageturning is fast and it felt like it took more time to crash it. File opening feels like 20 times slower.
Now that is strange: I enabled nightmode and everything is slowed down so much it feels like I'm waiting more than 2-3 minutes for any reaction after my input. After disabling Night mode everything goes soooo fast.

Edit:
Thinking about it I guess Koreader didn't even crash, just slowed down soo much (nightmode) that I thought it crashed.

[EastEriq]

Getting onboard, perhaps a couple of steps behind nhedgehog. The debug build you posted, freshly installed, a single medium-sized epub, very early crashed. The first run doesn't include a bt because I c'ed once or twice too much past SIGSEGV. Some of the other have redundant bt and where, before I realized they were equivalent.
Anything else which I could specifically do?

[EastEriq]

And this one inserting one by one the commands of nhedgehog in https://www.mobileread.com/forums/at...7&d=1599736061, i.e. starting koreader from gdb, instead of attaching gdb to the reader.lua process started earlier, just after opening the book.
Crash at the third or fourth page-turning tap at the center of the screen.

[pazos]

@EastEriq @nhedgehog: thanks for your help!

Just try to run the last nightly with ./luajit -joff as stated above and without any other change.

You don't need to run gdb or any other tool, just keep a look at logs and report segmentation faults (please remove old crash.log to avoid confusion )

Since this is painfully slow (specially for screen transformations like inversion or rotation) I would suggest to enable C blitter unless that makes the program crash (In developer options, see attachments)

Just try to read books and explore the UI/Menus. As @nhedgehog said the behaviour isn't affected by big or complex files. It just happens randomly when the GC hits in.

Also, if you don't mind, please lets move conversation to https://github.com/koreader/koreader/issues/6000 because it is easier to paste diffs there and keep track of reports. If that's not possible it is cool for me to stay here. Moderators can move this thread to dev's corner if they want

[EastEriq]

Ok, moving to issue 6000. For tonight, I'll just briefly test #!./luajit -joff in reader.lua in the debug build I have currently installed. More of that, in the following.

[mobman]

Originally Posted by EastEriq

which KOreader has chances on PB631?

This version works well enough for me:
https://github.com/koreader/koreader...018.10.07-beta

[EastEriq]

yeah, tried it, I find somehow more difficult to crash it, but alas it has no RTL support, very few gestures, doesn't see my system fonts, and misses probably two years of other bonus features. Which for me defeats the purpose, not worth the disk space it would takes on my reader, if I was stuck at that one.

[EastEriq]

Bottom line, the cause for https://github.com/koreader/koreader/issues/6000 was identified and IIUC on the way to be solved. This is what I (and others likewise) did. Thanks a lot ezdiy, pazos, NiLuJe, nhedgehog.