which KOreader has chances on PB631?

[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

 {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

[pazos]

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

 {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

[EastEriq]

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}

[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?

[pazos]

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

[ezdiy]

Originally Posted by EastEriq

Motivated by this post
If I log in with ssh, I for example see with top that the process

 {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:

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:

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

[EastEriq]

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

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

[pazos]

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

[nhedgehog]

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!

[EastEriq]

So far I only managed to install yesterday's build, which still just crashes. I understood (correct me if I'm wrong) that in order to provide useful information for the developers, I should generate a gdb trace from a debug version, instead of just submitting uninformative crash.logs. This means getting the build chain to work, and I haven't yet gone round to it. Will try when I have a bit of time.

[pazos]

Originally Posted by EastEriq

So far I only managed to install yesterday's build, which still just crashes. I understood (correct me if I'm wrong) that in order to provide useful information for the developers, I should generate a gdb trace from a debug version, instead of just submitting uninformative crash.logs. This means getting the build chain to work, and I haven't yet gone round to it. Will try when I have a bit of time.

Indeed, a debug version is required.

You can build one with

./kodev release --debug pocketbook

but requires a working toolchain from https://github.com/koreader/koxtoolchain.

Here's a debug version to avoid all that: https://www.dropbox.com/s/e30fg6f5ll...08-22.zip?dl=0.

[EastEriq]

Originally Posted by pazos

Here's a debug version to avoid all that: https://www.dropbox.com/s/e30fg6f5ll...08-22.zip?dl=0.

Thanks a lot, got it. Will try to have a go on it during the next days.

[nhedgehog]

@pazos: Thanks for the debug version, that spared some time.

Did it with gdb, took some time since I'm on Windows. Crash was logged the last from line 664 (trying to open a menu in Koreader, previous page turning was working without problems).

[pazos]

Originally Posted by nhedgehog

@pazos: Thanks for the debug version, that spared some time.

Did it with gdb, took some time since I'm on Windows. Crash was logged the last from line 664 (trying to open a menu in Koreader, previous page turning was working without problems).

Thank you!

Could you run it again until it crash and type

where

or

bt

in gdb?