#48575 [NEW]: Darwin / OS X should use dlopen() et al
From: php at group dot apple dot com Operating system: Mac OS X PHP version: 5.3.0RC3 PHP Bug Type: *Compile Issues Bug description: Darwin / OS X should use dlopen() et al Description: There is a flaw in the logic in the low-level Zend pieces regarding Mac OS X's ability to use dlopen() and its cousins. When available, those standard APIs should _always_ be used in lieu of the deprecated dyld functions. In effect, the #ifdef logic in zend.h should be reversed to use HAVE_MACH_O_DYLD_H only if HAVE_DLFCN_H is undefined. However, that change caused confusion elsewhere, so the patch below is a skanky workaround without applying broader modifications to the Zend core. Ideally, Zend should do the right thing and preferably drop support for those old versions of OS X which needed the dyld APIs; that would obviate the need for this patch. I am writing the bug here because zend.com doesn't have a similar facility and this appears to be an embedded use of their toolkit. Reproduce code: --- --- php-5.3.0/acconfig.h2009-06-10 11:23:33.0 -0700 +++ php/acconfig.h 2009-06-16 17:10:25.0 -0700 @@ -120,6 +120,15 @@ #endif /* + * Don't use on Mac OS X / Darwin if dl*() functions are available. + * Because this header is processed multiple times during compilation (thanks to lack of + * #ifdef protectors), this logic had to move here. + */ +#if defined(HAVE_DLFCN_H) && defined(HAVE_MACH_O_DYLD_H) +#/* This symbol must be allowed to be cleared. */ undef HAVE_MACH_O_DYLD_H +#endif + +/* * Local variables: * tab-width: 4 * c-basic-offset: 4 --- php-5.3.0RC3/main/php_config.h.in 2009-06-10 11:23:36.0 -0700 +++ php/main/php_config.h.in2009-06-16 17:10:25.0 -0700 @@ -2948,6 +2948,15 @@ #endif /* + * Don't use on Mac OS X / Darwin if dl*() functions are available. + * Because this header is processed multiple times during compilation (thanks to lack of + * #ifdef protectors), this logic had to move here. + */ +#if defined(HAVE_DLFCN_H) && defined(HAVE_MACH_O_DYLD_H) +#/* This symbol must be allowed to be cleared. */ undef HAVE_MACH_O_DYLD_H +#endif + +/* * Local variables: * tab-width: 4 * c-basic-offset: 4 -- Edit bug report at http://bugs.php.net/?id=48575&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48575&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48575&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48575&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48575&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48575&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48575&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48575&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48575&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48575&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48575&r=support Expected behavior: http://bugs.php.net/fix.php?id=48575&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48575&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48575&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48575&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48575&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48575&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48575&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48575&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48575&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48575&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48575&r=mysqlcfg
#48575 [Com]: Darwin / OS X should use dlopen() et al
ID: 48575 Comment by: php at group dot apple dot com Reported By: php at group dot apple dot com Status: Feedback Bug Type: *Compile Issues Operating System: Mac OS X PHP Version: 5.3.0RC3 New Comment: Quoting from: http://developer.apple.com/documentation/DeveloperTools/Reference/Mach OReference /Reference/reference.html "These [dlopen() et al] are the recommended functions to use to interact with the dynamic loader. These functions work in Mac OS X v10.3 and v10.4. However, in Mac OS X v10.4 they are more efficient than other image-loading functions. These functions are declared in /usr/include/dlfcn.h." 10.3 was released on 24 October 2003; 10.2 was released on 24 August 2002, so dropping support entirely means no longer supporting seven year old software. This applies to both Leopard and Snow Leopard. And it builds just fine on Snow Leopard. :-) Previous Comments: [2009-06-17 01:58:52] scott...@php.net Do you have any details about what the older versions of OSX are that required the use of the dyld API? On a sidenote, are you testing this on Snow Leopard? We don't currently have an install of this available to test on, things might be broken there. [2009-06-17 00:53:32] php at group dot apple dot com Description: There is a flaw in the logic in the low-level Zend pieces regarding Mac OS X's ability to use dlopen() and its cousins. When available, those standard APIs should _always_ be used in lieu of the deprecated dyld functions. In effect, the #ifdef logic in zend.h should be reversed to use HAVE_MACH_O_DYLD_H only if HAVE_DLFCN_H is undefined. However, that change caused confusion elsewhere, so the patch below is a skanky workaround without applying broader modifications to the Zend core. Ideally, Zend should do the right thing and preferably drop support for those old versions of OS X which needed the dyld APIs; that would obviate the need for this patch. I am writing the bug here because zend.com doesn't have a similar facility and this appears to be an embedded use of their toolkit. Reproduce code: --- --- php-5.3.0/acconfig.h2009-06-10 11:23:33.0 -0700 +++ php/acconfig.h 2009-06-16 17:10:25.0 -0700 @@ -120,6 +120,15 @@ #endif /* + * Don't use on Mac OS X / Darwin if dl*() functions are available. + * Because this header is processed multiple times during compilation (thanks to lack of + * #ifdef protectors), this logic had to move here. + */ +#if defined(HAVE_DLFCN_H) && defined(HAVE_MACH_O_DYLD_H) +#/* This symbol must be allowed to be cleared. */ undef HAVE_MACH_O_DYLD_H +#endif + +/* * Local variables: * tab-width: 4 * c-basic-offset: 4 --- php-5.3.0RC3/main/php_config.h.in 2009-06-10 11:23:36.0 -0700 +++ php/main/php_config.h.in2009-06-16 17:10:25.0 -0700 @@ -2948,6 +2948,15 @@ #endif /* + * Don't use on Mac OS X / Darwin if dl*() functions are available. + * Because this header is processed multiple times during compilation (thanks to lack of + * #ifdef protectors), this logic had to move here. + */ +#if defined(HAVE_DLFCN_H) && defined(HAVE_MACH_O_DYLD_H) +#/* This symbol must be allowed to be cleared. */ undef HAVE_MACH_O_DYLD_H +#endif + +/* * Local variables: * tab-width: 4 * c-basic-offset: 4 -- Edit this bug report at http://bugs.php.net/?id=48575&edit=1
#50185 [Com]: ldap_get_entries() return false instead of an empty array when there is no error
ID: 50185
Comment by: php at group dot apple dot com
Reported By: Joel dot Brogniart at univ-lyon2 dot fr
Status: Feedback
Bug Type: LDAP related
Operating System: Mac OS X 10.5.8
PHP Version: 5.2.11
New Comment:
This behavior changed in 5.2.9, apparently due to the change associated
with http://bugs.php.net/bug.php?id=48469
Previous Comments:
[2009-11-16 09:38:24] j...@php.net
RTFM: "Returns a complete result information in a multi-dimensional
array on success and FALSE on error. "
Your query most likely has an error, try check it with ldap_error()
[2009-11-16 08:50:07] Joel dot Brogniart at univ-lyon2 dot fr
Description:
With PHP version < 5.2.10, if the "bad_uid" is not in the LDAP
directory and no error occured the following code return an empty array
in $info. With PHP version 5.2.10 it return FALSE $info even when there
is no error.
(simplified code)
$ldap_host="ldap.example.com";
$ldap_root="ou=people,dc=example,dc=com";
$ldap_dn="cn=admin,ou=people,dc=example,dc=com";
$ldap_password="fak3pwd";
$result = array();
$attribute_list = array("uid");
$connection = ldap_connect($ldap_host);
$link = @ldap_bind($connection, $ldap_dn, $ldap_password);
$search="(uid=bad_uid)";
$search_result = ldap_search($connection, $ldap_root, $search,
$attribute_list);
$info = ldap_get_entries($connection, $search_result);
Reproduce code:
---
---
>From manual page: function.ldap-get-entries#Return Values
---
$ldap_host="ldap.example.com";
$ldap_root="ou=people,dc=example,dc=com";
$ldap_dn="cn=admin,ou=people,dc=example,dc=com";
$ldap_password="fak3pwd";
$result = array();
$attribute_list = array("uid");
$connection = ldap_connect($ldap_host);
$link = @ldap_bind($connection, $ldap_dn, $ldap_password);
$search="(uid=bad_uid)";
$search_result = ldap_search($connection, $ldap_root, $search,
$attribute_list);
$info = ldap_get_entries($connection, $search_result);
Expected result:
$info :
Array
(
)
Actual result:
--
$info :
--
Edit this bug report at http://bugs.php.net/?id=50185&edit=1
Req #42630 [Com]: dlopen() should be preferred to NSLinkModule()
Edit report at http://bugs.php.net/bug.php?id=42630&edit=1
ID: 42630
Comment by: php at group dot apple dot com
Reported by: jdolecek at NetBSD dot org
Summary: dlopen() should be preferred to NSLinkModule()
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: Mac OS X 10.4
PHP Version: 5.2.4
New Comment:
I believe this was addressed in 5.3.1 or 5.3.2.
Previous Comments:
[2007-09-11 20:27:05] jdolecek at NetBSD dot org
Description:
PHP uses NSLinkModule()-based interface for loading dynamic extensions.
Since Mac OS X 10.4, dlopen() is now available as native function and
should be used in preference to older NSLinkModule()-based method, for
consistency with other UNIX platforms.
Fix - if dlopen() is available, use dlopen(), otherwise fallback to
NSLinkModule():
--- Zend/zend.h.orig2007-09-05 00:16:02.0 +0200
+++ Zend/zend.h
@@ -80,18 +80,7 @@
# include
#endif
-#if HAVE_MACH_O_DYLD_H
-#include
-
-/* MH_BUNDLE loading functions for Mac OS X / Darwin */
-void *zend_mh_bundle_load (char* bundle_path);
-int zend_mh_bundle_unload (void *bundle_handle);
-void *zend_mh_bundle_symbol(void *bundle_handle, const char
*symbol_name);
-const char *zend_mh_bundle_error(void);
-
-#endif /* HAVE_MACH_O_DYLD_H */
-
-#if defined(HAVE_LIBDL) && !defined(HAVE_MACH_O_DYLD_H) &&
!defined(ZEND_WIN32)
+#if defined(HAVE_LIBDL) && !defined(ZEND_WIN32)
# ifndef RTLD_LAZY
# define RTLD_LAZY 1/* Solaris 1, FreeBSD's (2.1.7.1 and older)
*/
@@ -118,6 +107,14 @@ const char *zend_mh_bundle_error(void);
# define DL_HANDLE void *
# define ZEND_EXTENSIONS_SUPPORT 1
#elif defined(HAVE_MACH_O_DYLD_H)
+
+#include
+
+/* MH_BUNDLE loading functions for Mac OS X / Darwin */
+void *zend_mh_bundle_load (char* bundle_path);
+int zend_mh_bundle_unload (void *bundle_handle);
+void *zend_mh_bundle_symbol(void *bundle_handle, const char
*symbol_name);
+const char *zend_mh_bundle_error(void);
# define DL_LOAD(libname)
zend_mh_bundle_load(libname)
# define DL_UNLOAD zend_mh_bundle_unload
# define DL_FETCH_SYMBOL(h,s)
zend_mh_bundle_symbol(h,s)
--- Zend/zend_extensions.c.orig 2007-09-05 00:24:04.0 +0200
+++ Zend/zend_extensions.c
@@ -230,7 +230,7 @@ ZEND_API zend_extension *zend_get_extens
*
*/
-#if HAVE_MACH_O_DYLD_H
+#if defined(HAVE_MACH_O_DYLD_H) && !defined(HAVE_LIBDL)
void *zend_mh_bundle_load(char* bundle_path)
{
@@ -284,7 +284,7 @@ const char *zend_mh_bundle_error(void)
return NULL;
}
-#endif /* HAVE_MACH_O_DYLD_H */
+#endif /* HAVE_MACH_O_DYLD_H && !HAVE_LIBDL */
/*
* Local variables:
Reproduce code:
---
I've originally developed this patch as a fix to bug #42629 to make
extensions load with RTLD_GLOBAL. However, I found simplier fix to that
problem, so I'm filling this dlopen() change as a separate bug report.
--
Edit this bug report at http://bugs.php.net/bug.php?id=42630&edit=1
[PHP-BUG] Bug #51467 [NEW]: Crash in shutdown
From: Operating system: Mac OS X 10.6 PHP version: 5.3.2 Package: Reproducible crash Bug Type: Bug Bug description:Crash in shutdown Description: Executing certain scripts on Mac OS X 10.6 running 5.3.2 (or 5.3.1 or 5.3) causes a crash in the shutdown routine. The stack trace appears to be the same reported in http://bugs.php.net/bug.php?id=49209. See stack trace below. I uploaded a tarball named "shutdown_crasher.tar.gz" as a smallish sample demonstrating the flaw. "php displayDoc.php" shows the first crash noted below. Putting the files into an apache doc root and loading the index.html file shows two buttons. Clicking on one should cause apache to crash. (Oddly, one deployment always crashed with the "synchronous" call while another always crashed with the "async" call.) This crash is the second noted below. Test script: --- See tarball attached as a patch. Expected result: I expected output without a crash. Actual result: -- Backtrace from php CLI: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0001434ed621 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 php 0x00010032aa3f gc_zval_possible_root + 99 1 php 0x00010031ad97 zend_hash_destroy + 42 2 php 0x0001001a2b35 sxe_object_free_storage + 53 3 php 0x00010032f351 zend_objects_store_free_object_storage + 120 4 php 0x000100304ab1 shutdown_executor + 515 5 php 0x00010030fce8 zend_deactivate + 111 6 php 0x0001002c2fce php_request_shutdown + 597 7 php 0x00010038c51f main + 5213 8 php 0x000113b8 start + 52 Backtrace from apache: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0001d074cc21 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libphp5.so 0x00010131c64f gc_zval_possible_root + 99 1 libphp5.so 0x00010130d58b zend_hash_destroy + 42 2 libphp5.so 0x00010119e100 sxe_object_free_storage + 53 3 libphp5.so 0x000101320f05 zend_objects_store_free_object_storage + 120 4 libphp5.so 0x0001012f76f2 shutdown_executor + 515 5 libphp5.so 0x000101302508 zend_deactivate + 111 6 libphp5.so 0x0001012b6481 php_request_shutdown + 597 7 libphp5.so 0x00010137cff9 php_handler + 1370 [apache stack removed] -- Edit bug report at http://bugs.php.net/bug.php?id=51467&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51467&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51467&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51467&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51467&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51467&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51467&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51467&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51467&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51467&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51467&r=support Expected behavior: http://bugs.php.net/fix.php?id=51467&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51467&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51467&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51467&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51467&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51467&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51467&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51467&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51467&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51467&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51467&r=mys
Bug #51467 [Com]: Crash in shutdown
Edit report at http://bugs.php.net/bug.php?id=51467&edit=1 ID: 51467 Comment by: php at group dot apple dot com Reported by: php at group dot apple dot com Summary: Crash in shutdown Status: Feedback Type: Bug Package: Reproducible crash Operating System: Mac OS X 10.6 PHP Version: 5.3.2 New Comment: The patch file didn't upload because it wasn't text. I base64'd it and posted it here: http://pastebin.org/131802 Previous Comments: [2010-04-03 02:43:18] ras...@php.net That doesn't look like the same backtrace to me. Try turning off gc in your php.ini: zend.enable_gc=Off And see if it still happens. There have been some recent fixes to the gc code. ---- [2010-04-03 02:39:45] php at group dot apple dot com Description: Executing certain scripts on Mac OS X 10.6 running 5.3.2 (or 5.3.1 or 5.3) causes a crash in the shutdown routine. The stack trace appears to be the same reported in http://bugs.php.net/bug.php?id=49209. See stack trace below. I uploaded a tarball named "shutdown_crasher.tar.gz" as a smallish sample demonstrating the flaw. "php displayDoc.php" shows the first crash noted below. Putting the files into an apache doc root and loading the index.html file shows two buttons. Clicking on one should cause apache to crash. (Oddly, one deployment always crashed with the "synchronous" call while another always crashed with the "async" call.) This crash is the second noted below. Test script: --- See tarball attached as a patch. Expected result: I expected output without a crash. Actual result: -- Backtrace from php CLI: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0001434ed621 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 php 0x00010032aa3f gc_zval_possible_root + 99 1 php 0x00010031ad97 zend_hash_destroy + 42 2 php 0x0001001a2b35 sxe_object_free_storage + 53 3 php 0x00010032f351 zend_objects_store_free_object_storage + 120 4 php 0x000100304ab1 shutdown_executor + 515 5 php 0x00010030fce8 zend_deactivate + 111 6 php 0x0001002c2fce php_request_shutdown + 597 7 php 0x00010038c51f main + 5213 8 php 0x000113b8 start + 52 Backtrace from apache: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0001d074cc21 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libphp5.so 0x00010131c64f gc_zval_possible_root + 99 1 libphp5.so 0x00010130d58b zend_hash_destroy + 42 2 libphp5.so 0x00010119e100 sxe_object_free_storage + 53 3 libphp5.so 0x000101320f05 zend_objects_store_free_object_storage + 120 4 libphp5.so 0x0001012f76f2 shutdown_executor + 515 5 libphp5.so 0x000101302508 zend_deactivate + 111 6 libphp5.so 0x0001012b6481 php_request_shutdown + 597 7 libphp5.so 0x00010137cff9 php_handler + 1370 [apache stack removed] -- Edit this bug report at http://bugs.php.net/bug.php?id=51467&edit=1
Bug #51467 [Com]: Crash in shutdown
Edit report at http://bugs.php.net/bug.php?id=51467&edit=1 ID: 51467 Comment by: php at group dot apple dot com Reported by: php at group dot apple dot com Summary: Crash in shutdown Status: Feedback Type: Bug Package: Reproducible crash Operating System: Mac OS X 10.6 PHP Version: 5.3.2 New Comment: Are you saying the two backtraces in this report don't look the same or that #49209's backtrace doesn't look the same? If the former, focus on the function name + offsets and you will see they are practically identical. If the latter, consider that the other report is a different OS (Linux) running PHP 5.2.10; given the similarities, this bug appears to have been latent in multiple releases. To answer your question, disabling GC prevents the crash. Previous Comments: [2010-04-03 03:13:59] php at group dot apple dot com The patch file didn't upload because it wasn't text. I base64'd it and posted it here: http://pastebin.org/131802 [2010-04-03 02:43:18] ras...@php.net That doesn't look like the same backtrace to me. Try turning off gc in your php.ini: zend.enable_gc=Off And see if it still happens. There have been some recent fixes to the gc code. ------------ [2010-04-03 02:39:45] php at group dot apple dot com Description: Executing certain scripts on Mac OS X 10.6 running 5.3.2 (or 5.3.1 or 5.3) causes a crash in the shutdown routine. The stack trace appears to be the same reported in http://bugs.php.net/bug.php?id=49209. See stack trace below. I uploaded a tarball named "shutdown_crasher.tar.gz" as a smallish sample demonstrating the flaw. "php displayDoc.php" shows the first crash noted below. Putting the files into an apache doc root and loading the index.html file shows two buttons. Clicking on one should cause apache to crash. (Oddly, one deployment always crashed with the "synchronous" call while another always crashed with the "async" call.) This crash is the second noted below. Test script: --- See tarball attached as a patch. Expected result: I expected output without a crash. Actual result: -- Backtrace from php CLI: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0001434ed621 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 php 0x00010032aa3f gc_zval_possible_root + 99 1 php 0x00010031ad97 zend_hash_destroy + 42 2 php 0x0001001a2b35 sxe_object_free_storage + 53 3 php 0x00010032f351 zend_objects_store_free_object_storage + 120 4 php 0x000100304ab1 shutdown_executor + 515 5 php 0x00010030fce8 zend_deactivate + 111 6 php 0x0001002c2fce php_request_shutdown + 597 7 php 0x00010038c51f main + 5213 8 php 0x000113b8 start + 52 Backtrace from apache: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0001d074cc21 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libphp5.so 0x00010131c64f gc_zval_possible_root + 99 1 libphp5.so 0x00010130d58b zend_hash_destroy + 42 2 libphp5.so 0x00010119e100 sxe_object_free_storage + 53 3 libphp5.so 0x000101320f05 zend_objects_store_free_object_storage + 120 4 libphp5.so 0x0001012f76f2 shutdown_executor + 515 5 libphp5.so 0x000101302508 zend_deactivate + 111 6 libphp5.so 0x0001012b6481 php_request_shutdown + 597 7 libphp5.so 0x00010137cff9 php_handler + 1370 [apache stack removed] -- Edit this bug report at http://bugs.php.net/bug.php?id=51467&edit=1
Bug #51467 [Com]: Crash in shutdown
Edit report at http://bugs.php.net/bug.php?id=51467&edit=1 ID: 51467 Comment by: php at group dot apple dot com Reported by: php at group dot apple dot com Summary: Crash in shutdown Status: Feedback Type: Bug Package: Reproducible crash Operating System: Mac OS X 10.6 PHP Version: 5.3.2 New Comment: Downloading now. Given the integration time to build in our environment, I likely won't have results until Monday. Previous Comments: [2010-04-03 03:25:02] ras...@php.net But you just proved they are unrelated. Your backtrace showed a gc_ function as the crash point, and disabling gc fixed it. There was no gc code in PHP 5.2.x which is the version bug 49209 was reported against, and of course there are no gc functions in the backtrace of that report. So, please try a current PHP 5.3 snapshot to see if the recent gc fixes has addressed this particular issue. [2010-04-03 03:21:42] php at group dot apple dot com Are you saying the two backtraces in this report don't look the same or that #49209's backtrace doesn't look the same? If the former, focus on the function name + offsets and you will see they are practically identical. If the latter, consider that the other report is a different OS (Linux) running PHP 5.2.10; given the similarities, this bug appears to have been latent in multiple releases. To answer your question, disabling GC prevents the crash. ---- [2010-04-03 03:13:59] php at group dot apple dot com The patch file didn't upload because it wasn't text. I base64'd it and posted it here: http://pastebin.org/131802 [2010-04-03 02:43:18] ras...@php.net That doesn't look like the same backtrace to me. Try turning off gc in your php.ini: zend.enable_gc=Off And see if it still happens. There have been some recent fixes to the gc code. ---------------- [2010-04-03 02:39:45] php at group dot apple dot com Description: Executing certain scripts on Mac OS X 10.6 running 5.3.2 (or 5.3.1 or 5.3) causes a crash in the shutdown routine. The stack trace appears to be the same reported in http://bugs.php.net/bug.php?id=49209. See stack trace below. I uploaded a tarball named "shutdown_crasher.tar.gz" as a smallish sample demonstrating the flaw. "php displayDoc.php" shows the first crash noted below. Putting the files into an apache doc root and loading the index.html file shows two buttons. Clicking on one should cause apache to crash. (Oddly, one deployment always crashed with the "synchronous" call while another always crashed with the "async" call.) This crash is the second noted below. Test script: --- See tarball attached as a patch. Expected result: I expected output without a crash. Actual result: -- Backtrace from php CLI: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0001434ed621 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 php 0x00010032aa3f gc_zval_possible_root + 99 1 php 0x00010031ad97 zend_hash_destroy + 42 2 php 0x0001001a2b35 sxe_object_free_storage + 53 3 php 0x00010032f351 zend_objects_store_free_object_storage + 120 4 php 0x000100304ab1 shutdown_executor + 515 5 php 0x00010030fce8 zend_deactivate + 111 6 php 0x0001002c2fce php_request_shutdown + 597 7 php 0x00010038c51f main + 5213 8 php 0x000113b8 start + 52 Backtrace from apache: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0001d074cc21 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libphp5.so 0x00010131c64f gc_zval_possible_root + 99 1 libphp5.so 0x00010130d58b zend_hash_destroy + 42 2 libphp5.so 0x00010119e100 sxe_object_free_storage + 53 3 libphp5.so 0x000101320f05 zend_objects_store_free_object_storage + 120 4 libphp5.so
Bug #51467 [Com]: Crash in shutdown
Edit report at http://bugs.php.net/bug.php?id=51467&edit=1 ID: 51467 Comment by: php at group dot apple dot com Reported by: php at group dot apple dot com Summary: Crash in shutdown Status: Feedback Type: Bug Package: Reproducible crash Operating System: Mac OS X 10.6 PHP Version: 5.3.2 New Comment: The same crash occurs with php5.3-201004030030.tar.bz2. Previous Comments: [2010-04-03 03:33:39] php at group dot apple dot com Downloading now. Given the integration time to build in our environment, I likely won't have results until Monday. [2010-04-03 03:25:02] ras...@php.net But you just proved they are unrelated. Your backtrace showed a gc_ function as the crash point, and disabling gc fixed it. There was no gc code in PHP 5.2.x which is the version bug 49209 was reported against, and of course there are no gc functions in the backtrace of that report. So, please try a current PHP 5.3 snapshot to see if the recent gc fixes has addressed this particular issue. [2010-04-03 03:21:42] php at group dot apple dot com Are you saying the two backtraces in this report don't look the same or that #49209's backtrace doesn't look the same? If the former, focus on the function name + offsets and you will see they are practically identical. If the latter, consider that the other report is a different OS (Linux) running PHP 5.2.10; given the similarities, this bug appears to have been latent in multiple releases. To answer your question, disabling GC prevents the crash. ---- [2010-04-03 03:13:59] php at group dot apple dot com The patch file didn't upload because it wasn't text. I base64'd it and posted it here: http://pastebin.org/131802 [2010-04-03 02:43:18] ras...@php.net That doesn't look like the same backtrace to me. Try turning off gc in your php.ini: zend.enable_gc=Off And see if it still happens. There have been some recent fixes to the gc code. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51467 -- Edit this bug report at http://bugs.php.net/bug.php?id=51467&edit=1
Bug #51467 [Com]: Crash in shutdown
Edit report at http://bugs.php.net/bug.php?id=51467&edit=1 ID: 51467 Comment by: php at group dot apple dot com Reported by: php at group dot apple dot com Summary: Crash in shutdown Status: Feedback Type: Bug Package: Reproducible crash Operating System: Mac OS X 10.6 PHP Version: 5.3.2 New Comment: Any more feedback required to diagnose this problem? Previous Comments: [2010-04-03 05:08:22] php at group dot apple dot com The same crash occurs with php5.3-201004030030.tar.bz2. [2010-04-03 03:33:39] php at group dot apple dot com Downloading now. Given the integration time to build in our environment, I likely won't have results until Monday. [2010-04-03 03:25:02] ras...@php.net But you just proved they are unrelated. Your backtrace showed a gc_ function as the crash point, and disabling gc fixed it. There was no gc code in PHP 5.2.x which is the version bug 49209 was reported against, and of course there are no gc functions in the backtrace of that report. So, please try a current PHP 5.3 snapshot to see if the recent gc fixes has addressed this particular issue. [2010-04-03 03:21:42] php at group dot apple dot com Are you saying the two backtraces in this report don't look the same or that #49209's backtrace doesn't look the same? If the former, focus on the function name + offsets and you will see they are practically identical. If the latter, consider that the other report is a different OS (Linux) running PHP 5.2.10; given the similarities, this bug appears to have been latent in multiple releases. To answer your question, disabling GC prevents the crash. ---- [2010-04-03 03:13:59] php at group dot apple dot com The patch file didn't upload because it wasn't text. I base64'd it and posted it here: http://pastebin.org/131802 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51467 -- Edit this bug report at http://bugs.php.net/bug.php?id=51467&edit=1
[PHP-BUG] Bug #52043 [NEW]: GD doesn't recognize latest libJPEG version (8b)
From: Operating system: all PHP version: 5.3.2 Package: GD related Bug Type: Bug Bug description:GD doesn't recognize latest libJPEG version (8b) Description: Building php-5.3.2 against libJPEGv8b (NOT 6b!) appears to be functional, but php reports the wrong version number. The patch below adds an additional cast to the switch statement. Test script: --- php -info | grep -i jpeg Expected result: libJPEG Version => 8b Actual result: -- libJPEG Version => unknown -- Edit bug report at http://bugs.php.net/bug.php?id=52043&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52043&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52043&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52043&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52043&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52043&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52043&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52043&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52043&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52043&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52043&r=support Expected behavior: http://bugs.php.net/fix.php?id=52043&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52043&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52043&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52043&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52043&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52043&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52043&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52043&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52043&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52043&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52043&r=mysqlcfg
#50509 [Com]: "make install-pear-installer" does not honor $INSTALL_ROOT
ID: 50509 Comment by: php at group dot apple dot com Reported By: thomas dot parrott at jellyfish dot co dot uk Status: Assigned Bug Type: PHAR related Operating System: CentOS 5.4 PHP Version: 5.2.12 Assigned To: cellog New Comment: Looks like the same bug reported as https://pear.php.net/bugs/bug.php? id=17067 Previous Comments: [2009-12-18 00:33:47] j...@php.net Assigned to the PEAR maintainer. [2009-12-17 17:27:41] thomas dot parrott at jellyfish dot co dot uk Description: When building PHP as an RPM, "make install-pear-installer" does not provide the ability to install in a non-root environment, but still reference root file paths like /usr/lib/php in the files generated. Expected result: I expect the make install-pear-installer command to provide an option for BUILD_ROOT like PHP does, in order to install files into a non-root location. -- Edit this bug report at http://bugs.php.net/?id=50509&edit=1
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: php at group dot apple dot com Reported by:mbecc...@php.net Summary:Segmentation fault in mysql_fetch_array Status: Assigned Type: Bug Package:MySQL related Operating System: FreeBSD 6.2 PHP Version:5.3.2 Assigned To:mysql Block user comment: N New Comment: This reproduces on Mac OS X, and appears to be a stack overflow issue. I enabled stack overflow protection by adding "-g -fstack-protector-all" to the CFLAGS passed to configure. (The problem does not reproduce when configured with --enable-debug or -O0 instead of -Os.) In running this through gdb, the following line in changes execute_data and may be the start of the corruption: zend_vm_execute.h:301 EX_T(opline->result.u.var).var.ptr_ptr = &EX_T(opline->result.u.var).var.ptr; With the following sample script, the third pass through zend_do_fcall_common_helper_SPEC() demonstrates the crash: Previous Comments: [2010-08-26 13:27:05] u...@php.net Please try to provide a short test script, like its good style with every other bug report. [2010-08-25 10:32:16] paj...@php.net Latest drupal (6+) versions work with 5.3 smoothly. [2010-08-25 10:22:29] mbecc...@php.net @Chris: I understand that Drupal and PHP 5.3 might not live happily together, but I'd expect errors, not segmentation faults. @Andrey: Is there anything I can do to help understanding what happens on when using libmysql? [2010-08-24 20:14:29] chris at chrischarlton dot us Drupal 6.14 was the first 6.x to start supporting PHP 5.3, but mileage will vary. It is highly recommended to run Drupal on a PHP 5.2.x server. Of course Drupal will natively support PHP 5.3, there are just a few kinks being worked out. [2010-04-09 09:27:41] mbecc...@php.net I've been able to test the drush script with a newly compiled 5.3.2 w/ mysqlnd and it appears that the segmentation fault is gone. Is there any way I can trace what happens with libmysql? i.e. libmysql: $ /usr/local/bin/php ~/bin/drush/drush.php dis twitter The following projects will be disabled: twitter Do you really want to continue? (y/n): y Segmentation fault: 11 (core dumped) mysqlnd: $ /array1/compile/php-5.3.2-apache/sapi/cli/php -d mysqlnd.debug="t:o,/tmp/mysqlnd.trace" ~/bin/drush/drush.php dis twitter The following projects will be disabled: twitter Do you really want to continue? (y/n): y twitter was disabled successfully. [ok] The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51248 -- Edit this bug report at http://bugs.php.net/bug.php?id=51248&edit=1
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: php at group dot apple dot com Reported by:mbecc...@php.net Summary:Segmentation fault in mysql_fetch_array Status: Assigned Type: Bug Package:MySQL related Operating System: FreeBSD 6.2 PHP Version:5.3.2 Assigned To:mysql Block user comment: N New Comment: Does the request for valgrind mean you are unable to reproduce the behavior with - fstack-protector-all? Previous Comments: [2010-09-01 16:05:57] and...@php.net valgrind output would be helpful :) Thanks! [2010-08-27 22:00:08] php at group dot apple dot com This reproduces on Mac OS X, and appears to be a stack overflow issue. I enabled stack overflow protection by adding "-g -fstack-protector-all" to the CFLAGS passed to configure. (The problem does not reproduce when configured with --enable-debug or -O0 instead of -Os.) In running this through gdb, the following line in changes execute_data and may be the start of the corruption: zend_vm_execute.h:301 EX_T(opline->result.u.var).var.ptr_ptr = &EX_T(opline->result.u.var).var.ptr; With the following sample script, the third pass through zend_do_fcall_common_helper_SPEC() demonstrates the crash: [2010-08-26 13:27:05] u...@php.net Please try to provide a short test script, like its good style with every other bug report. [2010-08-25 10:32:16] paj...@php.net Latest drupal (6+) versions work with 5.3 smoothly. [2010-08-25 10:22:29] mbecc...@php.net @Chris: I understand that Drupal and PHP 5.3 might not live happily together, but I'd expect errors, not segmentation faults. @Andrey: Is there anything I can do to help understanding what happens on when using libmysql? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51248 -- Edit this bug report at http://bugs.php.net/bug.php?id=51248&edit=1
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: php at group dot apple dot com Reported by:mbecc...@php.net Summary:Segmentation fault in mysql_fetch_array Status: Assigned Type: Bug Package:MySQL related Operating System: FreeBSD 6.2 PHP Version:5.3.2 Assigned To:mysql Block user comment: N New Comment: As I noted, the problem disappears when compiled debug, so perhaps that option was enabled in your build? Since valgrind reports heap issues and this appears to be stack corruption, what data are you looking for? Mac OS X has a number of great debugging and analysis tools (Instruments, Shark, dtrace) I can use to get what you need. Previous Comments: [2010-09-03 18:16:49] mbecc...@php.net I've tried to use -fstack-protector-all both on FreeBSD 6.2 amd64 and Ubuntu Linux x64 and I can't see any segfaults, nor valgrind errors (tested on linux only) using the provided script. [2010-09-02 00:49:49] php at group dot apple dot com Does the request for valgrind mean you are unable to reproduce the behavior with - fstack-protector-all? [2010-09-01 16:05:57] and...@php.net valgrind output would be helpful :) Thanks! [2010-08-27 22:00:08] php at group dot apple dot com This reproduces on Mac OS X, and appears to be a stack overflow issue. I enabled stack overflow protection by adding "-g -fstack-protector-all" to the CFLAGS passed to configure. (The problem does not reproduce when configured with --enable-debug or -O0 instead of -Os.) In running this through gdb, the following line in changes execute_data and may be the start of the corruption: zend_vm_execute.h:301 EX_T(opline->result.u.var).var.ptr_ptr = &EX_T(opline->result.u.var).var.ptr; With the following sample script, the third pass through zend_do_fcall_common_helper_SPEC() demonstrates the crash: [2010-08-26 13:27:05] u...@php.net Please try to provide a short test script, like its good style with every other bug report. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51248 -- Edit this bug report at http://bugs.php.net/bug.php?id=51248&edit=1
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: php at group dot apple dot com Reported by:mbecc...@php.net Summary:Segmentation fault in mysql_fetch_array Status: Assigned Type: Bug Package:MySQL related Operating System: FreeBSD 6.2 PHP Version:5.3.2 Assigned To:mysql Block user comment: N New Comment: Thank you for attempting to reproduce on Mac OS X. The issue may be the choice of compiler, as the problem more readily reproduces with LLVM, which claims to be much more aggressive in its stack protection than GCC. One option would be to try to build using LLVM as the compiler, i.e.: CC=/usr/bin/llvm-gcc ./configure ... Previous Comments: [2010-10-06 14:17:47] and...@php.net No crash on 64bit MacOS X 10.6.4 , with or without the flags, libmysql. MySQL is 5.5.2 [2010-10-06 13:54:59] and...@php.net forgot to mention that I used the -g -fstack-protector-all [2010-10-06 13:52:59] and...@php.net I get no crash on Ubuntu 9.10 x86, PHP 5.3.4-dev, MySQL 5.1.51 . Neither with libmysql nor with mysqlnd, but by looking at the stacktrace it should not matter much. Will get it checked on Mac OS [2010-09-30 11:53:28] aaphp at mailinator dot com Received this using 5.3.3 on Apache 2.2.16 w/ Cpanel; CENTOS 4.8 x86_64 and osCommerce. Caused segfaults logged to /var/log/messages: Sep 29 20:23:22 hostname kernel: conftest[30619]: segfault at 0001 rip 00405dae rsp 007fb250 error 4 Sep 29 21:36:28 hostname kernel: php[20444]: segfault at 002a0014 rip 00741da3 rsp 007fbfffabb0 error 4 And php errors in /var/log/httpd/error_log: [Wed Sep 29 20:28:02 2010] [error] [client x.x.x.x] Premature end of script headers: php5 The errors are consistent - nothing loads on the site but 500 Internal Server Errors. Did not go away until PHP was downgraded to 5.2.14 or the following change made to the script: The Line: return mysql_fetch_array($db_query, MYSQL_ASSOC); Once changed to: return mysql_fetch_assoc($db_query); The error ceases & site functions as expected. [2010-09-24 20:38:23] janinemueller26 at gmail dot com I had also a mysql error with drupal and mysql on http://www.sportwettentipp.com, but update to the newest version and works fine, thanks for the bug fixing. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51248 -- Edit this bug report at http://bugs.php.net/bug.php?id=51248&edit=1
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: php at group dot apple dot com Reported by:mbecc...@php.net Summary:Segmentation fault in mysql_fetch_array Status: Feedback Type: Bug Package:MySQL related Operating System: FreeBSD 6.2 PHP Version:5.3.2 Assigned To:mysql Block user comment: N New Comment: Here are the configure flags I use: -- --with-apxs2=$(USRSBINDIR)/apxs \ --enable-cli \ --with-config-file-path=/etc \ --with-libxml-dir=$(USRDIR) \ --with-openssl=$(USRDIR) \ --with-kerberos=$(USRDIR) \ --with-zlib=$(USRDIR) \ --enable-bcmath \ --with-bz2=$(USRDIR) \ --enable-calendar \ --with-curl=$(USRDIR) \ --enable-exif \ --enable-ftp \ --with-gd \ --with-freetype-dir=$(DSTROOT)$(USRDIR)/local \ --with-jpeg-dir=$(DSTROOT)$(USRDIR)/local \ --with-png-dir=$(DSTROOT)$(USRDIR)/local \ --enable-gd-native-ttf \ --with-ldap=$(USRDIR) \ --with-ldap-sasl=$(USRDIR) \ --enable-mbstring \ --enable-mbregex \ --with-mysql=mysqlnd \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ --with-mysql-sock=/var/mysql/mysql.sock \ --with-iodbc=$(USRDIR) \ --enable-shmop \ --with-snmp=$(USRDIR) \ --enable-soap \ --enable-sockets \ --enable-suhosin \ --enable-sysvmsg --enable-sysvsem --enable-sysvshm \ --with-xmlrpc \ --with-iconv-dir=$(USRDIR) \ --with-xsl=$(USRDIR) \ --enable-zend-multibyte \ --enable-zip -- It may be relevant that I have applied the Suhosin patch to the sources. I will inspect the patch to see if it's modifying the crashing code in some way. In addition, I set CFLAGS="-Os -g -fstack-protector-all" before calling configure. I will build again and see if I can tease out more information. Previous Comments: [2010-10-13 12:33:21] and...@php.net Again, no crash and...@vihren:~/dev/php5.3-201010130830> $ ./php a.php mysql version: 5.1.44 and...@vihren:~/dev/php5.3-201010130830> $ cat config.nice #! /bin/sh # # Created by configure CC='/usr/bin/llvm-gcc' \ './configure' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--disable-libxml' \ '--disable-dom' \ '--disable-simplexml' \ '--disable-xml' \ '--disable-xmlreader' \ '--disable-xmlwriter' \ '--without-pear' \ "$@" and...@vihren:~/dev/php5.3-201010130830> $ uname -a Darwin vihren 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 The system is a MacOS X 10.6.something [2010-10-07 04:33:41] php at group dot apple dot com Thank you for attempting to reproduce on Mac OS X. The issue may be the choice of compiler, as the problem more readily reproduces with LLVM, which claims to be much more aggressive in its stack protection than GCC. One option would be to try to build using LLVM as the compiler, i.e.: CC=/usr/bin/llvm-gcc ./configure ... [2010-10-06 14:17:47] and...@php.net No crash on 64bit MacOS X 10.6.4 , with or without the flags, libmysql. MySQL is 5.5.2 [2010-10-06 13:54:59] and...@php.net forgot to mention that I used the -g -fstack-protector-all [2010-10-06 13:52:59] and...@php.net I get no crash on Ubuntu 9.10 x86, PHP 5.3.4-dev, MySQL 5.1.51 . Neither with libmysql nor with mysqlnd, but by looking at the stacktrace it should not matter much. Will get it checked on Mac OS The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51248 -- Edit this bug report at http://bugs.php.net/bug.php?id=51248&edit=1
Bug #53199 [Com]: Phar doesn't work with '--enable-zend-multibyte' option
Edit report at http://bugs.php.net/bug.php?id=53199&edit=1
ID: 53199
Comment by: php at group dot apple dot com
Reported by:brt dot river at gmail dot com
Summary:Phar doesn't work with '--enable-zend-multibyte'
option
Status: Open
Type: Bug
Package:PHAR related
Operating System: Mac OS X 10.6
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
I have been debugging a similar report with the phar CLI. Executing "php
phar.php"
(using the generated php/ext/phar/phar.php) works properly, but the
resulting
phar.phar does not. I have tried modifying the stub (via phar.php) to
print
debugging information but that only produces more "?" characters.
Attempting to
debug with Xdebug and MacGDBp wouldn't step through the first line
before
terminating.
Previous Comments:
[2010-10-29 10:22:36] brt dot river at gmail dot com
Description:
I'm using PHP 5.3.3 with '--enable-zend-multibyte' under Mac OS X.
My script calls my phar archive directly, The result characters are
garbled.
Test script:
---
* create.php
setStub('http://bugs.php.net/bug.php?id=53199&edit=1
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: php at group dot apple dot com Reported by:mbecc...@php.net Summary:Segmentation fault in mysql_fetch_array Status: Feedback Type: Bug Package:MySQL related Operating System: FreeBSD 6.2 PHP Version:5.3.2 Assigned To:mysql Block user comment: N Private report: N New Comment: I think I may have discovered the culprit: mistaken architecture information! Here are sample runs using different architectures: # arch -i386 /usr/bin/php /build/mysql_fetch_array_8264855.php mysql version: 5.0.91-log # arch -x86_64 /usr/bin/php /build/mysql_fetch_array_8264855.php zsh: segmentation fault arch -x86_64 /usr/bin/php /build/mysql_fetch_array_8264855.php Mac OS X builds "fat", i.e. multiple-architectures in a single compilation pass by passing "-arch i386 -arch x86_64". The system headers properly handle the data size differences, but projects which depend upon configure's evaluation of data sizes instead of system headers such as are often bit by this. The problem is exacerbated by configure's test to determine if it is cross-compiling; since Mac OS X can build and run both i386 and x86_64, configure ignores the cross-compilation directive and determines the results from the runtime. I will post more once I get a feeling for how pervasive the changes may be. Previous Comments: [2010-10-27 16:11:47] johizzle at gmail dot com I found that recompiling it with --enable-debug fixed the issue of the mysql_fetch_array($var,MYSQL_ASSOC); causing a segmentation fault(11). It's also good to note, that I installed mysql-client-community rpm, as well. RHEL 4.8 Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.7a PHP/5.3.3 ------------ [2010-10-15 00:57:38] php at group dot apple dot com Here are the configure flags I use: -- --with-apxs2=$(USRSBINDIR)/apxs \ --enable-cli \ --with-config-file-path=/etc \ --with-libxml-dir=$(USRDIR) \ --with-openssl=$(USRDIR) \ --with-kerberos=$(USRDIR) \ --with-zlib=$(USRDIR) \ --enable-bcmath \ --with-bz2=$(USRDIR) \ --enable-calendar \ --with-curl=$(USRDIR) \ --enable-exif \ --enable-ftp \ --with-gd \ --with-freetype-dir=$(DSTROOT)$(USRDIR)/local \ --with-jpeg-dir=$(DSTROOT)$(USRDIR)/local \ --with-png-dir=$(DSTROOT)$(USRDIR)/local \ --enable-gd-native-ttf \ --with-ldap=$(USRDIR) \ --with-ldap-sasl=$(USRDIR) \ --enable-mbstring \ --enable-mbregex \ --with-mysql=mysqlnd \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ --with-mysql-sock=/var/mysql/mysql.sock \ --with-iodbc=$(USRDIR) \ --enable-shmop \ --with-snmp=$(USRDIR) \ --enable-soap \ --enable-sockets \ --enable-suhosin \ --enable-sysvmsg --enable-sysvsem --enable-sysvshm \ --with-xmlrpc \ --with-iconv-dir=$(USRDIR) \ --with-xsl=$(USRDIR) \ --enable-zend-multibyte \ --enable-zip -- It may be relevant that I have applied the Suhosin patch to the sources. I will inspect the patch to see if it's modifying the crashing code in some way. In addition, I set CFLAGS="-Os -g -fstack-protector-all" before calling configure. I will build again and see if I can tease out more information. [2010-10-13 12:33:21] and...@php.net Again, no crash and...@vihren:~/dev/php5.3-201010130830> $ ./php a.php mysql version: 5.1.44 and...@vihren:~/dev/php5.3-201010130830> $ cat config.nice #! /bin/sh # # Created by configure CC='/usr/bin/llvm-gcc' \ './configure' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--disable-libxml' \ '--disable-dom' \ '--disable-simplexml' \ '--disable-xml' \ '--disable-xmlreader' \ '--disable-xmlwriter' \ '--without-pear' \ "$@" and...@vihren:~/dev/php5.3-201010130830> $ uname -a Darwin vihren 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 The system is a MacOS X 10.6.something [2010-10-07 04:33:41] php at group dot a
Bug #53199 [Com]: Phar doesn't work with '--enable-zend-multibyte' option
Edit report at http://bugs.php.net/bug.php?id=53199&edit=1
ID: 53199
Comment by: php at group dot apple dot com
Reported by:brt dot river at gmail dot com
Summary:Phar doesn't work with '--enable-zend-multibyte'
option
Status: Feedback
Type: Bug
Package:PHAR related
Operating System: Mac OS X 10.6
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
The patch contained a logic flaw (compared against ptr and not size), so
I
reworked it to match the style of the other if-blocks in the function
and have
attached it as "phar.patch".
The patch file also contains a fix for Makefile.frag which removes
$(INSTALL_ROOT)
from the bang command path since INSTALL_ROOT is the mastering location,
not the
deployment location.
Previous Comments:
[2010-11-18 09:51:05] cataphr...@php.net
If it does indeed resolve the issue, this should be marked as duplicate
of bug #42396.
[2010-11-18 08:48:19] cataphr...@php.net
Can you please see if the attached patch resolves the issue?
Thanks.
[2010-11-18 08:47:39] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug53199.patch
Revision: 1290066459
URL:
http://bugs.php.net/patch-display.php?bug=53199&patch=bug53199.patch&revision=1290066459
------------
[2010-11-18 07:02:28] php at group dot apple dot com
I have been debugging a similar report with the phar CLI. Executing "php
phar.php"
(using the generated php/ext/phar/phar.php) works properly, but the
resulting
phar.phar does not. I have tried modifying the stub (via phar.php) to
print
debugging information but that only produces more "?" characters.
Attempting to
debug with Xdebug and MacGDBp wouldn't step through the first line
before
terminating.
[2010-10-29 10:22:36] brt dot river at gmail dot com
Description:
I'm using PHP 5.3.3 with '--enable-zend-multibyte' under Mac OS X.
My script calls my phar archive directly, The result characters are
garbled.
Test script:
---
* create.php
setStub('http://bugs.php.net/bug.php?id=53199&edit=1
Req #42396 [Com]: Followup to #36711: __halt_compiler() and unicode detection
Edit report at http://bugs.php.net/bug.php?id=42396&edit=1 ID: 42396 Comment by: php at group dot apple dot com Reported by:francois at tekwire dot net Summary:Followup to #36711: __halt_compiler() and unicode detection Status: Closed Type: Feature/Change Request Package:*General Issues Operating System: all PHP Version:5.2.3 Assigned To:hirokawa Block user comment: N Private report: N New Comment: Please see the related bug: http://bugs.php.net/bug.php?id=53199 The original patch contained a flaw. Previous Comments: [2010-11-24 07:09:51] dmi...@php.net It's fixed only in trunk. [2010-11-24 07:09:21] dmi...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-11-18 09:50:07] cataphr...@php.net This bug describes more accurately the problem I attempted to solve with the patch for bug #53199. [2010-06-25 10:11:56] phofstetter at sensational dot ch somehow, recently, the default value of detect_unicode seems to have changed. With detect_unicode enabled, it's impossible to run any PHAR-file - neither through the CLI or through the web server. IMHO, this should really be looked into. [2007-08-27 08:38:58] j...@php.net IMHO, #42396 is not a bug, but it is the specification. The normal script doesn't contain a null byte if it is not encoded in Unicode. It is understandable the addition of a unique byte seqence '0x' detection to support PHAR/PHK, but it is a change to add a new feature. Rui The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=42396 -- Edit this bug report at http://bugs.php.net/bug.php?id=42396&edit=1
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: php at group dot apple dot com Reported by:mbecc...@php.net Summary:Segmentation fault in mysql_fetch_array Status: Feedback Type: Bug Package:MySQL related Operating System: FreeBSD 6.2 PHP Version:5.3.2 Assigned To:mysql Block user comment: N Private report: N New Comment: The multi-architecture problem, while valid and now correct, did not address the crash. I continue to investigate. Previous Comments: [2010-11-18 08:27:53] php at group dot apple dot com I think I may have discovered the culprit: mistaken architecture information! Here are sample runs using different architectures: # arch -i386 /usr/bin/php /build/mysql_fetch_array_8264855.php mysql version: 5.0.91-log # arch -x86_64 /usr/bin/php /build/mysql_fetch_array_8264855.php zsh: segmentation fault arch -x86_64 /usr/bin/php /build/mysql_fetch_array_8264855.php Mac OS X builds "fat", i.e. multiple-architectures in a single compilation pass by passing "-arch i386 -arch x86_64". The system headers properly handle the data size differences, but projects which depend upon configure's evaluation of data sizes instead of system headers such as are often bit by this. The problem is exacerbated by configure's test to determine if it is cross-compiling; since Mac OS X can build and run both i386 and x86_64, configure ignores the cross-compilation directive and determines the results from the runtime. I will post more once I get a feeling for how pervasive the changes may be. [2010-10-27 16:11:47] johizzle at gmail dot com I found that recompiling it with --enable-debug fixed the issue of the mysql_fetch_array($var,MYSQL_ASSOC); causing a segmentation fault(11). It's also good to note, that I installed mysql-client-community rpm, as well. RHEL 4.8 Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.7a PHP/5.3.3 ------------ [2010-10-15 00:57:38] php at group dot apple dot com Here are the configure flags I use: -- --with-apxs2=$(USRSBINDIR)/apxs \ --enable-cli \ --with-config-file-path=/etc \ --with-libxml-dir=$(USRDIR) \ --with-openssl=$(USRDIR) \ --with-kerberos=$(USRDIR) \ --with-zlib=$(USRDIR) \ --enable-bcmath \ --with-bz2=$(USRDIR) \ --enable-calendar \ --with-curl=$(USRDIR) \ --enable-exif \ --enable-ftp \ --with-gd \ --with-freetype-dir=$(DSTROOT)$(USRDIR)/local \ --with-jpeg-dir=$(DSTROOT)$(USRDIR)/local \ --with-png-dir=$(DSTROOT)$(USRDIR)/local \ --enable-gd-native-ttf \ --with-ldap=$(USRDIR) \ --with-ldap-sasl=$(USRDIR) \ --enable-mbstring \ --enable-mbregex \ --with-mysql=mysqlnd \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ --with-mysql-sock=/var/mysql/mysql.sock \ --with-iodbc=$(USRDIR) \ --enable-shmop \ --with-snmp=$(USRDIR) \ --enable-soap \ --enable-sockets \ --enable-suhosin \ --enable-sysvmsg --enable-sysvsem --enable-sysvshm \ --with-xmlrpc \ --with-iconv-dir=$(USRDIR) \ --with-xsl=$(USRDIR) \ --enable-zend-multibyte \ --enable-zip -- It may be relevant that I have applied the Suhosin patch to the sources. I will inspect the patch to see if it's modifying the crashing code in some way. In addition, I set CFLAGS="-Os -g -fstack-protector-all" before calling configure. I will build again and see if I can tease out more information. [2010-10-13 12:33:21] and...@php.net Again, no crash and...@vihren:~/dev/php5.3-201010130830> $ ./php a.php mysql version: 5.1.44 and...@vihren:~/dev/php5.3-201010130830> $ cat config.nice #! /bin/sh # # Created by configure CC='/usr/bin/llvm-gcc' \ './configure' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--disable-libxml' \ '--disable-dom' \ '--disable-simplexml' \ '--disable-xml' \ '--disable-xmlreader' \ '--disable-xmlwriter' \ '--without-pear' \ "$@" and...@vihren:~/dev/php5.3-201010
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: php at group dot apple dot com Reported by:mbecc...@php.net Summary:Segmentation fault in mysql_fetch_array Status: Feedback Type: Bug Package:MySQL related Operating System: FreeBSD 6.2 PHP Version:5.3.2 Assigned To:mysql Block user comment: N Private report: N New Comment: I found the problem and have created two patch files. One (arches.patch) addresses the broader architectural problems of multi-architecture builds. The second (php_mysql_fetch_hash.patch) addresses the flaw which causes this crash, namely that a long is written to an int. Previous Comments: [2010-11-30 06:38:01] php at group dot apple dot com The multi-architecture problem, while valid and now correct, did not address the crash. I continue to investigate. [2010-11-18 08:27:53] php at group dot apple dot com I think I may have discovered the culprit: mistaken architecture information! Here are sample runs using different architectures: # arch -i386 /usr/bin/php /build/mysql_fetch_array_8264855.php mysql version: 5.0.91-log # arch -x86_64 /usr/bin/php /build/mysql_fetch_array_8264855.php zsh: segmentation fault arch -x86_64 /usr/bin/php /build/mysql_fetch_array_8264855.php Mac OS X builds "fat", i.e. multiple-architectures in a single compilation pass by passing "-arch i386 -arch x86_64". The system headers properly handle the data size differences, but projects which depend upon configure's evaluation of data sizes instead of system headers such as are often bit by this. The problem is exacerbated by configure's test to determine if it is cross-compiling; since Mac OS X can build and run both i386 and x86_64, configure ignores the cross-compilation directive and determines the results from the runtime. I will post more once I get a feeling for how pervasive the changes may be. [2010-10-27 16:11:47] johizzle at gmail dot com I found that recompiling it with --enable-debug fixed the issue of the mysql_fetch_array($var,MYSQL_ASSOC); causing a segmentation fault(11). It's also good to note, that I installed mysql-client-community rpm, as well. RHEL 4.8 Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.7a PHP/5.3.3 ------------ [2010-10-15 00:57:38] php at group dot apple dot com Here are the configure flags I use: -- --with-apxs2=$(USRSBINDIR)/apxs \ --enable-cli \ --with-config-file-path=/etc \ --with-libxml-dir=$(USRDIR) \ --with-openssl=$(USRDIR) \ --with-kerberos=$(USRDIR) \ --with-zlib=$(USRDIR) \ --enable-bcmath \ --with-bz2=$(USRDIR) \ --enable-calendar \ --with-curl=$(USRDIR) \ --enable-exif \ --enable-ftp \ --with-gd \ --with-freetype-dir=$(DSTROOT)$(USRDIR)/local \ --with-jpeg-dir=$(DSTROOT)$(USRDIR)/local \ --with-png-dir=$(DSTROOT)$(USRDIR)/local \ --enable-gd-native-ttf \ --with-ldap=$(USRDIR) \ --with-ldap-sasl=$(USRDIR) \ --enable-mbstring \ --enable-mbregex \ --with-mysql=mysqlnd \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ --with-mysql-sock=/var/mysql/mysql.sock \ --with-iodbc=$(USRDIR) \ --enable-shmop \ --with-snmp=$(USRDIR) \ --enable-soap \ --enable-sockets \ --enable-suhosin \ --enable-sysvmsg --enable-sysvsem --enable-sysvshm \ --with-xmlrpc \ --with-iconv-dir=$(USRDIR) \ --with-xsl=$(USRDIR) \ --enable-zend-multibyte \ --enable-zip -- It may be relevant that I have applied the Suhosin patch to the sources. I will inspect the patch to see if it's modifying the crashing code in some way. In addition, I set CFLAGS="-Os -g -fstack-protector-all" before calling configure. I will build again and see if I can tease out more information. [2010-10-13 12:33:21] and...@php.net Again, no crash and...@vihren:~/dev/php5.3-201010130830> $ ./php a.php mysql version: 5.1.44 and...@vihren:~/dev/php5.3-201010130830> $ cat config.nice #! /bin/sh # # Created by configure CC='/usr/bin/llvm-gcc' \ './configure
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: php at group dot apple dot com Reported by:mbecc...@php.net Summary:Segmentation fault in mysql_fetch_array Status: Feedback Type: Bug Package:MySQL related Operating System: FreeBSD 6.2 PHP Version:5.3.2 Assigned To:mysql Block user comment: N Private report: N New Comment: The second patch is the same patch applied for http://bugs.php.net/bug.php? id=52636, which is included with 5.3.4RC1. The first patch does not appear to be in the source tree yet. Previous Comments: [2010-12-02 03:54:35] php at group dot apple dot com I found the problem and have created two patch files. One (arches.patch) addresses the broader architectural problems of multi-architecture builds. The second (php_mysql_fetch_hash.patch) addresses the flaw which causes this crash, namely that a long is written to an int. [2010-11-30 06:38:01] php at group dot apple dot com The multi-architecture problem, while valid and now correct, did not address the crash. I continue to investigate. [2010-11-18 08:27:53] php at group dot apple dot com I think I may have discovered the culprit: mistaken architecture information! Here are sample runs using different architectures: # arch -i386 /usr/bin/php /build/mysql_fetch_array_8264855.php mysql version: 5.0.91-log # arch -x86_64 /usr/bin/php /build/mysql_fetch_array_8264855.php zsh: segmentation fault arch -x86_64 /usr/bin/php /build/mysql_fetch_array_8264855.php Mac OS X builds "fat", i.e. multiple-architectures in a single compilation pass by passing "-arch i386 -arch x86_64". The system headers properly handle the data size differences, but projects which depend upon configure's evaluation of data sizes instead of system headers such as are often bit by this. The problem is exacerbated by configure's test to determine if it is cross-compiling; since Mac OS X can build and run both i386 and x86_64, configure ignores the cross-compilation directive and determines the results from the runtime. I will post more once I get a feeling for how pervasive the changes may be. [2010-10-27 16:11:47] johizzle at gmail dot com I found that recompiling it with --enable-debug fixed the issue of the mysql_fetch_array($var,MYSQL_ASSOC); causing a segmentation fault(11). It's also good to note, that I installed mysql-client-community rpm, as well. RHEL 4.8 Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.7a PHP/5.3.3 ------------ [2010-10-15 00:57:38] php at group dot apple dot com Here are the configure flags I use: -- --with-apxs2=$(USRSBINDIR)/apxs \ --enable-cli \ --with-config-file-path=/etc \ --with-libxml-dir=$(USRDIR) \ --with-openssl=$(USRDIR) \ --with-kerberos=$(USRDIR) \ --with-zlib=$(USRDIR) \ --enable-bcmath \ --with-bz2=$(USRDIR) \ --enable-calendar \ --with-curl=$(USRDIR) \ --enable-exif \ --enable-ftp \ --with-gd \ --with-freetype-dir=$(DSTROOT)$(USRDIR)/local \ --with-jpeg-dir=$(DSTROOT)$(USRDIR)/local \ --with-png-dir=$(DSTROOT)$(USRDIR)/local \ --enable-gd-native-ttf \ --with-ldap=$(USRDIR) \ --with-ldap-sasl=$(USRDIR) \ --enable-mbstring \ --enable-mbregex \ --with-mysql=mysqlnd \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ --with-mysql-sock=/var/mysql/mysql.sock \ --with-iodbc=$(USRDIR) \ --enable-shmop \ --with-snmp=$(USRDIR) \ --enable-soap \ --enable-sockets \ --enable-suhosin \ --enable-sysvmsg --enable-sysvsem --enable-sysvshm \ --with-xmlrpc \ --with-iconv-dir=$(USRDIR) \ --with-xsl=$(USRDIR) \ --enable-zend-multibyte \ --enable-zip -- It may be relevant that I have applied the Suhosin patch to the sources. I will inspect the patch to see if it's modifying the crashing code in some way. In addition, I set CFLAGS="-Os -g -fstack-protector-all" before calling configure. I will build again and see if I can tease out more information. --
