Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#64 pdf device segfaults on example 24

closed-fixed
Werner Smekal
None
5
2010-07-27
2009-11-17
Alan W. Irwin
No

On Debian stable, with libharu-2.1.0 built from source, example 24 generates a segfault like this:

examples/c/x24c -dev pdf -o test.pdf
ERROR: error_no=1050, detail_no=0
Segmentation fault

Here is the corresponding valgrind messages:

software@raven> valgrind examples/c/x24c -dev pdf -o test.pdf
==15027== Memcheck, a memory error detector.
==15027== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==15027== Using LibVEX rev 1854, a library for dynamic binary translation.
==15027== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==15027== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.
==15027== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==15027== For more details, rerun with: -v
==15027==
ERROR: error_no=1050, detail_no=0
==15027== Invalid read of size 8
==15027== at 0x6D986A6: HPDF_Free (in /home/software/libharu/install/lib/libhpdf-2.1.0.so)
==15027== by 0x6B7C3E5: plD_init_pdf (pdf.c:290)
==15027== by 0x4E69932: c_plptex (plsym.c:643)
==15027== by 0x400E59: main (x24c.c:149)
==15027== Address 0x3e303278303c2308 is not stack'd, malloc'd or (recently) free'd
==15027==
==15027== Process terminating with default action of signal 11 (SIGSEGV)
==15027== General Protection Fault
==15027== at 0x6D986A6: HPDF_Free (in /home/software/libharu/install/lib/libhpdf-2.1.0.so)
==15027== by 0x6B7C3E5: plD_init_pdf (pdf.c:290)
==15027== by 0x4E69932: c_plptex (plsym.c:643)
==15027== by 0x400E59: main (x24c.c:149)
==15027==
==15027== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 11 from 2)
==15027== malloc/free: in use at exit: 103,277 bytes in 437 blocks.
==15027== malloc/free: 517 allocs, 80 frees, 125,973 bytes allocated.
==15027== For counts of detected errors, rerun with: -v
==15027== searching for pointers to 437 not-freed blocks.
==15027== checked 321,784 bytes.
==15027==
==15027== LEAK SUMMARY:
==15027== definitely lost: 100 bytes in 1 blocks.
==15027== possibly lost: 0 bytes in 0 blocks.
==15027== still reachable: 103,177 bytes in 436 blocks.
==15027== suppressed: 0 bytes in 0 blocks.
==15027== Rerun with --leak-check=full to see details of leaked memory.
Segmentation fault

So it appears there is some issue with the HPDF_Free call for the 24th example that does not appear for any other example. (Note that if I adjust test_c.sh to drop example 24 "make test_c_pdf" completes without any obvious errors.)

Discussion

  • Alan W. Irwin
    Alan W. Irwin
    2009-11-17

    • status: open --> open-accepted
     
  • Alan W. Irwin
    Alan W. Irwin
    2010-07-27

    • status: open-accepted --> closed-fixed
     
  • Alan W. Irwin
    Alan W. Irwin
    2010-07-27

    One of the fonts used in example 24 has a size of 403 while in upstream libharu-2.1.0 we have

    include/hpdf_consts.h:#define HPDF_MAX_FONTSIZE 300

    Changing that to 600 (as in PLplot''s fixup area for libharu at cmake/external/libharu/include/hpdf_consts.h) solved the issue. Therefore, I am closing this although the bug fix still has to propagate to upstream libharu.