Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consistent crash on file load #4928

Closed
BrainDamage opened this issue Apr 16, 2019 · 6 comments · Fixed by #4931
Closed

consistent crash on file load #4928

BrainDamage opened this issue Apr 16, 2019 · 6 comments · Fixed by #4931
Labels

Comments

@BrainDamage
Copy link

  • KOReader version: v2019.04-14-g58d88b1
  • Device: Kobo Aura H2O2

Issue

consistent crash on file load ( the file is possibly corrupted )

crash.log (if applicable)

crash.log

@NiLuJe
Copy link
Member

NiLuJe commented Apr 16, 2019

Yep, it is.

@Frenzie
Copy link
Member

Frenzie commented Apr 16, 2019

Ah, this is the background to #4929.

I'm surprised MuPDF takes down the whole program here.

@Frenzie
Copy link
Member

Frenzie commented Apr 16, 2019

How did you manage to save the last opened document if it crashed, btw?

@BrainDamage
Copy link
Author

BrainDamage commented Apr 16, 2019

I simply pressed "open next file" at the end of a file, from a previous file in the same folder.
It launched the current one, saved settings ( I guess ) and then crashed

@Frenzie Frenzie added the bug label Apr 16, 2019
@Frenzie
Copy link
Member

Frenzie commented Apr 16, 2019

But that's not how it works. If I open a file and crash the program, the in memory settings crash with it. Something like the last opened document will be lost. Generally speaking I consider this a bug, not a feature, but those settings will only be saved in case of a clean exit. Never in between. Settings pertaining to a specific document will be saved when exiting the document. This too is a bug, for which I've prepared a solution but I haven't wanted to tackle migration.

If you purposefully edit the last file pointer to a broken file or break the file afterward, you'll see this on startup:

Screenshot_2019-04-16_17-27-55

On closer inspection of your log, the program does not actually crash. It seems to quit when it should be showing you the file browser. Do you have any special settings?

INFO  quitting uimanager
04/16/19-16:18:44 INFO  no dialog left to show

@Frenzie
Copy link
Member

Frenzie commented Apr 16, 2019

Oh, never mind. There's a code path that leads to a proper exit, possibly to prevent memory corruption? That's what'll cause it to save the last opened file.

function ReaderUI:showReaderCoroutine(file, provider)
UIManager:show(InfoMessage:new{
text = T(_("Opening file '%1'."), file),
timeout = 0.0,
})
-- doShowReader might block for a long time, so force repaint here
UIManager:forceRePaint()
UIManager:nextTick(function()
logger.dbg("creating coroutine for showing reader")
local co = coroutine.create(function()
self:doShowReader(file, provider)
end)
local ok, err = coroutine.resume(co)
if err ~= nil or ok == false then
io.stderr:write('[!] doShowReader coroutine crashed:\n')
io.stderr:write(debug.traceback(co, err, 1))
UIManager:quit()
end
end)
end

It can be easily triggered by this CBZ test file. It's a random source code file renamed .png.

not-a-png.cbz.zip

I've never encountered this code path before, in the past five years. ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants