Segmentation fault crash while opening book #11680
Comments
|
Can reproduce, will investigate. segmentation faults (aka segfaults) is just some generic crash that happens because of coding errors/oversights, there were many reports, but all for different reasons, so none is "similar" to any other :) .... and that backtrace doesn't seem to end, looks like an infinite loop and a huge stack overflow. |
|
And indeed there was a coding error: --- a/crengine/src/lvrend.cpp
+++ b/crengine/src/lvrend.cpp
@@ -11557,26 +11557,28 @@ void getRenderedWidths(ldomNode * node, int &maxWidth, int &minWidth, int direct
if ( is_img || node->isBoxingInlineBox() ) {
if (!nowrap) {
// Get done with previous word
if (curWordWidth > minWidth)
minWidth = curWordWidth;
curWordWidth = 0;
}
collapseNextSpace = false;
lastSpaceWidth = 0;
int _maxw = 0;
int _minw = 0;
- if ( is_img && img_width > 0) {
- // Inline img with a fixed width
- _maxw = img_width;
- _minw = img_width;
+ if ( is_img ) {
+ if ( img_width > 0) {
+ // Inline img with a fixed width
+ _maxw = img_width;
+ _minw = img_width;
+ }
}
else {
// Get the rendered width of the inlineBox
getRenderedWidths(node, _maxw, _minw, direction, false, rendFlags);
}fixes the infinite loop and segfault. But then, we get lots of when rendering and turning pages: ie. at the beginning of the book, there are pages that even Calibre struggles to render correctly: Haven't yet investigated why these images end up being detected as having 0-width. How are these pages supposed to look when not scrambled, in other reading software? Do you see images / lines ? |
Unlikely . :-) Segmentation fault just means some memory is being accessed or written that isn't accessible. So similar in that extremely generic sense only. |
The book is not very nicely formatted (as you can probably tell); it appears to be some conversion from PDF. It renders somewhat differently on all readers. The best job does AlReader. The page you showed above does not have any images. This is how it looks like on some other reader software (the original file looks the same): ReadEra: Reasily: AlReader: Here is an example of a page that does have an actual image on the original (AlReader): |
Understood. I said "presumably" and just mentioned it in case it could help :-) |
|
Ok, the image ends up being 0-width because it's explicitely requested by the publisher CSS:
If you manage to stick in (or fix the CSS in the epub to set this width to other than 0): You'll get - and you can go on reading: Non-blocking segfault then :) No urgency making a PR, I'll keep that for my next batch of fixes. |
|
Tip to be able to load the book and add/edit the book style tweak:
|
|
Great, thank you! I already edited the stylesheet in the original epub and it loaded fine. 💯 |
|
Just came across another segfault today that fixes itself when I disable embedded style defaults before opening the book. I should mention that I was reading several pages of this book back in June 2023 without incident. So something must have broken in an update since. Here is the stylesheet.css of the book (sorry for the crappy formatting). Let me know if you can see what might be the culprit or if you need a scrambled copy of the book. Thank you. html{color:#000;background:#FFF;}body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,code,form,fieldset,legend,input,textarea,p,blockquote,th,td{margin:0;padding:0;}table{border-collapse:collapse;border-spacing:0;}fieldset,img{border:0;}address,caption,cite,code,dfn,em,strong,th,var{font-style:normal;font-weight:normal;}li{list-style:none;}caption,th{text-align:left;}h1,h2,h3,h4,h5,h6{font-size:100%;font-weight:normal;}q:before,q:after{content:'';}abbr,acronym{border:0;font-variant:normal;}sup{vertical-align:text-top;}sub{vertical-align:text-bottom;}input,textarea,select{font-family:inherit;font-size:inherit;font-weight:inherit;}input,textarea,select{*font-size:100%;}legend{color:#000;}
body{font:13px/1.231 arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}select,input,button,textarea{font:99% arial,helvetica,clean,sans-serif;}table{font-size:inherit;font:100%;}pre,code,kbd,samp,tt{font-family:monospace;*font-size:108%;line-height:100%;}
h1{font-size:138.5%;}h2{font-size:123.1%;}h3{font-size:108%;}h1,h2,h3{margin:1em 0;}h1,h2,h3,h4,h5,h6,strong{font-weight:bold;}abbr,acronym{border-bottom:1px dotted #000;cursor:help;}em{font-style:italic;}blockquote,ul,ol,dl{margin:1em;}ol,ul,dl{margin-left:2em;}ol li{list-style:decimal outside;}ul li{list-style:disc outside;}dl dd{margin-left:1em;}th,td{border:1px solid #000;padding:.5em;}th{font-weight:bold;text-align:center;}caption{margin-bottom:.5em;text-align:center;}p,fieldset,table,pre{margin-bottom:1em;}input[type=text],input[type=password],textarea{width:12.25em;*width:11.9em;}
table, td, tr {
border: 0px;
margin: 0px;
padding: 0px;
} |
|
Can't see - the styles may be innofensive as long as they don't apply to any element :) |
|
I have no clue what it could be. Here is the scramble: |
|
Well, it doesn't crash for me - because it was the same cause as your other book above - and the same fix avoids it (removing my fix makes it crash). So, all good, no more work needed :) |
|
That's good news! Any idea why it didn't crash yet back in June? |
|
Not sure. I haven't change much about this bit of code in 2023/2024, but may be the bigger koreader/crengine#555 shuffled things around and new codepaths were taken that weren't last year. |
Issue
Scrambled Title - Scrambled author.epub.txt
When trying to open this file (scrambled for this report), the book first appears to load normally, but at around the halfway point of the progress bar, KOReader abruptly crashes.
Verbose crash.log:
Converting the file on Calibre from epub to epub and epub to mobi didn't help.
The document opens fine on several other Android e-reader software (including AlReader, CoolReader, Document Viewer, Reasily, ReadEra).
There was a presumably similar issue reported here: #1675.
Thank you for your help.
The text was updated successfully, but these errors were encountered: