Bug 328182 - Okular hangs when opening cbz archive containing xml file
Summary: Okular hangs when opening cbz archive containing xml file
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: Comicbook backend (show other bugs)
Version: 0.17.2
Platform: Kubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-28 16:36 UTC by sasha
Modified: 2013-11-30 21:44 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.11.5
Sentry Crash Report:


Attachments
Okular hangs when trying to open the attached file (895.72 KB, application/x-cbz)
2013-11-28 16:36 UTC, sasha
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sasha 2013-11-28 16:36:58 UTC
Created attachment 83809 [details]
Okular hangs when trying to open the attached file

When trying to open CBZ comic book archive okular hangs if the archive includes XML file. Contents of XML file are irrelevant as long as the file begins with "<?xml version="1.0"?>". This impacts ComicRack tagged CBZ files as they include ComicInfo.xml file). 

This is the end of "strace -f" output in the console. Okular never fully loads, does not display anything at all and it does not generate any more output.
------------------------------------
lseek(11, 917116, SEEK_SET)             = 917116
lseek(11, 917194, SEEK_SET)             = 917194
lseek(11, 64, SEEK_SET)                 = 64
read(11, "\354}\7TS\333\266\366\16U\245\211(H\217\240r\224\336\233\200H\23\21P\221&M\f!@\32"..., 16384) = 16384
lseek(11, 64, SEEK_SET)                 = 64
read(11, "\354}\7TS\333\266\366\16U\245\211(H\217\240r\224\336\233\200H\23\21P\221&M\f!@\32"..., 16384) = 16384
read(11, "PJ\320Y.z\370\362,'\35X\n\216\355\330\352\245\35k\345\\\324I\275\26\23!\213\241\312:"..., 16384) = 16384
lseek(11, 917018, SEEK_SET)             = 917018
read(11, "<?xml version=\"1.0\"?>\nPK\1\2\36\3\24\0\0\0"..., 16384) = 198
read(11, "", 16186)                     = 0
lseek(11, 917018, SEEK_SET)             = 917018
read(11, "<?xml version=\"1.0\"?>\nPK\1\2\36\3\24\0\0\0"..., 16384) = 198
read(11, "", 16186)                     = 0
lseek(11, 917018, SEEK_SET)             = 917018
lseek(11, 917040, SEEK_SET)             = 917040
------------------------------------
Comment 1 Albert Astals Cid 2013-11-30 18:41:01 UTC
It's actually a kdelibs bug https://git.reviewboard.kde.org/r/114226/
Comment 2 Albert Astals Cid 2013-11-30 21:44:42 UTC
Git commit 64a7238c3c082b174e47c3896d6eb0f5c52ab461 by Albert Astals Cid.
Committed on 30/11/2013 at 21:33.
Pushed by aacid into branch 'KDE/4.11'.

Make KLimitedIODevice::bytesAvailable return the numbers of bytesAvaliable to read

At the moment KLimitedIODevice::bytesAvailable is returning at least the size of the file, so QIODevice::atEnd never returns true because it thinks there are more bytes to read. This makes that if you feed an "invalid" svg like "<?xml version="1.0"?>" to the QImageReader it infinite loops believing there will be more stuff to read but then read() always returns 0 but then bytesAvailable says there are more and it stays there forever.
FIXED-IN: 4.11.5
REVIEW: 114226

M  +1    -1    kdecore/io/klimitediodevice.cpp

http://commits.kde.org/kdelibs/64a7238c3c082b174e47c3896d6eb0f5c52ab461