ID: 39508 Updated by: [EMAIL PROTECTED] Reported By: phpbug at macfreek dot nl -Status: Open +Status: Assigned -Bug Type: Reproducible crash +Bug Type: GD related Operating System: Mac OS 10.4.8 (Darwin 8.8.0) PHP Version: 5.2.0 -Assigned To: +Assigned To: pajoye
Previous Comments: ------------------------------------------------------------------------ [2006-11-14 08:59:43] phpbug at macfreek dot nl Here is my full config, listing the output of php -v, gd_info(), phpinfo(), port installed gd2, pecl list-all: http://www.macfreek.nl/temp/gd-crasher-php-config.txt ------------------------------------------------------------------------ [2006-11-14 08:53:56] phpbug at macfreek dot nl Description: ------------ I got a nasty, but reproducible, crasher. I have a moderately long (~200 lines, no includes) piece of code that works fine on my Intel Mac with PHP 5.1.6, but crashes on my G5 Mac with PHP 5.2.0 The crashing line is: print $brush; with $brush a resurce object created with imagecreatetruecolor() (and not destroyed with imagedestroy() yet). The crash is a ~3 second pauze followed by either by a bus error or a segmentation fault. Reproduce code: --------------- My code is available fr now at http://www.macfreek.nl/temp/gd-crasher.phps However, this bug is notoriously hard to isolate. For one thing, the end of the file contains an unused function with nothing but bogus statements ($abc = 'xxxxx';). If I removed this function, the code no longer crashes. I _assume_ that there is buffer overflow somewhere, resulting in random memory being executed. At least that may explain why the removal of an unused function alters the behavior. This may also explain why it runs fine on the Intel, but that may be also because the different PHP version. The most suspect functions I use are: imagecreatetruecolor() -- creates a Resource imagesetbrush() -- uses a resource internally, has some comments on imagedestroy(). So far I removed other suspect code (e.g. imagettfbbox(), imagettftext() and all usage of external files) and trimmed the code down from 500 to 200 lines. However, I have a hard time to narrow it even further. Since I suspect that it is hard to reproduce on other machines, please advise how to proceed. Should I compile 5-CVS, use --enable-debug? (If so, please give a pointers, I usually use a package manager for installation and this is the first time I use gdb). Expected result: ---------------- Either a Fatal error blaming my buggy code, or a normal result, like I see on the Intel with PHP 5.1.6. Actual result: -------------- (gdb) run gd-crasher.php Starting program: /opt/local/bin/php gd-crasher.php Reading symbols for shared libraries ...++++++..................................................................++++++...+++++ done Reading symbols for shared libraries .. done Creating image Drawing calender bar -> Brushes = array( ) Drawing clock -> Brushes = array( ) -> Brushes = array( Resource id #5, ) -> Brushes = array( Resource id #5, ) -> Brushes = array( Resource id #5, Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0004000c 0x0044dbec in zend_mm_remove_from_free_list () (gdb) bt #0 0x0044dbec in zend_mm_remove_from_free_list () #1 0x0044edbc in _zend_mm_free_int () #2 0x0044f848 in _efree () #3 0x00473eb0 in _zval_dtor_func () #4 0x004a1994 in _zval_dtor () #5 0x004b2b6c in ZEND_ECHO_SPEC_TMP_HANDLER () #6 0x004b2c10 in ZEND_PRINT_SPEC_TMP_HANDLER () #7 0x004a3470 in execute () #8 0x004a3d04 in zend_do_fcall_common_helper_SPEC () #9 0x004a4b88 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #10 0x004a3470 in execute () #11 0x004a3d04 in zend_do_fcall_common_helper_SPEC () #12 0x004a4b88 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #13 0x004a3470 in execute () #14 0x00476cd8 in zend_execute_scripts () #15 0x0040deb0 in php_execute_script () #16 0x005132a4 in main () ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=39508&edit=1