| Summary: | pdftops crashes on solaris with memory corruption | ||
|---|---|---|---|
| Product: | poppler | Reporter: | William Bader <williambader> |
| Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | williambader |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
William Bader
2011-05-13 21:23:06 UTC
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.