Mobileread
which KOreader has chances on PB631?
#1  EastEriq 09-01-2020, 05:02 PM
Motivated by this post, I had a new go on KOreader. I tried both the "stable" version mentioned there and the most recent 2020.8.1 from https://github.com/koreader/koreader/releases.
I have to say that coming from "just" cr3, I'm impressed. For one, Koreader is the only one handling correctly mixed LTR-RTL text, which not even the stock pbreader does.
However neither of the two versions I have tried holds. I've found uncountable ways for crashing the program, by turning just a few pages, by entering the settings menus, by sketching some gesture on the touchscreen (not even knowing what their effect should be - never got that far in the settings).

Unless that is really a feature for reminding me that no single book deserves more than a cursive attention to a couple of its pages, and to stay away from the vane and addicting illusion of fine-tuning the configuration, has someone had better experiences than mine? Is KR demanding too much from the resources of PB631?

If I log in with ssh, I for example see with top that the process
Code
 {reader.lua} ./luajit ./reader.lua
is taking 407Mb, 87% of VSZ on a particular medium sized epub, though I have still 157Mb free. Too much for headroom?

ETA: seen this thread, but it's old
Reply 

#2  pazos 09-01-2020, 05:29 PM
Quote EastEriq
Motivated by this post, I had a new go on KOreader. I tried both the "stable" version mentioned there and the most recent 2020.8.1 from https://github.com/koreader/koreader/releases.
I have to say that coming from "just" cr3, I'm impressed. For one, Koreader is the only one handling correctly mixed LTR-RTL text, which not even the stock pbreader does.
However neither of the two versions I have tried holds. I've found uncountable ways for crashing the program, by turning just a few pages, by entering the settings menus, by sketching some gesture on the touchscreen (not even knowing what their effect should be - never got that far in the settings).

Unless that is really a feature for reminding me that no single book deserves more than a cursive attention to a couple of its pages, and to stay away from the vane and addicting illusion of fine-tuning the configuration, has someone had better experiences than mine? Is KR demanding too much from the resources of PB631?

If I log in with ssh, I for example see with top that the process
Code
 {reader.lua} ./luajit ./reader.lua
is taking 407Mb, 87% of VSZ on a particular medium sized epub, though I have still 157Mb free. Too much for headroom?

ETA: seen this thread, but it's old
We did very promising improvements the last days (and by we I mean ezdiy).

These changes affect all pocketbook devices and prevent some long-time wonky behaviour (like not repurposing the same instance when launched from PB library, that could explain the resources displayed on top)

Sadly, there's still one issue that doesn't happen on most devices but does(did?) happens on yours: https://github.com/koreader/koreader/issues/6000

Short answer: try tomorrow nightly (or wait for the next stable). If you hit a SIGSEGV::SEGV_MAPERR error then I'm afraid you'll need to wait until somebody figures out what happens. If you don't hit that error there's a chance of everything working (mostly) fine
Reply 

#3  EastEriq 09-01-2020, 06:07 PM
I'll try.

Now that you say, I went searching for /mnt/ext1/applications/koreader/crash.log. All my last 14 logs (since I swapped to 2020.8.1) end with a {SIGSEGV::SEGV_MAPERR}
Reply 

#4  EastEriq 09-02-2020, 02:09 PM
Tried the current nightly, crashed it very quickly four times with plain inexpressive "Segmentation fault" in crash.log.
How can I help in troubleshooting, without getting too deep into?
Reply 

#5  pazos 09-02-2020, 04:03 PM
Quote EastEriq
Tried the current nightly, crashed it very quickly four times with plain inexpressive "Segmentation fault" in crash.log.
How can I help in troubleshooting, without getting too deep into?
Unfortunate, but somehow expected (both errors are segmentation faults). I'm afraid this is exactly the kind of error that cannot be troubleshooted without getting too deep into.

In case you still want to help you need ezdiy's tools from the thread: https://www.mobileread.com/forums/sh...d.php?t=325185 and follow the instructions given in https://github.com/koreader/koreader/issues/6000
Reply 

#6  ezdiy 09-02-2020, 04:41 PM
Quote EastEriq
Motivated by this post
If I log in with ssh, I for example see with top that the process
Code
 {reader.lua} ./luajit ./reader.lua
is taking 407Mb, 87% of VSZ on a particular medium sized epub, though I have still 157Mb free. Too much for headroom?

[/URL], but it's old
PB631 (and all old models for that matter) is skirting the line with memory. I'll try to run with ulimit to try simulate your situation, but overall it doesn't look good - koreader is a massive memory hog.

Also, does the nightly crash straight away during startup (ie bug on my end), or after doing a bit of stuff for a while (= out of memory)?

As for how to debug, indeed there's useable gdb inside. ssh in, set up your environment by pasting the following:

Code
export LC_ALL="en_US.UTF-8"
export KOREADER_DIR=/mnt/ext1/applications/koreader
export LD_LIBRARY_PATH=${KOREADER_DIR}/libs
export KO_EXIT_CODE="/tmp/.koreader.exit"
export TESSDATA_PREFIX="data"
export STARDICT_DATA_DIR="data/dict"
cd $KOREADER_DIR
And then you can:

Code
$ gdb ./luajit
...
(gdb) handle SIGILL pass nostop noprint
(gdb) r reader.lua -d
Reply 

#7  EastEriq 09-03-2020, 03:45 PM
Quote ezdiy
Also, does the nightly crash straight away during startup (ie bug on my end), or after doing a bit of stuff for a while (= out of memory)?
Short answer, not right away, but after doing a couple of things, like turning a few pages, trying to open the settings, doing some funny gesture.
However (at least not with the nightly build, which I tried only cursively, but with 8.1), I've seen such crashes also when opening one-page .txt files, or smaller epubs, with smaller memory footprint.

I'll see in the following if manage to setup debugging as both of you instructed, and provide further feedback.
Reply 

#8  nhedgehog 09-09-2020, 11:38 AM
Any news here? The PB631 is one of the best readers Pocketbook produced and I would really love to use Koreader on this device.
Reply 

#9  pazos 09-09-2020, 11:53 AM
Quote nhedgehog
Any news here? The PB631 is one of the best readers Pocketbook produced and I would really love to use Koreader on this device.
Nope. The error just happens on a few devices (PB627/PB631, maybe others). It did happen on android on the past too.

It doesn't seem an OOM error to me, but I might be wrong. In android it happened too on the past and the solution was to restrict JIT engine on most parts of the code and just allocate a "big" chunk of memory (64K) for mcode at init.

NiLuJe suggested than the error on Pocketbook might be different and caused by ffi.load or relatives trying to load dependencies for inkview shared library and clashing with our own libraries.

We need a gdb backtrace or a coredump.

FWIW KOReader should run on a machine with 128MB of RAM for epubs without too much trouble, but the bare minimum for PDF's is 256MB.
Reply 

#10  nhedgehog 09-09-2020, 12:34 PM
Don't think it is the size of RAM, PB631 has 512MB RAM, my PB626 has only 256 MB RAM and is not experiencing those problems. I'll wait one day for EastEriq in case he has allready done the gdb backtrace, if not, I'll try my luck.
Thanks for the quick response, I really appreciate your commitment here!
Reply 

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