View Single Post
Old 09-10-2020, 12:03 PM   #22
pazos
cosiņeiro
pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.
 
Posts: 1,406
Karma: 2451781
Join Date: Apr 2014
Device: BQ Cervantes 4
Quote:
Originally Posted by nhedgehog View Post
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:
Code:
#!./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.
pazos is offline   Reply With Quote