Version: 0.3.1 (using KDE KDE 3.3.1) Installed from: Compiled From Sources Compiler: gcc (GCC) 3.4.2 OS: Linux No matter what PDF I try to view using kpdf, it crashes shortly after rendering the first page. The stack trace is always the same. I'll attach a coredump plus the pdf causing it. (gdb) bt #0 0x41ee5c76 in TextPage::coalesce () from /opt/kde/lib/kde3/libkpdfpart.so #1 0x41e7c048 in QOutputDev::endPage () from /opt/kde/lib/kde3/libkpdfpart.so #2 0x41e7c3a8 in QOutputDevPixmap::endPage () from /opt/kde/lib/kde3/libkpdfpart.so #3 0x41e9c29e in Gfx::~Gfx () from /opt/kde/lib/kde3/libkpdfpart.so #4 0x41eca740 in Page::displaySlice () from /opt/kde/lib/kde3/libkpdfpart.so #5 0x41ecaa7c in Page::display () from /opt/kde/lib/kde3/libkpdfpart.so #6 0x41ec8deb in PDFDoc::displayPage () from /opt/kde/lib/kde3/libkpdfpart.so #7 0x41e862a5 in ThumbnailGenerator::run () from /opt/kde/lib/kde3/libkpdfpart.so #8 0x40b7f0c5 in QThreadInstance::start () from /usr/lib/qt/lib/libqt-mt.so.3 #9 0x4135073e in pthread_start_thread () from /lib/libpthread.so.0 #10 0x4156b08a in clone () from /lib/libc.so.6
Created attachment 8295 [details] PDF-file
Coredump too large for attaching. Get it here: http://www.osd.dk/tmp/core.kpdf.gz
That pdf works without problems here on KDE 3.3.1, strange, do you have any special setup?
Not at far as I know. Although I'm using gcc-3.4.2 on an AMD Opteron 240 under kernel 2.6.9 if that makes a difference (32-bit mode). Does it require any special dependencies? The PDF displays just fine in kghostview, but I guess that's just a frontend to gs. ... I just tested the PDF on a different box which didn't have a problem showing it. (AMD XP 2100+, kernel 2.4.27, GCC 3.3.4, KDE 3.3, KPDF 0.3.) What can I do to get more info on the crash? Maybe something can give a clue as to why it crashes on the other box.
KDE 3.3 and KDE 3.3.1 have a very different kpdf. Can you build and test with debugging enabled (./configure --enable-debug=full) on your opteron machine to see the lines that are really causing the crash? I have gcc 3.4.1 so i don't think 3.4.2 should be a problem.
Tried recompiling kdegraphics with --enable-debug=full as suggested. The crash disappears and I have no problems showing pdf-files. Recompiling without --enable-debug (using --disable-debug instead) and I'm right back where I started. KPDF crashes again.
Ouch, that sounds like a memory management related problem, as adding debug usually makes the memory allocated bigger and memory problems sometimes dissapear. If you could locate were exactly inside TextPage::coalesce it crashes it would be helpful, if you know some C add some printf here and there and try locating the line that crashes. Also can you try if xpdf works? It should not as the part of code that is crashing is common with xpdf And finally are you using some agressive compiling options like people that use gentoo usually use?
I can't reproduce this poblem, Debian/unstable, kde 3.3.1. the pdf works fine.
KPDF from HEAD running on Valgrind (with full debugging etc.) doesn't report any memory errors which might lead to crashes if optimisation is enabled.
xpdf seems to be working but I didn't compile that myself, which means it was probably compiled with gcc 3.3.4 and options -march i486 -mcpu i686. I used -march opteron with gcc 3.4.2 to build the kernel, kde and a bunch of support libraries. I've been trying to add printf()s all over the TextPage::coalesce() function and the QOutputDev::endpage() in kpdf. Sometimes it doesn't get to output anything, other times it runs through the entire function several times before segfaulting; depends on how I run kpdf (with gdb, valgrind or without any of them). Mostly it segfaults in the m_text->coalesce(gTrue) call around line 72 in QOutputDev.cpp (kdegraphics-3.3.1). I say this because I've added a printf() at the first line of the called function and I'm not seeing the output from that printf(). Could the cause be some kind of stack overflow? I built the kernel with 4k stacks instead of 8k. Maybe that what's causing the problem? Anyway, I'll try a 8k stack kernel now and see what happens.
No dice. It was a longshot anyway.
Would it be possible recompiling with -march i486 -mcpu i686? That would give us a better idea if the failure is only when using opteron or more general.
I compiled it with -march i686 and that solves it. So I guess there's something in the kpdf/xpdf code which breaks when compiled with -march opteron. All of KDE, Qt and support libraries have been compiled with -march opteron, and kpdf is the only app I've had problems with (yet, anyway).
There seems to be an error in xpdf in Opteron, Adriann de Groot "reports" it at http://216.239.57.104/search?q=cache:2xFAc0Gskk4J:news.gw.com/freebsd.amd64/589+xpdf+opteron+crash&hl=ca&ie=UTF-8 In that very same mail he says kpdf works but that was a older version of kpdf based on a different xpdf codebase.
i have similar issues with kpdf from the kpdf_experiments branch on x86_64 at work. when i'm in the office next with some spare time i'll see what i can do.
Just built and rebuilt kpdf on an amd64 on FreeBSD with gcc 3.4.2 with the following configurations: -g3 -no-inline -O3 -O3 -march=opteron The latter two produce identical executables; all three can view the PDF file from above without problems. This is with everything from BRANCH.
Since Kdegraphics 3.3.2 i'm also unable to open any pdf using kpdf. All pdf's i tried worked fine under xpdf. I'm using the Gentoo packages and gcc 3.4.3 with options: "-O2 -march=i686 -mtune=pentium4 -pipe -fomit-frame-pointer -fPIC -mmmx -msse -msse2 -m32" All other kdegraphics programs are working fine. KDE crash Handeler's backtrace gives: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 8236)] [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 8236)] [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 8236)] [New Thread 32769 (LWP 8244)] [New Thread 16386 (LWP 8245)] 0x4652db9b in waitpid () from /lib/libpthread.so.0 #0 0x4652db9b in waitpid () from /lib/libpthread.so.0 #1 0x4726c148 in ?? () from /usr/kde/3.3/lib/libkdecore.so.4 #2 0x00000000 in ?? () #3 0x4718ac9f in KCrash::defaultCrashHandler () from /usr/kde/3.3/lib/libkdecore.so.4 #4 0x0000001b in ?? () #5 0xb7c1aac0 in T1_fdb () from /usr/lib/libt1.so.5 #6 0x037f0c7f in ?? () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x0007fffc in ?? () #10 0x077f037f in ?? () #11 0xb7c05717 in T1_AASetChar () from /usr/lib/libt1.so.5 #12 0xb7d12136 in SplashT1Font::makeGlyph () from /usr/kde/3.3/lib/kde3/libkpdfpart.so #13 0x0000000b in ?? () #14 0x0000006e in ?? () #15 0x416f199a in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x00000398 in ?? () #19 0x00000389 in ?? () #20 0xb7d2500c in ?? () from /usr/kde/3.3/lib/kde3/libkpdfpart.so #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0x00000288 in ?? () #24 0xb7d0f203 in SplashFont::getGlyph () from /usr/kde/3.3/lib/kde3/libkpdfpart.so #25 0xb7ba5654 in ?? ()
Did kpdf from KDE 3.3.1 work on the very same machine and gcc optimizations?
Created attachment 8839 [details] post-3.3.2-kdegraphics.diff for xpdf bug kpdf still chrashed after this diff
Yes it worked with the very same optimizations and machine. I emerged kdegraphics with the patch above that was supposed to fix a xpdf bug but it didn't solved my problem emerge info output Portage 2.0.51-r8 (default-linux/x86/2004.2, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-ck1 i686) ================================================================= System uname: 2.6.10-ck1 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz Gentoo Base System version 1.6.8 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Nov 24 2004, 13:09:16)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.8.5-r2, 1.5, 1.6.3, 1.9.3, 1.4_p6, 1.7.9 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r2 virtual/os-headers: 2.4.22 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=i686 -mtune=pentium4 -pipe -fomit-frame-pointer -fPIC -mmmx -msse -msse2 -m32" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=i686 -mtune=pentium4 -pipe -fomit-frame-pointer -fPIC -mmmx -msse -msse2 -m32" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl alsa apache2 apci apm arts avi berkdb bitmap-fonts cdr crypt cups dba dvd encode fam flac foomaticdb fortran gd gdbm gentoo gif gpm gtk2 imagemagickimlib ipv6 java jikes jpeg kde kerberos libwww mad mikmod mmx motif mozilla mpeg nas ncurses nls oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline sdl slang spell sse sse2 ssl svga tcltk tcpd tetex tiff truetype usb x86 xml2 xmms xv zlib video_cards_radeon linguas_nl"
That diff does not solves a crash but a potential security problem.
Stijn, could you compile with debug enabled (see comment 5) and provide a better backtrace?
Could you both please compile the new kpdf from CVS HEAD? It has a few changes in the code so maybe it'll work.
K, I will give it a try this week
Hello, I'm also seeing this crash. Compiled using gcc 3.4.0 with the -march=pentium4 flag. FWIW, here's the bt that's produced: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 2710)] [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 2710)] [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 2710)] [New Thread 32769 (LWP 4578)] [New Thread 16386 (LWP 4579)] [KCrash handler] #4 0x4197d52a in TextPage::coalesce (this=0x83cc920) at TextOutputDev.cc:2046 #5 0x419c9617 in KPDFOutputDev::endPage (this=0x82a9f28) at gp_outputdev.cpp:115 #6 0x4192b79c in ~Gfx (this=0x83cc9a0) at Gfx.cc:494 #7 0x41959670 in Page::displaySlice (this=0x82e8898, out=0x82a9f28, hDPI=72, vDPI=72, rotate=135346440, crop=1, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, links=0x8231cf8, catalog=0x82ba868, abortCheckCbk=0x27, abortCheckCbkData=0x27) at Page.cc:452 #8 0x41959960 in Page::display (this=0x27, out=0x27, hDPI=0, vDPI=0, rotate=39, crop=39, links=0x27, catalog=0x27, abortCheckCbk=0x27, abortCheckCbkData=0x27) at Page.cc:329 #9 0x4195734a in PDFDoc::displayPage (this=0x8282a58, out=0x82a9f28, page=0, hDPI=72, vDPI=72, rotate=0, crop=1, doLinks=1, abortCheckCbk=0, abortCheckCbkData=0x0) at PDFDoc.cc:221 #10 0x419c6f6e in PDFPixmapGeneratorThread::run (this=0x82afcf0) at page.h:43 #11 0x40c6c88e in QThreadInstance::start (_arg=0x828b004) at kernel/qthread_unix.cpp:119 #12 0x41457cc4 in pthread_start_thread () from /lib/libpthread.so.0 #13 0x41692be7 in clone () from /lib/libc.so.6
recompiled without using -march=pentium4 flag and now it works no problem, no crashes. gcc bug?
What was the signal you received? SIGILL? SIGBUS?
The fun thing is that TextOutputDev.cc:2046 is intraLineSpace = maxIntraLineDelta * fontSize; How can it crash in a double multiplication?
SIGSEGV I'm thinking it has something to do with the -march flag and the threading. I was recently having a problem with winex where it would crash immediately on startup in set_thread_area. Removing the -march resolved this problem too.
*** Bug 102245 has been marked as a duplicate of this bug. ***
I'm the reporter of #102245. I can confirm that that removing the -march=pentium4 in g++ (GCC) 3.4.2 [FreeBSD] corrects the problem.
Can you still reproduce the problem with a more recent KPDF version?
Well, I haven't had any problems with kpdf for quite a while now, but I've also changed just about everything hardware and software wise. Seems like this can be closed. :)