Description: ------------ When trying to upgrade PEAR from 1.4.0a2 to 1.4.0a3 I'm experiencing a segmentation fault with PHP5.0.2 on Debian. Using PHP4 on the same server works OK (except for those strange preferred_state notices) Reproduce code: --------------- pear upgrade PEAR Expected result: ---------------- Upgrade OK Actual result: -------------- schst@rot3:schst> sudo pear5 upgrade PEAR Password: Failed to download pear/PEAR_Frontend_Web within preferred state alpha", latest release is version 0.4, stability "beta", use "channel://pear.php.net/PEAR_Frontend_Web-0.4" to install Failed to download pear/PEAR_Frontend_Gtk within preferred state alpha", latest release is version 0.3, stability "beta", use "channel://pear.php.net/PEAR_Frontend_Gtk-0.3" to install pear/PEAR can optionally use package "pear/PEAR_Frontend_Web" (version >= 0.5.0) pear/PEAR can optionally use package "pear/PEAR_Frontend_Gtk" (version >= 0.4.0) downloading PEAR-1.4.0a3.tgz ... Starting to download PEAR-1.4.0a3.tgz (243,679 bytes) ..................................................done: 243,679 bytes downloading Archive_Tar-1.2.tgz ... Starting to download Archive_Tar-1.2.tgz (14,792 bytes) ...done: 14,792 bytes downloading XML_RPC-1.2.0.tgz ... Starting to download XML_RPC-1.2.0.tgz (21,731 bytes) ...done: 21,731 bytes upgrade ok: channel://pear.php.net/Archive_Tar-1.2 upgrade ok: channel://pear.php.net/XML_RPC-1.2.0 Segmentation fault Trying the same with my PHP4 installation: schst@rot3:schst> sudo pear upgrade PEAR Failed to download pear/PEAR_Frontend_Web within preferred state alpha", latest release is version 0.4, stability "beta", use "channel://pear.php.net/PEAR_Frontend_Web-0.4" to install Failed to download pear/PEAR_Frontend_Gtk within preferred state alpha", latest release is version 0.3, stability "beta", use "channel://pear.php.net/PEAR_Frontend_Gtk-0.3" to install pear/PEAR can optionally use package "pear/PEAR_Frontend_Web" (version >= 0.5.0) pear/PEAR can optionally use package "pear/PEAR_Frontend_Gtk" (version >= 0.4.0) downloading PEAR-1.4.0a3.tgz ... Starting to download PEAR-1.4.0a3.tgz (243,679 bytes) ........................done: 243,679 bytes downloading XML_RPC-1.2.0.tgz ... Starting to download XML_RPC-1.2.0.tgz (21,731 bytes) ...done: 21,731 bytes upgrade ok: channel://pear.php.net/XML_RPC-1.2.0 upgrade ok: channel://pear.php.net/PEAR-1.4.0a3 PEAR: Optional feature remoteinstall available (adds the ability to install packages to a remote ftp server) PEAR: Optional feature webinstaller available (PEAR's web-based installer) PEAR: Optional feature gtkinstaller available (PEAR's PHP-GTK-based installer) To install use "pear install PEAR#featurename"

well, obviously a seg fault is a php issue, but can you trace it to the line that causes it?

I encounter the same problem with OSX 10.3.8 (as added to the OS box) going from 1.4.0a1 to a4, I ran it using gdb and got: # Program received signal EXC_BAD_ACCESS, Could not access memory. # 0x0019d1e8 in zend_get_class_entry (zobject=0x33f7590) at /Users/davey/Downloads/php-5.0.3/Zend/zend_API.c:204 # 204 /Users/davey/Downloads/php-5.0.3/Zend/zend_API.c: No such file or directory. # in /Users/davey/Downloads/php-5.0.3/Zend/zend_API.c I don't know if this helps, but it might. - Davey

I'm not familiar with the Installer structure, where should a start adding some echos? Or I could also grant you SSH access to the machine that causes the crash if that is helping you.

I ran into the same problem going from 1.4.0a2 to 1.4.0a4. The package*.xml said that PEAR_Frontend_Web 0.5.0 was required as was PEAR_Frontend_Gtk 0.4.0. Neither of these package have been release with this version yet. I untarred the package, edited the package files to the current versions of for each PEAR_Frontend_* package and then repackaged PEAR. Then I installed from the new PEAR-1.4.0a4.tgz and everything went fine. I doubt that the wrong version numbers were the exact cause of the seg fault but I think they were leading to what ever was causing it.

those dependencies were there in 1.4.0a1. The current versions are incompatible with PEAR 1.4.0, and will fail.

OK, I also encountered this on FreeBSD 4.10 (ammended bug data accordingly) so I'm going to say that this is definately *nix specific (doesn't happen on Win32 with PHP 5.0.3) I managed to get a core file on FreeBSD (joy!) and ran it through gdb. The (first part of the) stack is as follows: #0 0x1 in ?? () #1 0x824601a in zend_fetch_debug_backtrace (return_value=0x92cfb4c, skip_last=1) at /usr/home/davey/phpsource/php-5.0.3/Zend/zend_builtin_functions.c:1740 #2 0x8246239 in zif_debug_backtrace (ht=0, return_value=0x92cfb4c, this_ptr=0x0, return_value_used=1) at /usr/home/davey/phpsource/php-5.0.3/Zend/zend_builtin_functions.c:1830 #3 0x8276577 in zend_do_fcall_common_helper (execute_data=0xbfbf0224, opline=0x866a9d8, op_array=0x8633b0c) at /usr/home/davey/phpsource/php-5.0.3/Zend/zend_execute.c:2713 #4 0x8276cf6 in zend_do_fcall_handler (execute_data=0xbfbf0224, opline=0x866a9d8, op_array=0x8633b0c) at /usr/home/davey/phpsource/php-5.0.3/Zend/zend_execute.c:2843 #5 0x825b27f in execute (op_array=0x8633b0c) at /usr/home/davey/phpsource/php-5.0.3/Zend/zend_execute.c:1400 #6 0x8276680 in zend_do_fcall_common_helper (execute_data=0xbfbf0dd4, opline=0x865057c, op_array=0x863300c) at /usr/home/davey/phpsource/php-5.0.3/Zend/zend_execute.c:2740 #7 0x8276aaa in zend_do_fcall_by_name_handler (execute_data=0xbfbf0dd4, opline=0x865057c, op_array=0x863300c) at /usr/home/davey/phpsource/php-5.0.3/Zend/zend_execute.c:2825 #8 0x825b27f in execute (op_array=0x863300c) at /usr/home/davey/phpsource/php-5.0.3/Zend/zend_execute.c:1400 I'm no expert with backtraces, but I'm doing to say this is related to the debug_backtrace segfault experienced elsewhere. HTH - Davey

Just to verify that I have also seen this bug in a PHP 5.0.4-dev snapshot (compiled as of a couple of hours ago). Is there any way to re-write the code to not use debug_backtrace? Does debug_print_backtrace() use the same methods? At the risk of being really ugly, on PHP5 (which seems to be where the bug is) you could throw an exception and check its backtrace... Just throwing up ideas, please don't kill me. - Davey

Just to confirm this bug is STILL there in 5.1.0-dev *grumblefuss* - Davey

open a bug at php.net. A segfault due to proper use of php is not a bug in PEAR. Instead, this is a major bug in php.