Bug 119569 - kpdf uses 100% cpu when showing pdfs created with ps2pdf which have 3 or more pages
Summary: kpdf uses 100% cpu when showing pdfs created with ps2pdf which have 3 or more...
Status: RESOLVED FIXED
Alias: None
Product: kpdf
Classification: Applications
Component: general (show other bugs)
Version: 0.5
Platform: Slackware Linux
: NOR normal
Target Milestone: ---
Assignee: Albert Astals Cid
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-05 15:34 UTC by Stefan Gruber
Modified: 2006-01-06 00:47 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
The file which doesnt work (115.01 KB, application/octet-stream)
2006-01-05 16:59 UTC, Stefan Gruber
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gruber 2006-01-05 15:34:44 UTC
Version:           0.5 (using KDE KDE 3.5.0)
Installed from:    Slackware Packages
OS:                Linux

I printed a website[1] with the build in function of konqueror to a ps-file. Then I converted it with ps2pdf into pdf and opened it with kpdf. The pages are empty and when I close kpdf, there's still a process called kpdf and the cpu-load increases. Only a killall kpdf helps here. The vivaldi-Site is 4 pages long.
I tried that with smaller site which has only 2 pages as a ps-file and nothing happens here.
Then I tried with a 3 pages ps-file and there comes the same problem.
Opening the vivaldi-file with xpdf works, but there are error-messages in the konsole:"Error: Bad bounding box in Type 3 glyph".

[1]http://de.wikipedia.org/wiki/Vivaldi
Comment 1 Rex Dieter 2006-01-05 15:38:36 UTC
To help the devs, I'd suggest attaching a (small) problematic pdf here as a test-case.
Comment 2 Stefan Gruber 2006-01-05 16:59:51 UTC
Created attachment 14144 [details]
The file which doesnt work
Comment 3 Albert Astals Cid 2006-01-06 00:47:44 UTC
SVN commit 494666 by aacid:

Fix DCT decoding for broken files
BUGS: 119569


 M  +16 -10    DCTStream.cc  


--- branches/KDE/3.5/kdegraphics/kpdf/xpdf/xpdf/DCTStream.cc #494665:494666
@@ -14,19 +14,25 @@
 
 static boolean str_fill_input_buffer(j_decompress_ptr cinfo)
 {
+  int c;
   struct str_src_mgr * src = (struct str_src_mgr *)cinfo->src;
   if (src->index == 0) {
-    src->buffer = 0xFF;
+    c = 0xFF;
     src->index++;
   }
   else if (src->index == 1) {
-    src->buffer = 0xD8;
+    c = 0xD8;
     src->index++;
   }
-  else src->buffer = src->str->getChar();
-  src->pub.next_input_byte = &src->buffer;
-  src->pub.bytes_in_buffer = 1;
-  return TRUE;
+  else c = src->str->getChar();
+  if (c != EOF)
+  {
+    src->buffer = c;
+    src->pub.next_input_byte = &src->buffer;
+    src->pub.bytes_in_buffer = 1;
+    return TRUE;
+  }
+  else return FALSE;
 }
 
 static void str_skip_input_data(j_decompress_ptr cinfo, long num_bytes)
@@ -81,18 +87,17 @@
   // the start marker...
   bool startFound = false;
   int c = 0, c2 = 0;
-  int n = 0;
   while (!startFound)
   {
     if (!c)
     {
       c = str->getChar();
-      if (c != 0xFF) c = 0;
       if (c == -1)
       {
         error(-1, "Could not find start of jpeg data");
         exit(1);
       }
+      if (c != 0xFF) c = 0;
     }
     else
     {
@@ -104,7 +109,6 @@
       }
       else startFound = true;
     }
-    n++;
   }
 
   jpeg_read_header(&cinfo, TRUE);
@@ -119,7 +123,9 @@
 
   if (x == 0) {
     if (cinfo.output_scanline < cinfo.output_height)
-      jpeg_read_scanlines(&cinfo, row_buffer, 1);
+    {
+      if (!jpeg_read_scanlines(&cinfo, row_buffer, 1)) return EOF;
+    }
     else return EOF;
   }
   c = row_buffer[0][x];