IUS Community Project

Segfault with PDFlib

Asked by Marcel Lindenbergh

I just upgraded our CentOS 6.4 (x84) stock PHP 5.3.3 with the IUS repo to PHP 5.4.11 using the yum-plugin-replace.

Everything works fine except one class which uses PDFlib 8. Code using this class segfaults at the end of the PHP script. I've narrowed it down to the following test code to reproduce the segfault:

<?php

class PdfExt extends PDFLib {

    /** Just some public variable */
    public $someVar;
}

$pdf = new PdfExt();

//print_r($pdf);

The PdfExt class instance will cause a segfault when the script finishes (somewhere during internal PHP cleanup I suppose).
However, when the print_r() is uncommented the segfault magically disappears! It also disappears if the public $someVar is removed from the class.

This smells like a very serious bug. Any help is much appreciated.

Further info: the PDFlib functions properly, so all code inside the actual class is executed normally and the PDF output is perfectly fine. It all goes wrong during the cleanup by PHP is seems (garbage collection stage?) This wasn't an issue with the stock PHP 5.3.3, it appeared after upgrading to IUS PHP 5.4.11.

Thanks in advance.

Marcel

Question information

Language:
English Edit question
Status:
Solved
For:
IUS Community Project Edit question
Assignee:
No assignee Edit question
Solved by:
Marcel Lindenbergh
Solved:
Last query:
Last reply:
Revision history for this message
Marcel Lindenbergh (marcel-3) said : 		#1

Jusr ran Valgrind on the test script and here is it's output:

==3513== Memcheck, a memory error detector
==3513== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==3513== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==3513== Command: php pdflib_core_dump.php
==3513==
==3513== Invalid read of size 8
==3513== at 0x5EC697: zend_hash_destroy (in /usr/bin/php)
==3513== by 0xED6D749: ??? (in /usr/lib64/php/modules/libpdf_php.so)
==3513== by 0x606F6B: zend_objects_store_del_ref_by_handle_ex (in /usr/bin/php)
==3513== by 0x606F92: zend_objects_store_del_ref (in /usr/bin/php)
==3513== by 0x5D1D29: _zval_ptr_dtor (in /usr/bin/php)
==3513== by 0x5EC364: ??? (in /usr/bin/php)
==3513== by 0x5EC468: zend_hash_reverse_apply (in /usr/bin/php)
==3513== by 0x5D31D4: ??? (in /usr/bin/php)
==3513== by 0x5DFE93: ??? (in /usr/bin/php)
==3513== by 0x5825E4: php_request_shutdown (in /usr/bin/php)
==3513== by 0x688FEE: ??? (in /usr/bin/php)
==3513== by 0x68A3B7: ??? (in /usr/bin/php)
==3513== Address 0x20 is not stack'd, malloc'd or (recently) free'd
==3513==
==3513==
==3513== Process terminating with default action of signal 11 (SIGSEGV)
==3513== Access not within mapped region at address 0x20
==3513== at 0x5EC697: zend_hash_destroy (in /usr/bin/php)
==3513== by 0xED6D749: ??? (in /usr/lib64/php/modules/libpdf_php.so)
==3513== by 0x606F6B: zend_objects_store_del_ref_by_handle_ex (in /usr/bin/php)
==3513== by 0x606F92: zend_objects_store_del_ref (in /usr/bin/php)
==3513== by 0x5D1D29: _zval_ptr_dtor (in /usr/bin/php)
==3513== by 0x5EC364: ??? (in /usr/bin/php)
==3513== by 0x5EC468: zend_hash_reverse_apply (in /usr/bin/php)
==3513== by 0x5D31D4: ??? (in /usr/bin/php)
==3513== by 0x5DFE93: ??? (in /usr/bin/php)
==3513== by 0x5825E4: php_request_shutdown (in /usr/bin/php)
==3513== by 0x688FEE: ??? (in /usr/bin/php)
==3513== by 0x68A3B7: ??? (in /usr/bin/php)
==3513== If you believe this happened as a result of a stack
==3513== overflow in your program's main thread (unlikely but
==3513== possible), you can try to increase the size of the
==3513== main thread stack using the --main-stacksize= flag.
==3513== The main thread stack size used in this run was 10485760.
==3513==
==3513== HEAP SUMMARY:
==3513== in use at exit: 4,107,951 bytes in 20,625 blocks
==3513== total heap usage: 22,218 allocs, 1,593 frees, 4,322,771 bytes allocated
==3513==
==3513== LEAK SUMMARY:
==3513== definitely lost: 0 bytes in 0 blocks
==3513== indirectly lost: 0 bytes in 0 blocks
==3513== possibly lost: 0 bytes in 0 blocks
==3513== still reachable: 4,107,951 bytes in 20,625 blocks
==3513== suppressed: 0 bytes in 0 blocks
==3513== Rerun with --leak-check=full to see details of leaked memory
==3513==
==3513== For counts of detected and suppressed errors, rerun with: -v
==3513== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 142 from 9)
Segmentation fault (core dumped)

Revision history for this message
Jeffrey Ness (jeffrey-ness) said : 		#2

Hello Marcel,

Thank you for taking the time to post this issue.

First were you using this same code with stock PHP, and did it cause the same segfault?

Next, It sounds like this could be a issue with upstream PHP, and the bug should probably be opened with them:

   https://bugs.php.net/

IUS merely packages upstream software, so usually we are no help with bug traces like above.

What I'm going to do is try to reproduce this error on some internal servers, and on a standalone compile
of PHP.

Jeffrey-

Revision history for this message
Marcel Lindenbergh (marcel-3) said : 		#3

Hello Jeffrey,

Many thanks for your prompt answer.

There were no segfaults with the same code on stock PHP 5.3.3. It appeared after upgrading to PHP 5.4.11.

I just tried the same on a clean CentOS 6.4 box with no previous PHP installed and it happens there as well.

If you experience the same issue I will open up a ticket with PHP for this bug.

Marcel

Revision history for this message
Marcel Lindenbergh (marcel-3) said : 		#4

Also just tried to same example code on PHP 5.4.13 (installed via MacPorts) on Mac OS X 10.8.3 and it segfaults there too.

So definitely a PHP issue which has nothing to do with IUS, thank God. ;)

Marcel

Revision history for this message
Marcel Lindenbergh (marcel-3) said : 		#5

FYI: I filled a bug report for this with PHP:

https://bugs.php.net/bug.php?id=64455

Marcel

Revision history for this message
Jeffrey Ness (jeffrey-ness) said : 		#6

Marcel,

Thank you so very much for assisting, I'm glad to hear it wasn't an issue with the packaging.

This will be a great resource page for anyone using IUS packages, and non IUS PHP 5.4 to track the issue
back to the upstream bug.

Jeffrey-

Revision history for this message
Jeffrey Ness (jeffrey-ness) said : 		#7

Marcel,

Thank you so very much for assisting, I'm glad to hear it wasn't an issue with the packaging.

This will be a great resource page for anyone using IUS packages, and non IUS PHP 5.4 to track the issue
back to the upstream bug.

Jeffrey-