#47197 [Opn->Csd]: Configuration option --with-mysql-sock is ignored
ID: 47197 User updated by: coreync at gmail dot com Reported By: coreync at gmail dot com -Status: Open +Status: Closed Bug Type: MySQL related Operating System: Centos 5.2 PHP Version: 5.2.8 New Comment: The link to the php info is no longer relevant to this bug (I recompiled mysql to point to the same location as my php configuration). Closing. Previous Comments: [2009-01-23 10:58:44] coreync at gmail dot com Description: As seen in this phpinfo file: http://friendcodes.com/info.php When using --with-mysql-sock=/var/lib/mysql/mysql.sock as a configure tag, php still uses the server's mysql default socket location (scroll down to mysql section in the phpinfo). Expected result: I expected php to pass the socket location entered during configure to the mysql client. Actual result: -- Did not pass the socket location to the mysql client. Resolved by creating a symbolic link. -- Edit this bug report at http://bugs.php.net/?id=47197&edit=1
#47221 [Opn->Fbk]: no result from array_diff()
ID: 47221 Updated by: j...@php.net Reported By: sgnutzmann at yahoo dot de -Status: Open +Status: Feedback -Bug Type: Performance problem +Bug Type: Arrays related Operating System: Windows XP PHP Version: 5.2.8 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2009-01-26 17:58:51] sgnutzmann at yahoo dot de Description: I use the function array_diff() to compare two sorted string-arrays with numerical keys (array sizes are 76,906 and 433,959, string sizes in all array elements less than 20 characters). With PHP 5.2.4 the function returns very fast (just few seconds), with PHP 5.2.8 I kill PHP.exe after 30 minutes(!) without result. PHP.INI: memory_limit = 1536M extension=php_pdo.dll extension=php_zip.dll extension=php_pdo_odbc.dll Reproduce code: --- // $Sales and $Inv read previously from file system $idSales = array(); foreach ( $Sales as $i => $data ) $idSales[$i] = '#'.$data[2]; array_multisort ($idSales, $Sales); $idInv = array(); foreach ( $Inv as $i => $data ) $idInv[$i] = '#'.$data[1]; array_multisort ($idInv, $Inv); echo "Start array_diff\n"; $unknown = array_diff ( $idSales, $idInv ); echo "End array_diff\n"; Expected result: see description Actual result: -- no result in 30 minutes -- Edit this bug report at http://bugs.php.net/?id=47221&edit=1
#45546 [Com]: PCRE with utf8 kill apache childprocess
ID: 45546 Comment by: jdw at wheelhouse dot org Reported By: kaiser at macbureau dot de Status: No Feedback Bug Type: PCRE related Operating System: FreeBSD 7 PHP Version: 5.2.6 New Comment: We are also having this problem on FreeBSD 7 with Apache 1.3. The stack trace is the same: #0 0x286dcbc7 in match () from /usr/local/lib/libpcre.so.0 #1 0x286e3aba in match () from /usr/local/lib/libpcre.so.0 #2 0x286e3aba in match () from /usr/local/lib/libpcre.so.0 #3 0x286e469e in match () from /usr/local/lib/libpcre.so.0 #4 0x286dd629 in match () from /usr/local/lib/libpcre.so.0 #5 0x286e76c4 in pcre_exec () from /usr/local/lib/libpcre.so.0 #6 0x284b72fe in php_pcre_match_impl () from /nfsn/apps/apache/libexec/libphp5.so #7 0x284b7cac in php_do_pcre_match () from /nfsn/apps/apache/libexec/libphp5.so #8 0x285db1a8 in zend_do_fcall_common_helper_SPEC () from /nfsn/apps/apache/libexec/libphp5.so #9 0x285cca7f in execute () from /nfsn/apps/apache/libexec/libphp5.so #10 0x28b2f0c2 in _su3jdmx () from /nfsn/apps/php5/lib/php/extensions/no-debug-non-zts- 20060613/ioncube_loader_fre_5.2.so #11 0x2af863d8 in ?? () #12 0x29e80750 in ?? () #13 0x29e7f75c in ?? () #14 0x285dac0e in zend_do_fcall_common_helper_SPEC () from /nfsn/apps/apache/libexec/libphp5.so (This version was built with the FreeBSD PCRE instead of the builtin in case that helped; it didn't.) In one case, a customer has to set pcre.backtrack_limit and pcre.recursion_limit to 10 to get a Wordpress RSS feed to load. Are those considered "sane" values? Or is this getting ignored due to the incorrect "No Feedback" status? Previous Comments: [2009-01-14 13:00:22] jdc at parodius dot com I've built PHP 5.2.8 with debugging enabled, and ran the following script under PHP via the CLI, under gdb: It's important to note that if I change the str_repeat() length from 1244 to 1243, the segfault doesn't happen. The system limits: Resource limits (current): cputime infinity secs filesize infinity kB datasize 786432 kB stacksize 131072 kB coredumpsize infinity kB memoryuseinfinity kB memorylocked infinity kB maxprocesses 5547 openfiles 11095 sbsize infinity bytes vmemoryuse infinity kB Anyway, the results of the gdb backtrace are here (~790KB file): http://www.malkavian.com/~jdc/php.bug45546.backtrace.txt Hope this helps. [2009-01-14 12:27:59] jdc at parodius dot com This bug still exists in PHP 5.2.8, which uses its own bundled version of pcre. FreeBSD 7.1-STABLE is being used here. I have a customer who is experiencing this problem on a near-daily basis (logs showing httpd SIGILL regularly). I can induce a signal 11 from the shell (using PHP CLI) executing the code provided by "hempalex at gmail dot com" as well as the code provided by "kaiser at macbureau dot de". The comment from "ale at FreeBSD.org" also applies -- the value given to str_repeat() does in fact play a role. But when run from within Apache (2.2.11 using mod_php), signal 4 (illegal instruction) happens. I'm not sure why from within Apache it's SIGILL but from the command-line it's SIGSEGV. Increasing pcre.backtrack_limit and pcre.recursion_limit does not help. Decreasing them also does not help. I'd like to urge the PHP folks to take this problem seriously. There are many of us using FreeBSD who would be more than happy to give you an account on a development/test system for you to work out the source of this problem. [2008-09-26 16:17:20] nlop...@php.net again I cannot reproduce this problem. Try to adjust pcre.backtrack_limit and pcre.recursion_limit to some sane values. [2008-09-26 09:17:06] ale at FreeBSD dot org The feedback was provided. In any case the above script works if the string length is <= 2243 and stops working if > 2243 'a' chars. [2008-07-27 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". 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/45546 -- Edit this bug report at http://bugs.php.net/?id=45546&edit=1
#38111 [Com]: PHP crashes IIS worker process and application pool
ID: 38111 Comment by: tser at deltacontrols dot com Reported By: svendavidh at hotmail dot com Status: No Feedback Bug Type: IIS related Operating System: Windows Server 2003 Std. Ed. R2 PHP Version: 5.2.8 Assigned To: pajoye New Comment: PHP 5.2.8 (with no extension) ISAPI on IIS7 Vista 64 (using a 32 Application Pool) Just run phpinfo(); and the recycle the Application Pool Backtrace ntdll.dll!_dbgbreakpo...@0() ntdll.dll!_rtlreportcriticalfail...@8() + 0x2e bytes ntdll.dll!_rtlpreportheapfail...@4() + 0x21 bytes ntdll.dll!_rtlplogheapfail...@24() + 0xab bytes ntdll.dll!_rtlfreeh...@12() + 0x2fb4e bytes kernel32.dll!_heapf...@12() + 0x14 bytes msvcrt.dll!_free() + 0x39 bytes php5ts.dll!zend_hash_graceful_reverse_destroy(_hashtable * ht=0x00c68428) Line 650 + 0x11 bytes php5ts.dll!zend_destroy_rsrc_list(_hashtable * ht=0x00c68428, void * * * tsrm_ls=0x024906d8) Line 239 + 0xa bytes php5ts.dll!executor_globals_dtor(_zend_executor_globals * executor_globals=0x00c68298, void * * * tsrm_ls=0x024906d8) Line 525 + 0x7 bytes php5ts.dll!tsrm_shutdown() Line 180 + 0x4 bytesC php5isapi.dll!DllMain(HINSTANCE__ * hinstDLL=0x0019, unsigned long fdwReason=0, void * lpvReserved=0x) Line 964 php5isapi.dll!__dllmaincrtstar...@12() + 0x50 bytes ntdll.dll!_ldrpcallinitrout...@16() + 0x14 bytes ntdll.dll!_ldrpunload...@8() + 0x4b1a bytes ntdll.dll!_ldrunload...@4() + 0x46 bytes kernel32.dll!_freelibr...@4() + 0x19 bytes isapi.dll!ISAPI_DLL::Unload() + 0x38 bytes isapi.dll!ISAPI_DLL::~ISAPI_DLL() + 0x10 bytes isapi.dll!ISAPI_DLL::`scalar deleting destructor'() + 0xd bytes isapi.dll!ISAPI_DLL::DereferenceIsapiDll() + 0x37 bytes isapi.dll!ISAPI_DLL_HASH::AddRefRecord() + 0x23 bytes iisutil.dll!CLKRLinearHashTable::_Clear() + 0x6f bytes iisutil.dll!CLKRLinearHashTable::~CLKRLinearHashTable() + 0x19 bytes iisutil.dll!CLKRLinearHashTable::`scalar deleting destructor'() + 0xd bytes iisutil.dll!CLKRHashTable::_FreeSubTable() + 0x13 bytes iisutil.dll!CLKRHashTable::~CLKRHashTable() + 0x18 bytes isapi.dll!ISAPI_DLL_MANAGER::`scalar deleting destructor'() + 0xe bytes isapi.dll!TerminateIsapiModule() + 0x16 bytes isapi.dll!CIISModuleFactory::Terminate() + 0x14 bytes iiscore.dll!VIRTUAL_MODULE::~VIRTUAL_MODULE() + 0x3e bytes iiscore.dll!VIRTUAL_MODULE::`scalar deleting destructor'() + 0xd bytes iiscore.dll!VIRTUAL_MODULE::DereferenceVirtualModule() + 0x20 bytes iiscore.dll!MODULE_LIST::FreeModules() + 0x21 bytes iiscore.dll!W3_SERVER::TerminateGlobalModules() + 0x63 bytes iiscore.dll!W3_SERVER::Terminate() + 0x157 bytes iiscore.dll!IISCORE_PROTOCOL_MANAGER::StopListenerChannel() + 0x58 bytes w3wphost.dll!LISTENER_CHANNEL::HandleStopListenerChannel() + 0x65 bytes w3wphost.dll!LISTENER_CHANNEL_STOP_WORKITEM::ExecuteWorkItem() + 0x10 bytes w3wphost.dll!W3WP_HOST::ExecuteWorkItem() + 0x10 bytes ntdll.dll!_rtlptpworkcallb...@8() - 0x2c9 bytes ntdll.dll!_tppworkerthr...@4() - 0xbbc bytes kernel32.d...@basethreadinitthunk@12() + 0xe bytes ntdll.dll!___rtluserthreadst...@8() + 0x23 bytes ntdll.dll!__rtluserthreadst...@8() + 0x1b bytes Previous Comments: [2009-01-12 00:08:04] paj...@php.net "- Use FastCGI rather than ISAPI" that's definitively the way to go :) [2009-01-11 23:44:21] scott at datalink dot com dot au To help people with this issue, I've scanned all the PHP bugs relating to this issue and collated a list of workarounds: - Add w3wp.exe to DEP exclusion list - Turn off process recycling - Use FastCGI rather than ISAPI To the PHP team - you guys are great and I love your work. I know you haven't gotten the backtrace, but please don't mark this bug as bogus. The community is trying to get what you need and have been very patient with this issue, but it appears to be difficult to get because of the way it crashes. [2009-01-09 22:17:18] damon at clarkweb dot com Same problems with PHP 5.2.8 on Vista SP1. Following SIKLE's steps reproduces the bug every time. This has been open far too long for an easily reproducable bug. Please address! [2009-01-04 10:46:52]
#47194 [Asn]: documentation workflow change
ID: 47194 Updated by: cwei...@php.net Reported By: samm...@php.net Status: Assigned Bug Type:Feature/Change Request PHP Version: 5.2.8 Assigned To: cweiske New Comment: http://tmp.cweiske.de/phpdoc-broken-files.diff Previous Comments: [2009-01-22 21:31:39] samm...@php.net Description: Translations can among others have the status "working". A file can have the status "working" for one of two reasons: 1. The file is outdated and needs revision. 2. A translator is currently working on this file, but the work is not yet completed. In any case this file is clearly not ready to be published and should not be included in a full build for the manual in this language. Omitting files with status "working" from the build will also considerably speed up the build process. To manage these files and coordinate translation efforts, a list of files with status "working" needs to be created before the manual build. Also, during this preprocessing phase files that are outdated need to be identified and set to status working. A file is outdated when 1. its version number is different from the version number of its corrosponding en version number AND 2. the file has not been touched for more than days. will be defined for each language in a separate file and is dependent on the policy of the translation team for that language. The following changes to the build process are requested: 1. Check for files that are outdated and set the status flag for outdated files to "working". 2. Generate a list of files (ascii, one full pathname per line) that have the status "working". 3. Change the build to omit files with status "working", maybe using the file from step 2 as an exclude list. -- Edit this bug report at http://bugs.php.net/?id=47194&edit=1
#47220 [Opn->Csd]: segfault in dom_document_parser in recovery mode
ID: 47220
Updated by: rricha...@php.net
Reported By: felix-php at 7val dot com
-Status: Open
+Status: Closed
Bug Type: DOM XML related
Operating System: Debian Linux
PHP Version: 5.2.8
New Comment:
This bug has been fixed in CVS.
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.
Previous Comments:
[2009-01-26 16:54:42] felix-php at 7val dot com
Description:
A call to DOMDocument::load() or ::loadXML() in recovery mode leads to
segmentation fault in dom_document_parser) when the XML declaration
contains an unknown (and unrecoverable) encoding.
The segfault occurs in document.c +1690 when trying to access
properties of the result document (ret), which is NULL in this case:
if (ret->URL == NULL && ctxt->directory != NULL) {
Reproduce code:
---
';
$dom = new DOMDocument;
$dom->recover = true;
$dom->loadXML($xml);
echo $dom->saveXML();
Expected result:
Actual result:
--
Segmentation Fault
--
Edit this bug report at http://bugs.php.net/?id=47220&edit=1
#47221 [NEW]: no result from array_diff()
From: sgnutzmann at yahoo dot de Operating system: Windows XP PHP version: 5.2.8 PHP Bug Type: Performance problem Bug description: no result from array_diff() Description: I use the function array_diff() to compare two sorted string-arrays with numerical keys (array sizes are 76,906 and 433,959, string sizes in all array elements less than 20 characters). With PHP 5.2.4 the function returns very fast (just few seconds), with PHP 5.2.8 I kill PHP.exe after 30 minutes(!) without result. PHP.INI: memory_limit = 1536M extension=php_pdo.dll extension=php_zip.dll extension=php_pdo_odbc.dll Reproduce code: --- // $Sales and $Inv read previously from file system $idSales = array(); foreach ( $Sales as $i => $data ) $idSales[$i] = '#'.$data[2]; array_multisort ($idSales, $Sales); $idInv = array(); foreach ( $Inv as $i => $data ) $idInv[$i] = '#'.$data[1]; array_multisort ($idInv, $Inv); echo "Start array_diff\n"; $unknown = array_diff ( $idSales, $idInv ); echo "End array_diff\n"; Expected result: see description Actual result: -- no result in 30 minutes -- Edit bug report at http://bugs.php.net/?id=47221&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47221&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47221&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47221&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47221&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47221&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47221&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47221&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47221&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47221&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47221&r=support Expected behavior: http://bugs.php.net/fix.php?id=47221&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47221&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47221&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47221&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47221&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47221&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47221&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47221&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47221&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47221&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47221&r=mysqlcfg
#47220 [NEW]: segfault in dom_document_parser in recovery mode
From: felix-php at 7val dot com
Operating system: Debian Linux
PHP version: 5.2.8
PHP Bug Type: DOM XML related
Bug description: segfault in dom_document_parser in recovery mode
Description:
A call to DOMDocument::load() or ::loadXML() in recovery mode leads to
segmentation fault in dom_document_parser) when the XML declaration
contains an unknown (and unrecoverable) encoding.
The segfault occurs in document.c +1690 when trying to access properties
of the result document (ret), which is NULL in this case:
if (ret->URL == NULL && ctxt->directory != NULL) {
Reproduce code:
---
';
$dom = new DOMDocument;
$dom->recover = true;
$dom->loadXML($xml);
echo $dom->saveXML();
Expected result:
Actual result:
--
Segmentation Fault
--
Edit bug report at http://bugs.php.net/?id=47220&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47220&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47220&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47220&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47220&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47220&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47220&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47220&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47220&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47220&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47220&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47220&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47220&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47220&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47220&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47220&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47220&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47220&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47220&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47220&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47220&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47220&r=mysqlcfg
#47043 [Opn->WFx]: Compilation fails on Ming library
ID: 47043 Updated by: j...@php.net Reported By: john at jcoppens dot com -Status: Open +Status: Wont fix Bug Type: Ming related Operating System: Linux 386 PHP Version: 5.2CVS-2009-01-08 (snap) New Comment: As suggested by the "EXPERIMENTAL" status, this is truly experimental extension since it doesn't even compile. Apparently libming is also pretty much experimental since they chose to break BC between their 0.4.x release and 0.3a which is the version PHP 5.2.x compiles fine with. You should use the extension that is bundled with the current libming version. Also note that ext/ming will be moved to PECL in PHP 5.3.0. (and apparently abandoned..) Previous Comments: [2009-01-26 15:34:39] john at jcoppens dot com Yes, I had the same errors. The errors were the motive to install 0.4, hoping 0.4 would resolve the undefined references. John [2009-01-26 15:17:11] j...@php.net So did you get the errors with 0.3a and PHP 5.2.8 or not? Please be specific which versions of which did or did not work. Now it's not quite clear.. [2009-01-26 13:32:40] john at jcoppens dot com > What's this: --with-config-file-path=\etc\apache ??? You really have > such path? (hint: forward slashes..) Evidently a typo. Just in case that was the cause, I retried with the right slashes. No change. I first had Ming 0.3 installed, and was able to compile (at that time - last year) php 5.2.5 with Ming included. Now I got the list of undefined references, so I installed Ming 0.4. (ming-0.4.0.rc1). I compiled and installed 0.4 with: ./configure --enable-php --enable-cpp --enable-perl --enable-perl so it installed in /usr/local [2009-01-26 12:47:50] j...@php.net What's this: --with-config-file-path=\etc\apache ??? You really have such path? (hint: forward slashes..) And what ming library version have you installed? And how? [2009-01-08 21:38:20] john at jcoppens dot com Description: Compiling PHP with the following configuration: ./configure --with-mysql=/opt/mysql -with-mysqli --with-msql=/usr/local/msql \ --with-apxs \ --with-ming --with-zlib --with-bz2 --enable-exif --enable-ftp \ --with-gd --enable-gd-native-ttf --with-ttf=/usr --enable-dbase \ --with-freetype-dir=/usr --enable-sockets --with-t1lib \ --prefix=/usr --enable-mbstring --with-libxml-dir=/usr --with-pspell \ --with-config-file-path=\etc\apache causes a lot of undefined references, apparently all related to the ming libraries. Reproduce code: --- configure with the above options, make Expected result: Normal compilation Actual result: -- After a very long gcc command, probably near the end: ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getRot': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1196: undefined reference to `SWFDisplayItem_get_rot' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getYSkew': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1181: undefined reference to `SWFDisplayItem_get_ySkew' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getXSkew': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1166: undefined reference to `SWFDisplayItem_get_xSkew' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getYScale': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1151: undefined reference to `SWFDisplayItem_get_yScale' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getXScale': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1136: undefined reference to `SWFDisplayItem_get_xScale' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getY': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1121: undefined reference to `SWFDisplayItem_get_y' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getX': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1106: undefined reference to `SWFDisplayItem_get_x' ext/ming/.libs/ming.o: In function `zim_swffont_getShape': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1609: undefined reference to `SWFFont_getShape' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/?id=47043&edit=1
#47043 [Fbk->Opn]: Compilation fails on Ming library
ID: 47043 User updated by: john at jcoppens dot com Reported By: john at jcoppens dot com -Status: Feedback +Status: Open Bug Type: Ming related Operating System: Linux 386 PHP Version: 5.2CVS-2009-01-08 (snap) New Comment: Yes, I had the same errors. The errors were the motive to install 0.4, hoping 0.4 would resolve the undefined references. John Previous Comments: [2009-01-26 15:17:11] j...@php.net So did you get the errors with 0.3a and PHP 5.2.8 or not? Please be specific which versions of which did or did not work. Now it's not quite clear.. [2009-01-26 13:32:40] john at jcoppens dot com > What's this: --with-config-file-path=\etc\apache ??? You really have > such path? (hint: forward slashes..) Evidently a typo. Just in case that was the cause, I retried with the right slashes. No change. I first had Ming 0.3 installed, and was able to compile (at that time - last year) php 5.2.5 with Ming included. Now I got the list of undefined references, so I installed Ming 0.4. (ming-0.4.0.rc1). I compiled and installed 0.4 with: ./configure --enable-php --enable-cpp --enable-perl --enable-perl so it installed in /usr/local [2009-01-26 12:47:50] j...@php.net What's this: --with-config-file-path=\etc\apache ??? You really have such path? (hint: forward slashes..) And what ming library version have you installed? And how? [2009-01-08 21:38:20] john at jcoppens dot com Description: Compiling PHP with the following configuration: ./configure --with-mysql=/opt/mysql -with-mysqli --with-msql=/usr/local/msql \ --with-apxs \ --with-ming --with-zlib --with-bz2 --enable-exif --enable-ftp \ --with-gd --enable-gd-native-ttf --with-ttf=/usr --enable-dbase \ --with-freetype-dir=/usr --enable-sockets --with-t1lib \ --prefix=/usr --enable-mbstring --with-libxml-dir=/usr --with-pspell \ --with-config-file-path=\etc\apache causes a lot of undefined references, apparently all related to the ming libraries. Reproduce code: --- configure with the above options, make Expected result: Normal compilation Actual result: -- After a very long gcc command, probably near the end: ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getRot': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1196: undefined reference to `SWFDisplayItem_get_rot' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getYSkew': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1181: undefined reference to `SWFDisplayItem_get_ySkew' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getXSkew': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1166: undefined reference to `SWFDisplayItem_get_xSkew' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getYScale': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1151: undefined reference to `SWFDisplayItem_get_yScale' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getXScale': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1136: undefined reference to `SWFDisplayItem_get_xScale' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getY': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1121: undefined reference to `SWFDisplayItem_get_y' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getX': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1106: undefined reference to `SWFDisplayItem_get_x' ext/ming/.libs/ming.o: In function `zim_swffont_getShape': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1609: undefined reference to `SWFFont_getShape' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/?id=47043&edit=1
#47217 [Opn->Csd]: content-type is not set properly
ID: 47217
Updated by: il...@php.net
Reported By: gubp at pisti dot hu
-Status: Open
+Status: Closed
Bug Type: cURL related
Operating System: FreeBSD
PHP Version: 5.2.8
New Comment:
This bug has been fixed in CVS.
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.
Previous Comments:
[2009-01-26 11:19:59] gubp at pisti dot hu
Description:
Using the cURL to send files with custom content-type (eg.:
"@filename;type=content-type") does not work, because undesirable
"type=" string is preprended to the actual content-type.
Reproduce code:
---
test.php:
-
$data = array('file' => '@sheet.xls;type=application/vnd.ms-excel');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://localhost/upload.php');
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
curl_exec($ch);
echo curl_error($ch);
upload.php:
---
print_r($_FILES);
Expected result:
Array
(
[file] => Array
(
[name] => sheet.xls
[type] => application/vnd.ms-excel
[tmp_name] => /var/tmp/php21KVfg
[error] => 0
[size] => 1192
)
)
Actual result:
--
Array
(
[file] => Array
(
[name] => sheet.xls
[type] => type=application/vnd.ms-excel
[tmp_name] => /var/tmp/php21KVfg
[error] => 0
[size] => 1192
)
)
--
Edit this bug report at http://bugs.php.net/?id=47217&edit=1
#47043 [Opn->Fbk]: Compilation fails on Ming library
ID: 47043 Updated by: j...@php.net Reported By: john at jcoppens dot com -Status: Open +Status: Feedback Bug Type: Ming related Operating System: Linux 386 PHP Version: 5.2CVS-2009-01-08 (snap) New Comment: So did you get the errors with 0.3a and PHP 5.2.8 or not? Please be specific which versions of which did or did not work. Now it's not quite clear.. Previous Comments: [2009-01-26 13:32:40] john at jcoppens dot com > What's this: --with-config-file-path=\etc\apache ??? You really have > such path? (hint: forward slashes..) Evidently a typo. Just in case that was the cause, I retried with the right slashes. No change. I first had Ming 0.3 installed, and was able to compile (at that time - last year) php 5.2.5 with Ming included. Now I got the list of undefined references, so I installed Ming 0.4. (ming-0.4.0.rc1). I compiled and installed 0.4 with: ./configure --enable-php --enable-cpp --enable-perl --enable-perl so it installed in /usr/local [2009-01-26 12:47:50] j...@php.net What's this: --with-config-file-path=\etc\apache ??? You really have such path? (hint: forward slashes..) And what ming library version have you installed? And how? [2009-01-08 21:38:20] john at jcoppens dot com Description: Compiling PHP with the following configuration: ./configure --with-mysql=/opt/mysql -with-mysqli --with-msql=/usr/local/msql \ --with-apxs \ --with-ming --with-zlib --with-bz2 --enable-exif --enable-ftp \ --with-gd --enable-gd-native-ttf --with-ttf=/usr --enable-dbase \ --with-freetype-dir=/usr --enable-sockets --with-t1lib \ --prefix=/usr --enable-mbstring --with-libxml-dir=/usr --with-pspell \ --with-config-file-path=\etc\apache causes a lot of undefined references, apparently all related to the ming libraries. Reproduce code: --- configure with the above options, make Expected result: Normal compilation Actual result: -- After a very long gcc command, probably near the end: ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getRot': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1196: undefined reference to `SWFDisplayItem_get_rot' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getYSkew': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1181: undefined reference to `SWFDisplayItem_get_ySkew' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getXSkew': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1166: undefined reference to `SWFDisplayItem_get_xSkew' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getYScale': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1151: undefined reference to `SWFDisplayItem_get_yScale' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getXScale': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1136: undefined reference to `SWFDisplayItem_get_xScale' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getY': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1121: undefined reference to `SWFDisplayItem_get_y' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getX': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1106: undefined reference to `SWFDisplayItem_get_x' ext/ming/.libs/ming.o: In function `zim_swffont_getShape': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1609: undefined reference to `SWFFont_getShape' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/?id=47043&edit=1
#40579 [Com]: $_SERVER['SERVER_PORT'] is invalid during apache redirect
ID: 40579
Comment by: tim at timloram dot me dot uk
Reported By: ruslan dot kyrychuk at gmail dot com
Status: No Feedback
Bug Type: *Web Server problem
Operating System: Windows 2003
PHP Version: 5.2.1
New Comment:
I am experiencing this issue with exact same symptoms. Having used
mod_rewrite to redirect incoming requests to central gateway script,
$_SERVER['SERVER_PORT'] is always reading '80' even if my inital URL was
http://abc.com:86
Any ideas?
Previous Comments:
[2007-03-31 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-03-23 11:10:51] tony2...@php.net
Works just fine here.
["SERVER_PORT"]=> string(4) "8887"
["SCRIPT_NAME"]=> string(11) "/index.html"
[2007-03-23 10:58:01] ruslan dot kyrychuk at gmail dot com
Reproduce code:
---
1. Configure Apache to use port 8080
2. Create .htaccess file:
Options +FollowSymLinks -Indexes
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} (.+)\.html
RewriteRule ^(.+)$ test.php [QSA,L]
3. Create test.php file
Run http://localhost:8080/test.html
Output: 80
Run http://localhost:8080/test.php
Output: 8080
[2007-03-01 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-02-21 14:47:25] tony2...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the 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/40579
--
Edit this bug report at http://bugs.php.net/?id=40579&edit=1
#47043 [Fbk->Opn]: Compilation fails on Ming library
ID: 47043 User updated by: john at jcoppens dot com Reported By: john at jcoppens dot com -Status: Feedback +Status: Open Bug Type: Ming related Operating System: Linux 386 PHP Version: 5.2CVS-2009-01-08 (snap) New Comment: > What's this: --with-config-file-path=\etc\apache ??? You really have > such path? (hint: forward slashes..) Evidently a typo. Just in case that was the cause, I retried with the right slashes. No change. I first had Ming 0.3 installed, and was able to compile (at that time - last year) php 5.2.5 with Ming included. Now I got the list of undefined references, so I installed Ming 0.4. (ming-0.4.0.rc1). I compiled and installed 0.4 with: ./configure --enable-php --enable-cpp --enable-perl --enable-perl so it installed in /usr/local Previous Comments: [2009-01-26 12:47:50] j...@php.net What's this: --with-config-file-path=\etc\apache ??? You really have such path? (hint: forward slashes..) And what ming library version have you installed? And how? [2009-01-08 21:38:20] john at jcoppens dot com Description: Compiling PHP with the following configuration: ./configure --with-mysql=/opt/mysql -with-mysqli --with-msql=/usr/local/msql \ --with-apxs \ --with-ming --with-zlib --with-bz2 --enable-exif --enable-ftp \ --with-gd --enable-gd-native-ttf --with-ttf=/usr --enable-dbase \ --with-freetype-dir=/usr --enable-sockets --with-t1lib \ --prefix=/usr --enable-mbstring --with-libxml-dir=/usr --with-pspell \ --with-config-file-path=\etc\apache causes a lot of undefined references, apparently all related to the ming libraries. Reproduce code: --- configure with the above options, make Expected result: Normal compilation Actual result: -- After a very long gcc command, probably near the end: ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getRot': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1196: undefined reference to `SWFDisplayItem_get_rot' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getYSkew': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1181: undefined reference to `SWFDisplayItem_get_ySkew' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getXSkew': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1166: undefined reference to `SWFDisplayItem_get_xSkew' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getYScale': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1151: undefined reference to `SWFDisplayItem_get_yScale' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getXScale': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1136: undefined reference to `SWFDisplayItem_get_xScale' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getY': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1121: undefined reference to `SWFDisplayItem_get_y' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getX': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1106: undefined reference to `SWFDisplayItem_get_x' ext/ming/.libs/ming.o: In function `zim_swffont_getShape': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1609: undefined reference to `SWFFont_getShape' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/?id=47043&edit=1
#47047 [Com]: _SERVER["REQUEST_MTIME"]
ID: 47047 Comment by: spencer at gmail dot com Reported By: lunter at interia dot pl Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 5.3.0alpha3 New Comment: Good idea! I am all for this. Previous Comments: [2009-01-20 12:08:25] pijon at gmail dot com It will be very useful. Confirm. [2009-01-09 10:33:30] lunter at interia dot pl or better name: _SERVER["REQUEST_UTIME"] [2009-01-09 10:30:19] lunter at interia dot pl Description: _SERVER["REQUEST_MTIME"] New SERVER variable with microtime(true) of request time very useful to calculate page generating time in micro-seconds. -- Edit this bug report at http://bugs.php.net/?id=47047&edit=1
#47043 [Opn->Fbk]: Compilation fails on Ming library
ID: 47043 Updated by: j...@php.net Reported By: john at jcoppens dot com -Status: Open +Status: Feedback -Bug Type: Compile Failure +Bug Type: Ming related Operating System: Linux 386 PHP Version: 5.2CVS-2009-01-08 (snap) New Comment: What's this: --with-config-file-path=\etc\apache ??? You really have such path? (hint: forward slashes..) And what ming library version have you installed? And how? Previous Comments: [2009-01-08 21:38:20] john at jcoppens dot com Description: Compiling PHP with the following configuration: ./configure --with-mysql=/opt/mysql -with-mysqli --with-msql=/usr/local/msql \ --with-apxs \ --with-ming --with-zlib --with-bz2 --enable-exif --enable-ftp \ --with-gd --enable-gd-native-ttf --with-ttf=/usr --enable-dbase \ --with-freetype-dir=/usr --enable-sockets --with-t1lib \ --prefix=/usr --enable-mbstring --with-libxml-dir=/usr --with-pspell \ --with-config-file-path=\etc\apache causes a lot of undefined references, apparently all related to the ming libraries. Reproduce code: --- configure with the above options, make Expected result: Normal compilation Actual result: -- After a very long gcc command, probably near the end: ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getRot': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1196: undefined reference to `SWFDisplayItem_get_rot' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getYSkew': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1181: undefined reference to `SWFDisplayItem_get_ySkew' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getXSkew': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1166: undefined reference to `SWFDisplayItem_get_xSkew' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getYScale': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1151: undefined reference to `SWFDisplayItem_get_yScale' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getXScale': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1136: undefined reference to `SWFDisplayItem_get_xScale' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getY': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1121: undefined reference to `SWFDisplayItem_get_y' ext/ming/.libs/ming.o: In function `zim_swfdisplayitem_getX': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1106: undefined reference to `SWFDisplayItem_get_x' ext/ming/.libs/ming.o: In function `zim_swffont_getShape': /usr/local/src/programming/php-5.2.8/ext/ming/ming.c:1609: undefined reference to `SWFFont_getShape' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/?id=47043&edit=1
#47041 [Opn->Fbk]: 32-bit libnetsnmp.so not found in /usr/sfw/lib/
ID: 47041 Updated by: j...@php.net Reported By: nullpass at gmail dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Solaris 10 SPARC PHP Version: 5.2.8 New Comment: Does this exist: # /usr/sfw/bin/net-snmp-config if it does, is it for the 64 bit installation or 32 bit? You've propable just misconfigured the netsnmp installation if it's for the 64bit one.. Previous Comments: [2009-01-08 19:08:30] nullpass at gmail dot com Description: I am unable to convince PHP to use the 32-bit version of libnetsnmp.so. Compiling PHP with --with-snmp=/usr/sfw to use Sun's distro of net-snmp crle is: crle -c /var/ld/ld.config -l /usr/lib:/lib:/usr/local/lib:/usr/sfw/lib PHP needs to use the 32-bit library in /usr/sfw/lib/libnetsnmp.so (ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped) but instead it is going for the 64-bit library in: /usr/sfw/lib/sparcv9/libnetsnmp.so (ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped) This results in the error: ld: fatal: file /usr/sfw/lib/sparcv9/libnetsnmp.so: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to .libs/libphp5.so collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libphp5.la' -- Edit this bug report at http://bugs.php.net/?id=47041&edit=1
#47192 [Com]: gethostbyname is not interruptible by signals
ID: 47192
Comment by: fmassei at gmail dot com
Reported By: fmassei at gmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: linux
PHP Version: 5.2.8
New Comment:
Quick and dirty workaround: create a child process for resolving the
hostname and let the parent manage the signals.
Previous Comments:
[2009-01-25 16:00:08] fmassei at gmail dot com
well, it actually IS a bug, as long as the "pcntl_" functions are not
working as described for this function only.
[2009-01-24 23:55:06] j...@php.net
No, it's a change request since this function is not designed to do
what you ask. Not everything is a bug..
[2009-01-23 13:52:04] fmassei at gmail dot com
Somehow I posted this bug in the wrong category. It's not a
"Feature/Change Request" but more a "Network related" bug.
[2009-01-22 18:13:35] fmassei at gmail dot com
Description:
gethostbyname() is not interruptible by signals. If it cannot resolve
an hostname there is no way it can be interrupted except for a SIGKILL.
Reproduce code:
---
declare(ticks=1);
function al($sig)
{
echo $sig;
exit(0);
}
pcntl_signal(SIGINT, "al");
pcntl_signal(SIGTERM, "al");
pcntl_signal(SIGALRM, "al");
pcntl_alarm(3);
echo gethostbyname("google.com");
Expected result:
I was expected to interrupt gethostbyname() with any signal.
Actual result:
--
When running the above code, if the system cannot resolve google's
hostname, the function blocks and doesn't respond to any signal.
--
Edit this bug report at http://bugs.php.net/?id=47192&edit=1
#46419 [Asn->Csd]: Elements of associative arrays with NULL value are lost
ID: 46419
Updated by: dmi...@php.net
Reported By: max dot bilyk at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: SOAP related
Operating System: SuSE SLES 10
PHP Version: 5.2.6
Assigned To: dmitry
New Comment:
This bug has been fixed in CVS.
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.
Previous Comments:
[2009-01-16 14:02:40] fel...@php.net
Assigned to maintainer.
[2009-01-16 09:41:33] might at nifty dot com
I send a pache for this bug.
This patch remove "if(Z_TYPE_PP(temp_data) != IS_NULL)" block.
---
+++ php_encoding.c 2009-01-16 16:28:43.0 +0900
@@ -2638,33 +2638,33 @@
ulong int_val;
zend_hash_get_current_data(data->value.ht,
(void **)&temp_data);
- if (Z_TYPE_PP(temp_data) != IS_NULL) {
- item = xmlNewNode(NULL,
BAD_CAST("item"));
- xmlAddChild(xmlParam, item);
- key = xmlNewNode(NULL,
BAD_CAST("key"));
- xmlAddChild(item,key);
- if
(zend_hash_get_current_key(data->value.ht, &key_val, &int_val, FALSE) ==
HASH_KEY_IS_STRING) {
- if (style == SOAP_ENCODED) {
- set_xsi_type(key,
"xsd:string");
- }
- xmlNodeSetContent(key,
BAD_CAST(key_val));
- } else {
- smart_str tmp = {0};
- smart_str_append_long(&tmp,
int_val);
- smart_str_0(&tmp);
-
- if (style == SOAP_ENCODED) {
- set_xsi_type(key,
"xsd:int");
- }
- xmlNodeSetContentLen(key,
BAD_CAST(tmp.c), tmp.len);
- smart_str_free(&tmp);
+ item = xmlNewNode(NULL, BAD_CAST("item"));
+ xmlAddChild(xmlParam, item);
+ key = xmlNewNode(NULL, BAD_CAST("key"));
+ xmlAddChild(item,key);
+ if (zend_hash_get_current_key(data->value.ht,
&key_val, &int_val, FALSE) == HASH_KEY_IS_STRING) {
+ if (style == SOAP_ENCODED) {
+ set_xsi_type(key,
"xsd:string");
}
+ xmlNodeSetContent(key,
BAD_CAST(key_val));
+ } else {
+ smart_str tmp = {0};
+ smart_str_append_long(&tmp, int_val);
+ smart_str_0(&tmp);
- xparam =
master_to_xml(get_conversion((*temp_data)->type), (*temp_data), style,
item);
+ if (style == SOAP_ENCODED) {
+ set_xsi_type(key, "xsd:int");
+ }
+ xmlNodeSetContentLen(key,
BAD_CAST(tmp.c), tmp.len);
- xmlNodeSetName(xparam,
BAD_CAST("value"));
+ smart_str_free(&tmp);
}
+
+ xparam =
master_to_xml(get_conversion((*temp_data)->type), (*temp_data), style,
item);
+
+ xmlNodeSetName(xparam, BAD_CAST("value"));
+
zend_hash_move_forward(data->value.ht);
}
}
[2008-10-29 12:49:02] max dot bilyk at gmail dot com
Sorry, object properties are OK, so I removed it from "Summary"
[2008-10-29 12:47:18] max dot bilyk at gmail dot com
Description:
When transferring via SOAP associative arrays which have elements with
NULL value these elements are lost. At the same time f.e. empty strings
are transferred normally. Properities of objects with NULL value are
also transferred OK. The problem is that indices of associative arrays
are also informative as well as their values, therefore it's a loss of
significant information.
Another example: in case of data fetch from database into associative
array we often have array elements with NULL value, and when fetching
multiple rows each time
#47217 [NEW]: content-type is not set properly
From: gubp at pisti dot hu
Operating system: FreeBSD
PHP version: 5.2.8
PHP Bug Type: cURL related
Bug description: content-type is not set properly
Description:
Using the cURL to send files with custom content-type (eg.:
"@filename;type=content-type") does not work, because undesirable "type="
string is preprended to the actual content-type.
Reproduce code:
---
test.php:
-
$data = array('file' => '@sheet.xls;type=application/vnd.ms-excel');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://localhost/upload.php');
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
curl_exec($ch);
echo curl_error($ch);
upload.php:
---
print_r($_FILES);
Expected result:
Array
(
[file] => Array
(
[name] => sheet.xls
[type] => application/vnd.ms-excel
[tmp_name] => /var/tmp/php21KVfg
[error] => 0
[size] => 1192
)
)
Actual result:
--
Array
(
[file] => Array
(
[name] => sheet.xls
[type] => type=application/vnd.ms-excel
[tmp_name] => /var/tmp/php21KVfg
[error] => 0
[size] => 1192
)
)
--
Edit bug report at http://bugs.php.net/?id=47217&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47217&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47217&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47217&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47217&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47217&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47217&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47217&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47217&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47217&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47217&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47217&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47217&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47217&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47217&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47217&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47217&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47217&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47217&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47217&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47217&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47217&r=mysqlcfg
#47021 [Com]: SoapClient stumbles over WSDL delivered with "Transfer-Encoding: chunked"
ID: 47021
Comment by: giovanni at giacobbi dot net
Reported By: daniel dot gorski at develnet dot org
Status: Open
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.3CVS-2009-01-06 (CVS)
New Comment:
Please see related discussion:
http://marc.info/?t=12329199332&r=1&w=2
See also bug report #43069 which actually caused this bug.
Previous Comments:
[2009-01-22 15:35:02] ml at x-net dot be
I can confirm this bug. I tried avoiding the chunking in Apache by
using mod_deflate, but the PHP SOAP client probably doesn't send an
Accept-Encoding header with gzip in it.
[2009-01-06 16:28:52] daniel dot gorski at develnet dot org
Description:
The \SoapClient (and probably the \SoapServer) stumble over WSDL files
that are delivered via HTTP in chunks, carrying the HTTP response header
"Transfer-Encoding: chunked".
Reproduce code:
---
$sc = \SoapClient('http://any.wsdl/that/is/delivered/in/chunks');
Expected result:
No error, intantiation and initialization of the \SoapClient object.
Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from [URL]: Start tag expected, '<' not found in
[FILE]
--
Edit this bug report at http://bugs.php.net/?id=47021&edit=1
#47183 [Fbk->Opn]: Invalid format in php_error_docref() in ext/date/php_date.c:guess_timezone()
ID: 47183
User updated by: ch dot maurer at gmx dot de
Reported By: ch dot maurer at gmx dot de
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: Linux (none) 2.6.26.2
PHP Version: 5.2.8
New Comment:
No, changing
php_error_docref(NULL TSRMLS_CC, E_STRICT, DATE_TZ_ERRMSG "We
selected '%s' for '%s/%.1f/%s' instead", tzid, ta ? ta->tm_zone :
"Unknown", ta ? (float) (ta->tm_gmtoff / 3600) : 0, ta ? (ta->tm_isdst ?
"DST" : "no DST") : "Unknown");
to
double value = (double) (ta ? (float) (ta->tm_gmtoff / 3600) : 0);
php_error_docref(NULL TSRMLS_CC, E_STRICT, DATE_TZ_ERRMSG "We selected
'%s' for '%s/%.1f/%s' instead", tzid, ta ? ta->tm_zone : "Unknown",
value, ta ? (ta->tm_isdst ? "DST" : "no DST") : "Unknown");
does not change anything.
Previous Comments:
[2009-01-22 14:32:30] il...@php.net
Have you tried changing the (float) cast to (double) ?
[2009-01-21 19:18:47] j...@php.net
So it's actually bug in ext/date..
[2009-01-21 13:10:19] ch dot maurer at gmx dot de
Description:
See also
'http://www.apachefriends.org/f/viewtopic.php?t=32008&sid=5d3e09931c2d70bb0c1430f49c6c3a0c'
When cross compiled for ppc_85xxDP
A. '' terminates after displaying the date info and
displays error 'Fatal error: Balloc()
allocation exceeds list boundary in
/media/server/wwwroot/htdocs/info.php on line 2'
B. 'php -i' terminates after displaying the date info and terminates
Workaround:
If I replace %f by %d in the call to php_error_docref() in function
ext/date/php_date.c::guess_timezone():
php_error_docref(NULL TSRMLS_CC, E_STRICT, DATE_TZ_ERRMSG "We
selected '%s' for '%s/%.1f/%s' instead", tzid, ta ? ta->tm_zone :
"Unknown", ta ? (float) (ta->tm_gmtoff / 3600) : 0, ta ? (ta->tm_isdst ?
"DST" : "no DST") : "Unknown");
replaced by
php_error_docref(NULL TSRMLS_CC, E_STRICT, DATE_TZ_ERRMSG "We
selected '%s' for '%s/%d/%s' instead", tzid, ta ? ta->tm_zone :
"Unknown", ta ? ta->tm_gmtoff : 0, ta ? (ta->tm_isdst ? "DST" : "no
DST") : "Unknown");
this error disappears.
'php -i' will call guess_timezone() which calls
php_error_docref(NULL TSRMLS_CC, E_STRICT, DATE_TZ_ERRMSG "We selected
'%s' for '%s/%.1f/%s' instead", tzid, ta ? ta->tm_zone : "Unknown", ta ?
(float) (ta->tm_gmtoff / 3600) : 0, ta ? (ta->tm_isdst ? "DST" : "no
DST") : "Unknown");
which ends up calling
xbuf_format_converter() which does a va_arg(ap, double) for the %f
passed in to php_error_docref()
if I replace
case LM_STD:
fp_num = va_arg(ap, double);
by
case LM_STD:
fp_num = va_arg(ap, float);
I get
/home/christoph/php/ppc/php-5.2.8/main/spprintf.c: In function
'xbuf_format_converter':
/home/christoph/php/ppc/php-5.2.8/main/spprintf.c:570: warning: 'float'
is promoted to 'double' when passed through '...'
/home/christoph/php/ppc/php-5.2.8/main/spprintf.c:570: warning: (so you
should pass 'double' not 'float' to 'va_arg')
/home/christoph/php/ppc/php-5.2.8/main/spprintf.c:570: note: if this
code is reached, the program will abort
Reproduce code:
---
'php -i',
You will need to cross-compile PHP with the ELDK-4.2 for ppc_85xxDP and
run on the target ppc
X. Install ELDK-4.2
Note: ELDK does not require *any* root privileges, which is why I run
everything from my home dir.
X.1 download ELDK-4.2:
ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/eldk/4.2/ppc-linux-x86/iso/ppc-2008-04-01.iso
and burn CD
X.2 install ELDK-4.2: /media/ppc-2008-04-01> ./install -d
/home/christoph/ELDK-4.2 ppc_85xxDP
X.3 set environment variables in normal Linux shell (2 exports)
export CROSS_COMPILE=ppc_85xxDP-
export
PATH=/home/christoph/ELDK-4.2/usr/ppc-linux/bin:/home/christoph/ELDK-4.2/usr/bin:/home/christoph/ELDK-4.2/bin:$PATH
A. cross-compile apache from ELDK-4.2 src rpm for ppc_85xxDP
Do A. if you want to call '' from a browser
If you only want to execute 'php -i', you can skip this step A.
A.1 Do X.3 first
A.2 download and copy apache source rpm
'ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/eldk/4.2/ppc-linux-x86/sources/target/SRPMS/httpd-2.2.4-4.1.src.rpm'
to /home/christoph/ELDK-4.2/usr/src/denx/SRPMS
> cd /home/christoph/ELDK-4.2/usr/src/denx/SRPMS
> ~/ELDK-4.2/usr/src/denx/SRPMS> ${CROSS_COMPILE}rpm -iv
httpd-2.2.4-4.1.src.rpm
A.3 build apache
cd > /home/christoph/usr/src/denx/SPECS
~/ELDK-4.2/usr/src/denx/SPECS> ${CROSS_COMPILE}rpmbuild -ba httpd.spec
A.4 install apache to /home/christoph/ppc/wwwroot
B. cross-compile PHP-5.2.8 for ppc_85xxDP
B.1 download and copy PHP sources to /home/christoph/php/ppc/php-5.2.8
B.2 build php
B.2.1 If you executed step A. before, run
/home/christoph/php/pp
