I am using gcc-3.4.6 on Solaris 10 on a sun4u sparc. ./pdftops output-pdftopsbug.pdf output-pdftopsbug.ps fails with a memory error. The test pdf file is temporarily at http://williambader.com/output-pdftopsbug.pdf The poppler in git on 13 May 11 gives the traceback #0 0xfec548d4 in realfree () from /lib/libc.so.1 #1 0xfec55104 in cleanfree () from /lib/libc.so.1 #2 0xfec5425c in _malloc_unlocked () from /lib/libc.so.1 #3 0xfec5414c in malloc () from /lib/libc.so.1 #4 0xff1b7734 in operator new () from /usr/local/lib/libstdc++.so.6 #5 0x0020760c in GfxState::copy (this=0x2d6788) at GfxState.h:1298 #6 0x001743cc in GfxState::save (this=0x2d6788) at GfxState.cc:5844 #7 0x001420f4 in Gfx::saveState (this=0x2cc2c8) at Gfx.cc:4974 #8 0x00129814 in Gfx::opSave (this=0x2cc2c8, args=0xffbfd3a0, numArgs=0) at Gfx.cc:899 #9 0x0012945c in Gfx::execOp (this=0x2cc2c8, cmd=0xffbfd5b0, args=0xffbfd3a0, numArgs=0) at Gfx.cc:851 #10 0x00128be0 in Gfx::go (this=0x2cc2c8, topLevel=true) at Gfx.cc:711 #11 0x001289b0 in Gfx::display (this=0x2cc2c8, obj=0xffbfd710, topLevel=true) at Gfx.cc:678 #12 0x0019cde4 in Page::displaySlice (this=0x2cb2d8, out=0x28ce70, hDPI=72, vDPI=72, rotate=0, useMediaBox=false, crop=true, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, printing=true, catalog=0x28df30, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at Page.cc:485 #13 0x0008b350 in PSOutputDev::checkPageSlice (this=0x28dc30, page=0x2cb2d8, rotateA=0, useMediaBox=false, crop=true, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, printing=true, catalog=0x28df30, abortCheckCbk=0, abortCheckCbkData=0x0) at PSOutputDev.cc:3001 #14 0x0019ccc4 in Page::displaySlice (this=0x2cb2d8, out=0x28dc30, hDPI=72, vDPI=72, rotate=0, useMediaBox=false, crop=true, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, printing=true, catalog=0x28df30, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at Page.cc:469 #15 0x0019c89c in Page::display (this=0x2cb2d8, out=0x28dc30, hDPI=72, vDPI=72, rotate=0, useMediaBox=false, crop=true, printing=true, catalog=0x28df30, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at Page.cc:412 #16 0x00065ec8 in PDFDoc::displayPage (this=0x291978, out=0x28dc30, page=3, hDPI=72, vDPI=72, rotate=0, useMediaBox=false, crop=true, printing=true, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at PDFDoc.cc:433 #17 0x00065fa0 in PDFDoc::displayPages (this=0x291978, out=0x28dc30, firstPage=1, lastPage=4, hDPI=72, vDPI=72, rotate=0, useMediaBox=false, crop=true, printing=true, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at PDFDoc.cc:450 #18 0x0005afe0 in main (argc=3, argv=0xffbfde4c) at pdftops.cc:384 pdftops in poppler-0.17.0 gives #0 0xfec548d4 in realfree () from /lib/libc.so.1 #1 0xfec55104 in cleanfree () from /lib/libc.so.1 #2 0xfec5425c in _malloc_unlocked () from /lib/libc.so.1 #3 0xfec5414c in malloc () from /lib/libc.so.1 #4 0xff1b7734 in operator new () from /usr/local/lib/libstdc++.so.6 #5 0x000eb438 in GfxState::save (this=0x1fa5e0) at GfxState.h:1298 #6 0x000c3918 in Gfx::saveState (this=0x1f0120) at Gfx.cc:4974 #7 0x000bba0c in Gfx::execOp (this=0x1f0120, cmd=0xffbfd890, args=0x0, numArgs=0) at Gfx.cc:851 #8 0x000c4858 in Gfx::go (this=0x1f0120, topLevel=true) at Gfx.cc:711 #9 0x000c4c90 in Gfx::display (this=0x1f0120, obj=0xffbfd9d8, topLevel=true) at Gfx.cc:678 #10 0x00107330 in Page::displaySlice (this=0x1ef130, out=0x1b0cc8, hDPI=72, vDPI=72, rotate=0, useMediaBox=false, crop=false, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, printing=false, catalog=0x1b1d88, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at Page.cc:486 #11 0x00063734 in PSOutputDev::checkPageSlice (this=0x1b1a88, page=0x1ef130, rotateA=0, useMediaBox=false, crop=true, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, printing=true, catalog=0x1b1d88, abortCheckCbk=0, abortCheckCbkData=0x0) at PSOutputDev.cc:2999 #12 0x001071b0 in Page::displaySlice (this=0x1ef130, out=0x1b1a88, hDPI=72, vDPI=72, rotate=0, useMediaBox=false, crop=false, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, printing=false, catalog=0x1b1d88, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at Page.cc:470 #13 0x001073d0 in Page::display (this=0x1ef130, out=0x1b1a88, hDPI=72, vDPI=72, rotate=0, useMediaBox=false, crop=false, printing=false, catalog=0x0, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at Page.cc:412 #14 0x0004ed58 in PDFDoc::displayPages (this=0x1b57d0, out=0x1b1a88, firstPage=3, lastPage=4, hDPI=72, vDPI=72, rotate=0, useMediaBox=false, crop=false, printing=false, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at PDFDoc.cc:450 #15 0x00046a1c in main (argc=3, argv=0xffbfde84) at pdftops.cc:384 The same files produces no warnings when run on Linux with pdftops under valgrind. I did all of these tests with a static build and with -g (to get line numbers in the traceback) and -O0 (to reduce the chances that it is a gcc bug). The default dynamic link version runs the same as the static version but it is harder to debug. I have a number of test files, and the Solaris pdftops works on everything but this file.
gcc-3.4.6 ? really? If it crashes in a new i'd blame anyone but poppler about the crash.
gcc-3.4.6 is still the most recent build on the Solaris freeware site http://www.sunfreeware.com/ I've built gcc-4.6.0 on the Solaris system, and I compile my C programs with it, but poppler is in C++. gcc-4 and gcc-3 have a compatible calling interface for C, but I think that they are not compatible for C++. Sun freeware has versions of the system libraries that are all built with gcc-3.4.6 and compatible with each other. In order to build poppler with gcc-4.6.0, I would have to find all of the C++ system libraries that poppler uses and rebuild them from source with gcc-4.6.0. If it is only libstdc++, I could try that. At least so far, I haven't found any problems with anything from the Solaris freeware site. Whoever built it knew what they were doing and selected good configurations options. I suspect that the problem is in poppler because it seems to happen with the same object in two different versions of poppler. Also, the traceback in the git version show a call to GfxState::copy (stack entry #5 in the first traceback) which is not present in the 0.17.0 traceback. I suspect that there is something wrong in poppler, and changes between 0.17.0 and the git version were an attempt to fix it. The memory allocation in the Solaris runtimes might be more sensitive to writes outside allocated areas or to using memory after it has been freed.
To be fair i trust valgrind more than a 5 year compiler in a somewhat obscure architecure, also as far as i remember we used to have some problems with older gcc miscompiling poppler code so you might as well be hitting that. Of course i'm not saying that we are bug free (as you know very well know :D), but on the other hand given than valgrind is happy, it is crashing on a new (why new would ever crash?) and we don't have such machine available i think it's safe to say you are on your own with this problem.
"new" can crash if the memory allocation data structures are corrupted, for example, by writing to a block after freeing it or by writing past the end of a block into the data structures for the next block. The allocation data structure in the list of free blocks usually has a pointer to the next block. Before tools like valgrind, crashes on "new" or "malloc" were hard to debug because the bad write that caused the corruption could be far away from where the crash happened. I did run most of my test pdfs through pdftops under Linux with valgrind, and with the patch that I submitted yesterday, I did not have any errors. valgrind does not catch all bad accesses. It knows what is allocated, but it does not know what is actually used. For example, if the compiler or the run-times allocated padding, valgrind will usually not complain if a program writes into the padding. If you have a few variables on the stack, I think that it also won't mind if you write past the end of one variable into the next variable as long as you don't write past the end of the stack. With C, I sometimes use a bounds checking version of gcc http://williambader.com/bounds/example.html but it does not work on C++. Anyway, thanks for the advice. I guess the next step is rebuilding the necessary libraries on Solaris. I'll need a while before I can get around to it because my sun is about as fast as a 400 MHz Pentium.
Yesterday's git version runs OK on my Solaris system. $ ./pdftops output-pdftopsbug.pdf x.ps $ tail -3 x.ps %%+ font CairoFont-5-0 %%+ font CairoFont-0-0 %%EOF $ ./pdftops -v pdftops version 0.17.1 Copyright 2005-2011 The Poppler Developers - http://poppler.freedesktop.org Copyright 1996-2004 Glyph & Cog, LLC $ $ /usr/local/bin/pdftops output-pdftopsbug.pdf x.ps Bus Error (core dumped) $ /usr/local/bin/pdftops -v pdftops version 0.17.0 Copyright 2005-2011 The Poppler Developers - http://poppler.freedesktop.org Copyright 1996-2004 Glyph & Cog, LLC $
so fixed?
> so fixed? Yes, the recent git version that I tested is ok, and I compiled with full optimization. The 0.17.0 version crashed, with and without optimization. It seems that the problem was something in poppler and is fixed now. The 0.17.1 (0.18 Beta 1) NEWS says * Rework the way form fields tree is built * Cleanup unused parameters/variables Maybe one or the other fixed whatever was causing the problem with the older c++ library on Solaris. William
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.