Bug #55760 [Com]: Can not load php_ldap.dll
Edit report at https://bugs.php.net/bug.php?id=55760edit=1 ID: 55760 Comment by: ramki067 at gmail dot com Reported by:mod4wb at heysoft dot de Summary:Can not load php_ldap.dll Status: Bogus Type: Bug Package:LDAP related Operating System: Windows PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Same problem here: Installed XAMPP 1.7.7 and enabled extension=php_ldap.dll in php.ini file in C:\xampp\php\php.ini path. After restarting apache, i'm getting an error: php_ldap.dll file could not be loaded. Module could not be found. The package has PHP 5.3.8 version. Is LDAP not supported or the support is not added in this PHP release? or am i missing something? Mods Please reply. Thanks. Previous Comments: [2011-09-29 14:25:08] nrenou at free dot fr Same problem : With xampp 1.7.7 on a Windows 2003 Server, if you enable php_ldap.dll, Apache won't start ssleay32.dll, libeay32.dll, libsasl.sll and php5ts.dll are in c:\xampp\php and Apache doesn't start if you don't copy these files into c:\xampp\php\ext (the same folder than php_ldap.dll) Regards [2011-09-22 11:15:46] paj...@php.net And for the record here: it is a dependency of Crypt32.dll which is used by libsasl.dll. [2011-09-22 11:09:51] paj...@php.net Directory of c:\Program Files\Internet Explorer 03/15/2011 09:44 AM 887,296 iedvtool.dll 03/15/2011 09:44 AM 546,816 ieproxy.dll 07/22/2011 07:34 AM 304,640 IEShims.dll 03/15/2011 09:44 AM 498,688 jsdbgui.dll 03/15/2011 09:44 AM 140,800 jsdebuggeride.dll 03/15/2011 09:44 AM66,048 JSProfilerCore.dll 03/15/2011 09:44 AM 194,560 jsprofilerui.dll 06/10/2009 10:30 PM 358,904 msdbg2.dll 03/15/2011 09:44 AM 455,680 networkinspection.dll 03/15/2011 09:44 AM 537,088 pdm.dll 07/22/2011 07:55 AM 174,384 sqmapi.dll 11 File(s) 4,164,904 bytes For any support question please use php-windows or php-install mailing list, bugs.php.net is only about actual issues. Thanks for your attention. [2011-09-22 10:41:21] mod4wb at heysoft dot de Sure this tipp does not help, because as I wrote earlier: I searched the entire Windows drive and the files are not there. I downloaded both files from the internet now and it works. I am sure there will be more people with the same problem, but if you don't care, why should I? Tipp: php 5.3.5 is compiled with VC6 php 5.3.8 is compiled with VC9 Probably soemone did noch check the new compiler options, because the files are required, but nod needed according to dependency walker. [2011-09-22 08:03:05] paj...@php.net SASL support requires ieshims.dll, via libsasl.dll. Add the internet explorer directory to your path and that should fix the issue. 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 https://bugs.php.net/bug.php?id=55760 -- Edit this bug report at https://bugs.php.net/bug.php?id=55760edit=1
Bug #55796 [Com]: directive mysql.connect_charset missing
Edit report at https://bugs.php.net/bug.php?id=55796edit=1 ID: 55796 Comment by: git dot user at gmail dot com Reported by:b dot cropp at srz dot de Summary:directive mysql.connect_charset missing Status: Open Type: Bug Package:MySQL related Operating System: gentoo linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: seems like duplicate of https://bugs.php.net/bug.php?id=33604 Previous Comments: [2011-09-27 09:59:19] b dot cropp at srz dot de Description: After updating from PHP-5.3.6 to 5.3.8 directive mysql.connect_charset seems to be missing. Is this a bug or wanted? If it's wanted, how should I now handle the db communication? Please give me a reference for this new behaviour. -- Edit this bug report at https://bugs.php.net/bug.php?id=55796edit=1
Bug #55760 [Bgs]: Can not load php_ldap.dll
Edit report at https://bugs.php.net/bug.php?id=55760edit=1 ID: 55760 Updated by: paj...@php.net Reported by:mod4wb at heysoft dot de Summary:Can not load php_ldap.dll Status: Bogus Type: Bug Package:LDAP related Operating System: Windows PHP Version:5.3.8 Block user comment: N Private report: N New Comment: See my previous comment, not much we can do against that. Also to fix your setup is rather easy. Previous Comments: [2011-10-12 10:32:07] ramki067 at gmail dot com Same problem here: Installed XAMPP 1.7.7 and enabled extension=php_ldap.dll in php.ini file in C:\xampp\php\php.ini path. After restarting apache, i'm getting an error: php_ldap.dll file could not be loaded. Module could not be found. The package has PHP 5.3.8 version. Is LDAP not supported or the support is not added in this PHP release? or am i missing something? Mods Please reply. Thanks. [2011-09-29 14:25:08] nrenou at free dot fr Same problem : With xampp 1.7.7 on a Windows 2003 Server, if you enable php_ldap.dll, Apache won't start ssleay32.dll, libeay32.dll, libsasl.sll and php5ts.dll are in c:\xampp\php and Apache doesn't start if you don't copy these files into c:\xampp\php\ext (the same folder than php_ldap.dll) Regards [2011-09-22 11:15:46] paj...@php.net And for the record here: it is a dependency of Crypt32.dll which is used by libsasl.dll. [2011-09-22 11:09:51] paj...@php.net Directory of c:\Program Files\Internet Explorer 03/15/2011 09:44 AM 887,296 iedvtool.dll 03/15/2011 09:44 AM 546,816 ieproxy.dll 07/22/2011 07:34 AM 304,640 IEShims.dll 03/15/2011 09:44 AM 498,688 jsdbgui.dll 03/15/2011 09:44 AM 140,800 jsdebuggeride.dll 03/15/2011 09:44 AM66,048 JSProfilerCore.dll 03/15/2011 09:44 AM 194,560 jsprofilerui.dll 06/10/2009 10:30 PM 358,904 msdbg2.dll 03/15/2011 09:44 AM 455,680 networkinspection.dll 03/15/2011 09:44 AM 537,088 pdm.dll 07/22/2011 07:55 AM 174,384 sqmapi.dll 11 File(s) 4,164,904 bytes For any support question please use php-windows or php-install mailing list, bugs.php.net is only about actual issues. Thanks for your attention. [2011-09-22 10:41:21] mod4wb at heysoft dot de Sure this tipp does not help, because as I wrote earlier: I searched the entire Windows drive and the files are not there. I downloaded both files from the internet now and it works. I am sure there will be more people with the same problem, but if you don't care, why should I? Tipp: php 5.3.5 is compiled with VC6 php 5.3.8 is compiled with VC9 Probably soemone did noch check the new compiler options, because the files are required, but nod needed according to dependency walker. 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 https://bugs.php.net/bug.php?id=55760 -- Edit this bug report at https://bugs.php.net/bug.php?id=55760edit=1
[PHP-BUG] Req #60044 [NEW]: make is failing for date/lib/parse_tz.lo
From: Operating system: AIX 6.1 PHP version: 5.3.8 Package: Compile Failure Bug Type: Feature/Change Request Bug description:make is failing for date/lib/parse_tz.lo Description: configurung with this command line parameters: ./configure --prefix=/usr/local --with-apxs2=/export/opt/quikremit/apache2/bin/apxs --with-config-file-path=/export/opt/quikremit/apache2/conf --with-gd --with-zlib-dir=/opt/freeware/lib --enable-shared --disable-static --with-png --with-zlib --with-bz2 --with-xml --with-jpeg-dir=/opt/freeware/lib --with-png-dir=/opt/freeware/lib --with-xpm-dir=/opt/freeware/lib --host=powerpc-ibm-aix6.1.0.0 after this i am running make But it is failing with below error code: Assembler: /tmp//ccksvqSL.s: line 1541: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. make: *** [ext/date/lib/parse_tz.lo] Error 1 Test script: --- make is failing on below code: /bin/sh /export/opt/quikremit/pqapp/php/php-5.3.8/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/date/lib -Iext/date/ -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/date/ -DPHP_ATOM_INC -I/export/opt/quikremit/pqapp/php/php-5.3.8/include -I/export/opt/quikremit/pqapp/php/php-5.3.8/main -I/export/opt/quikremit/pqapp/php/php-5.3.8 -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/date/lib -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/ereg/regex -I/usr/local/include/libxml2 -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/sqlite3/libsqlite -I/export/opt/quikremit/pqapp/php/php-5.3.8/TSRM -I/export/opt/quikremit/pqapp/php/php-5.3.8/Zend-I/usr/include -g -O2 -fvisibility=hidden -c /export/opt/quikremit/pqapp/php/php-5.3.8/ext/date/lib/parse_tz.c -o ext/date/lib/parse_tz.lo Expected result: make should be successful with no errors Actual result: -- Assembler: /tmp//ccf46yBi.s: line 1541: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. make: *** [ext/date/lib/parse_tz.lo] Error 1 -- Edit bug report at https://bugs.php.net/bug.php?id=60044edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60044r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60044r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60044r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60044r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60044r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60044r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60044r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60044r=needscript Try newer version: https://bugs.php.net/fix.php?id=60044r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60044r=support Expected behavior: https://bugs.php.net/fix.php?id=60044r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60044r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60044r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60044r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60044r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60044r=dst IIS Stability: https://bugs.php.net/fix.php?id=60044r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60044r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60044r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60044r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60044r=mysqlcfg
Req #60044 [Opn-Fbk]: make is failing for date/lib/parse_tz.lo
Edit report at https://bugs.php.net/bug.php?id=60044edit=1 ID: 60044 Updated by: der...@php.net Reported by:sanjay dot d dot patil at oracle dot com Summary:make is failing for date/lib/parse_tz.lo -Status: Open +Status: Feedback Type: Feature/Change Request Package:Compile Failure Operating System: AIX 6.1 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: This .s file is generated by your compiler. Perhaps it can't deal with so many states in a file? Try disabling optimisation (-O0) instead of (-O2) while compiling (you can just change that in the Makefile for the parze_tz file only. Previous Comments: [2011-10-12 11:04:21] sanjay dot d dot patil at oracle dot com Description: configurung with this command line parameters: ./configure --prefix=/usr/local --with-apxs2=/export/opt/quikremit/apache2/bin/apxs --with-config-file-path=/export/opt/quikremit/apache2/conf --with-gd --with-zlib-dir=/opt/freeware/lib --enable-shared --disable-static --with-png --with-zlib --with-bz2 --with-xml --with-jpeg-dir=/opt/freeware/lib --with-png-dir=/opt/freeware/lib --with-xpm-dir=/opt/freeware/lib --host=powerpc-ibm-aix6.1.0.0 after this i am running make But it is failing with below error code: Assembler: /tmp//ccksvqSL.s: line 1541: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. make: *** [ext/date/lib/parse_tz.lo] Error 1 Test script: --- make is failing on below code: /bin/sh /export/opt/quikremit/pqapp/php/php-5.3.8/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/date/lib -Iext/date/ -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/date/ -DPHP_ATOM_INC -I/export/opt/quikremit/pqapp/php/php-5.3.8/include -I/export/opt/quikremit/pqapp/php/php-5.3.8/main -I/export/opt/quikremit/pqapp/php/php-5.3.8 -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/date/lib -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/ereg/regex -I/usr/local/include/libxml2 -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/sqlite3/libsqlite -I/export/opt/quikremit/pqapp/php/php-5.3.8/TSRM -I/export/opt/quikremit/pqapp/php/php-5.3.8/Zend-I/usr/include -g -O2 -fvisibility=hidden -c /export/opt/quikremit/pqapp/php/php-5.3.8/ext/date/lib/parse_tz.c -o ext/date/lib/parse_tz.lo Expected result: make should be successful with no errors Actual result: -- Assembler: /tmp//ccf46yBi.s: line 1541: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. make: *** [ext/date/lib/parse_tz.lo] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=60044edit=1
Bug #60042 [Csd]: spl_autoload_call may manipulate a dangling pointer
Edit report at https://bugs.php.net/bug.php?id=60042edit=1 ID: 60042 User updated by:tom at punkave dot com Reported by:tom at punkave dot com Summary:spl_autoload_call may manipulate a dangling pointer Status: Closed Type: Bug Package:SPL related Operating System: Any PHP Version:5.3.8 Assigned To:felipe Block user comment: N Private report: N New Comment: Thanks for hitting it so quickly! Previous Comments: [2011-10-12 01:02:59] fel...@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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. ;) [2011-10-12 01:02:51] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318040 Log: - Fixed bug #60042 (spl_autoload_call may manipulate a dangling pointer) patch by: tom at punkave dot com [2011-10-12 00:59:42] fel...@php.net Ah, right. I didn't see the loop. [2011-10-12 00:28:10] tom at punkave dot com But there's a while loop, and if there are multiple iterations through the loop and one of them doesn't change retval then the same value is destroyed more than once, isn't it? That's bad, right? [2011-10-11 22:12:32] fel...@php.net The retval variable doesn't need to be set to NULL there. The pointer only live in the current scope and it isn't used after zval_ptr_dtor. Thanks. 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 https://bugs.php.net/bug.php?id=60042 -- Edit this bug report at https://bugs.php.net/bug.php?id=60042edit=1
Bug #31577 [Com]: [chm] bug on function.dbase-add-record.html
Edit report at https://bugs.php.net/bug.php?id=31577edit=1 ID: 31577 Comment by: tmylward at alphacrc dot com Reported by:sand001 at sympatico dot ca Summary:[chm] bug on function.dbase-add-record.html Status: No Feedback Type: Bug Package:dBase related Operating System: windows XP PHP Version:5.0.2 Block user comment: N Private report: N New Comment: I have a similar problem. I can read all of the 122 .DBF files supplied by my Company. However, when I attempt to open any file with read/write or writeOnly permissions, the file will NOT open. Previous Comments: [2005-02-26 01:00:04] 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. [2005-02-08 11:03:27] tony2...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Please check if your webserver has all access privileges to the dbf file. [2005-01-16 22:34:09] sand001 at sympatico dot ca Description: I have found a bug on page function.dbase-add-record.html [chm date: 2004-12-26]... I can read from a .dbf file with PHP but I cannot write to it. I have used PHP to create the .dbf or I have used my normally created .dbf with the same structure. The same HTML input screen collects data so that I can write a .txt delimited file with it and append it into the .dbf but the prescribed code from the examples fails when the dbase_open() flag is set to '1' or '2' as required to write the data. All of the echo lines show me that the fields are filled properly. The dbase_open() command works well when the flag is set to '0' for reading. I can output the data that I have put into the .dbf by appending from the .txt file. Reproduce code: --- ?php $filename=collect.txt; $name=$_POST[name]; $street=$_POST[street]; $city=$_POST[city]; $prov=$_POST[prov]; $country=$_POST[country]; $postal=$_POST[postal]; $tel=$_POST[tel]; $mail=$_POST[mail]; $fax=$_POST[fax]; echo strong $name/strongbr; echo strong $street/strongbr; echo strong $city/strongstrong, $prov/strongstrong, $country/strongbr; echo strong $postal/strongbr; echo strong $tel/strongbr; echo strong $mail/strongbr; echo strong $fax/strongbr; $db=dbase_open(collectx.dbf,2) ; $def = array (trim($name), trim($street), trim($city), trim($prov), trim($country), trim($postal), trim($tel), trim($mail), trim($fax)); dbase_add_record($db, $def); dbase_close($db) ? Expected result: I expect to be able to fill a .dbf file with HTML input as collected in the fields that echo their contents to me, above. Thank you for your assistance. Actual result: -- Warning: dbase_open() [function.dbase-open]: unable to open database collectx.dbf in c:\Inetpub\wwwroot\collect.php on line 23 -- Edit this bug report at https://bugs.php.net/bug.php?id=31577edit=1
Bug #50291 [Com]: incorrect usage of autoconf diversions
Edit report at https://bugs.php.net/bug.php?id=50291edit=1 ID: 50291 Comment by: reeves_28 at yahoo dot com Reported by:vapier at gentoo dot org Summary:incorrect usage of autoconf diversions Status: Re-Opened Type: Bug Package:Compile Failure Operating System: Linux PHP Version:5.3.1 Block user comment: N Private report: N New Comment: One to make it compile is to run grep -Rn divert( and comment out all lines in the *.m4 and *.in files that show up. There should be only three files that actuall need changed. Ignore /ext/fileinfo/tests/magic this doesn't affect the compile. You will get a lot of warnings from autoconf but it will compile. Previous Comments: [2011-04-25 11:12:57] mail at crick dot ru PS. I mean the patch to compile only with autoconf 2.6.4, not for both post and pre. [2011-04-25 11:09:15] mail at crick dot ru Can I ask post here a patch that will allow PHP to compile with autoconf version 2.6? I think it will be useful to many users. [2011-04-25 01:21:24] ras...@php.net I spent quite a while on it. I couldn't come up with a viable way to support both pre and post autoconf-2.64 so it is either/or at this point. Every distro has pre- 2.64, not everyone has post 2.64. We will eventually be able to make a clean break, but it definitely won't be in 5.3. [2011-04-24 23:41:25] mail at crick dot ru This annoying bug is still there. How about solutions? [2010-08-10 19:58:16] scott...@php.net This got lost when we re-branched trunk from 5_3 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 https://bugs.php.net/bug.php?id=50291 -- Edit this bug report at https://bugs.php.net/bug.php?id=50291edit=1
Req #53831 [Com]: DateInterval constructor does not handle valid ISO 8601 strings
Edit report at https://bugs.php.net/bug.php?id=53831edit=1
ID: 53831
Comment by: dagguh at gmail dot com
Reported by:pallinger at dsd dot sztaki dot hu
Summary:DateInterval constructor does not handle valid ISO
8601 strings
Status: Open
Type: Feature/Change Request
Package:Date/time related
Operating System: ubuntu linux 10.10
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
http://en.wikipedia.org/wiki/Iso8601#Durations
This decimal fraction may be specified with either a comma or a full stop, as
in
P0,5Y or P0.5Y.
Remember to accept both comma and a full stop.
Previous Comments:
[2011-01-24 18:41:19] pallinger at dsd dot sztaki dot hu
Description:
---
From manual page: http://www.php.net/dateinterval.construct
---
The documentation says that Each duration period is represented by an integer
value followed by a period designator., however, the ISO 8601 allows
non-integer values for the last number
(http://en.wikipedia.org/wiki/ISO_8601#Durations).
This is quite important if I want to parse XML data which contains
millisecond-precision durations, as the seconds will surely not be integers.
Test script:
---
?php
var_dump(new DateInterval('PT1.1S'));
?
Expected result:
Should print out a valid DateInterval object, eg.:
object(DateInterval)#1 (8) {
[y]=
int(0)
[m]=
int(0)
[d]=
int(0)
[h]=
int(0)
[i]=
int(0)
[s]=
float(1.1)
[invert]=
int(0)
[days]=
bool(false)
}
It could also include a millisecond/microsecond/nanosecond field to accomodate
additional precision. However, if the durations that are stored are still
integers, it would be difficult to handle durations like P0.5Y.
Actual result:
--
PHP Fatal error: Uncaught exception 'Exception' with message
'DateInterval::__construct(): Unknown or bad format (PT1.1S)' in -:1
Stack trace:
#0 -(1): DateInterval-__construct('PT1.1S')
#1 {main}
thrown in - on line 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=53831edit=1
Req #50019 [Com]: DatePeriod doesn't accept negative intervals
Edit report at https://bugs.php.net/bug.php?id=50019edit=1
ID: 50019
Comment by: dagguh at gmail dot com
Reported by:jennifer dot kimball at nrc dot ca
Summary:DatePeriod doesn't accept negative intervals
Status: Open
Type: Feature/Change Request
Package:Date/time related
Operating System: Solaris 10
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
You are mistaken.
This is the faulty line:
$i=DateInterval::createFromDateString('-1 year');
DateInterval::createFromDateString doesn't report any error when it fails. Fix
your DateInterval first :)
Previous Comments:
[2009-10-27 15:13:56] jennifer dot kimball at nrc dot ca
Description:
DatePeriod should be able to create a list of dates that goes into the future
from the start date, or into the past from the start date. There is nothing in
the documentation to suggest this should not be possible, and trying it does
not throw an error.
Given that a question like 'What are the dates of the previous 3 Saturdays' is
fairly common, it seems sensible that DatePeriod be able to calculate that way.
Reproduce code:
---
---
From manual page: dateperiod.construct#Description
---
//postive interval works:
$d1=date_create('2004-12-25');
$i=DateInterval::createFromDateString('1 year');
$d2=date_create('2009-03-03');
$p=new DatePeriod($d1,$i,$d2);
foreach($p as $d) echo $d-format('Y-m-d');
//negative interval fails with no error
$d1=date_create('2009-12-25');
$i=DateInterval::createFromDateString('-1 year');
$d2=date_create('2004-03-03');
$p=new DatePeriod($d1,$i,$d2);
foreach($p as $d) echo $d-format('Y-m-d');
Expected result:
//postive interval output (which does happen)
2004-12-25
2005-12-25
2006-12-25
2007-12-25
2008-12-25
//negative interval output (which does not happen)
2009-12-25
2008-12-25
2007-12-25
2006-12-25
2005-12-25
2004-12-25
Actual result:
--
//no output
//no error
--
Edit this bug report at https://bugs.php.net/bug.php?id=50019edit=1
Bug #50444 [Opn]: PDO-ODBC changes for 64-bit
Edit report at https://bugs.php.net/bug.php?id=50444edit=1
ID: 50444
User updated by:davbrown4 at yahoo dot com
Reported by:davbrown4 at yahoo dot com
Summary:PDO-ODBC changes for 64-bit
Status: Open
Type: Bug
Package:PDO related
Operating System: Solaris
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
Hello - are there any plans to accept this fix? We have customers using php who
need this fix.
Previous Comments:
[2009-12-11 00:25:46] davbrown4 at yahoo dot com
Description:
While testing the 64-bit version of our ODBC driver (StarQuest StarSQL
http://www.starquest.com) on Solaris SPARC, with unixODBC 2.2.14 (the current
stable version), we encountered typedef problems with the PDO-ODBC support - it
needed 64-bit changes similar to what had already been done to the ODBC
support. The lines that needed to be changed were pointed out by the Solaris
(Sun Workshop) compiler.
(Note that in unixODBC 2.2.14, the default build for 64 bit platforms is to
make sizeof( SQLLEN ) = 8. The changes below should continue to work with the
older interpretation (BUILD_LEGACY_64_BIT_MODE)).
Reproduce code:
---
The following are our diffs to 5.3.1 (we originally were working with 5.2.11).
diff -ur pdo_odbc-orig pdo_odbc
diff -ur pdo_odbc-orig/odbc_stmt.c pdo_odbc/odbc_stmt.c
--- pdo_odbc-orig/odbc_stmt.c 2009-07-14 19:32:43.0 -0700
+++ pdo_odbc/odbc_stmt.c2009-12-03 16:36:42.0 -0800
@@ -279,7 +279,7 @@
pdo_odbc_stmt *S = (pdo_odbc_stmt*)stmt-driver_data;
RETCODE rc;
SWORD sqltype = 0, ctype = 0, scale = 0, nullable = 0;
- UDWORD precision = 0;
+ SQLULEN precision = 0;
pdo_odbc_param *P;
/* we're only interested in parameters for prepared SQL right now */
@@ -546,7 +546,7 @@
zend_bool dyn = FALSE;
RETCODE rc;
SWORD colnamelen;
- SDWORD colsize, displaysize;
+ SQLULEN colsize, displaysize;
rc = SQLDescribeCol(S-stmt, colno+1, S-cols[colno].colname,
sizeof(S-cols[colno].colname)-1, colnamelen,
diff -ur pdo_odbc-orig/php_pdo_odbc_int.h pdo_odbc/php_pdo_odbc_int.h
--- pdo_odbc-orig/php_pdo_odbc_int.h2008-12-31 03:15:49.0 -0800
+++ pdo_odbc/php_pdo_odbc_int.h 2009-12-03 16:37:45.0 -0800
@@ -157,7 +157,7 @@
} pdo_odbc_stmt;
typedef struct {
- SQLINTEGER len;
+ SQLLEN len;
SQLSMALLINT paramtype;
char *outbuf;
unsigned is_unicode:1;
--
Edit this bug report at https://bugs.php.net/bug.php?id=50444edit=1
Bug #55848 [Ver-Csd]: openssl doesn't work with unix sockets
Edit report at https://bugs.php.net/bug.php?id=55848edit=1 ID: 55848 User updated by:mattfic...@php.net Reported by:mattfic...@php.net Summary:openssl doesn't work with unix sockets -Status: Verified +Status: Closed Type: Bug Package:OpenSSL related Operating System: Windows PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: After tracing the problem, I figured out it was a problem in my configuration. Mysqlnd with SSL works on PHP 5.4.0 for me now, through both mysql, mysqli and PDO (therefore I'm closing this bug). Note, that on PHP 5.3.8, mysql and SSL fail for me when I try to use PDO. However, it works on 5.3.8 through mysql and mysqli. Previous Comments: [2011-10-10 20:47:00] and...@php.net Matt, the error message comes from two places both in PHP. Once wenn crypto is set up and then when enabled. It probably barks already during set up and this got to be traced. I can't reproduce it here on Linux. Is it possible go trace it in a debugger and see which parts of the streams return NOT_IMPL for the stream? Thanks! [2011-10-10 20:08:43] and...@php.net PHP 5.3 and 5.4, and probably trunk, don't support SSL over Unix Sockets. Sorry! mysqlnd tries to set up SSL and PHP barks that this stream type doesn't support crypto. As workaround: you have to go back using libmysql, where SSL over Unix Sockets works. [2011-10-08 09:39:35] pajoye @php.net This bug due to this typo was only in 5.3, 5.4 and trunk were not affected as far as I can see [2011-10-08 09:14:00] pawel at prochot dot co dot uk https://bugs.php.net/bug.php?id=55870 Explains how to fix it. Just fix the spelling mistake or grab a snapshot. [2011-10-05 18:06:11] mattfic...@php.net I have tried 54 snapshot r317753 and it fails just like 5.4.0beta1 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 https://bugs.php.net/bug.php?id=55848 -- Edit this bug report at https://bugs.php.net/bug.php?id=55848edit=1
Bug #55848 [Csd]: openssl doesn't work with unix sockets
Edit report at https://bugs.php.net/bug.php?id=55848edit=1 ID: 55848 Updated by: paj...@php.net Reported by:mattfic...@php.net Summary:openssl doesn't work with unix sockets Status: Closed Type: Bug Package:OpenSSL related Operating System: Windows PHP Version:5.4.0beta1 -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N New Comment: The PDO and SSL issue in 5.3.8 is already fixed in SVN, it was due to a typo in a #ifdef. Previous Comments: [2011-10-12 17:32:31] mattfic...@php.net After tracing the problem, I figured out it was a problem in my configuration. Mysqlnd with SSL works on PHP 5.4.0 for me now, through both mysql, mysqli and PDO (therefore I'm closing this bug). Note, that on PHP 5.3.8, mysql and SSL fail for me when I try to use PDO. However, it works on 5.3.8 through mysql and mysqli. [2011-10-10 20:47:00] and...@php.net Matt, the error message comes from two places both in PHP. Once wenn crypto is set up and then when enabled. It probably barks already during set up and this got to be traced. I can't reproduce it here on Linux. Is it possible go trace it in a debugger and see which parts of the streams return NOT_IMPL for the stream? Thanks! [2011-10-10 20:08:43] and...@php.net PHP 5.3 and 5.4, and probably trunk, don't support SSL over Unix Sockets. Sorry! mysqlnd tries to set up SSL and PHP barks that this stream type doesn't support crypto. As workaround: you have to go back using libmysql, where SSL over Unix Sockets works. [2011-10-08 09:39:35] pajoye @php.net This bug due to this typo was only in 5.3, 5.4 and trunk were not affected as far as I can see [2011-10-08 09:14:00] pawel at prochot dot co dot uk https://bugs.php.net/bug.php?id=55870 Explains how to fix it. Just fix the spelling mistake or grab a snapshot. 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 https://bugs.php.net/bug.php?id=55848 -- Edit this bug report at https://bugs.php.net/bug.php?id=55848edit=1
Req #59286 [Opn]: Need to be able to support OAuth extensions.
Edit report at https://bugs.php.net/bug.php?id=59286edit=1 ID: 59286 Updated by: fel...@php.net Reported by:joe at manvscode dot com Summary:Need to be able to support OAuth extensions. Status: Open Type: Feature/Change Request Package:oauth PHP Version:5.3.2 Block user comment: N Private report: N New Comment: test Previous Comments: [2011-10-05 16:29:43] ja...@php.net On the consumer side, no. Though I think there should be a way to do so. The problem is - we'd have to make a distinction between which parameters are used in the SBS and which are not. [2011-10-05 14:29:09] sites at hubmed dot org Is there currently a method for adding oauth_body_hash to the OAuth Authorization header, when using OAUTH_HTTP_METHOD_PUT to upload a file? [2010-07-02 00:44:49] ja...@php.net We had actually discussed that specific extension and its' implementation. IIRC, the conclusion we reached basically we can only check that the signature matches per the OAuth Core spec but generating the actual oauth_body_hash would not be easy to generalize. There might be some Content-Type checks too. FWIW, ideally if the OAuth parameters come in the Authorization header you can call OAuthProvider::setRequiredParams(oauth_body_hash) but it would be up to the implementer to generate and verify the oauth_body_hash. - JJ [2010-06-29 14:09:50] joe at manvscode dot com Description: It isn't clear how extensions can be supported--like this one: http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/3/spec.html This is needed for providers that are expecting data posted and a content-type other than application/x-www-form-urlencoded (i.e. in the case of XML/JSON posting). -- Edit this bug report at https://bugs.php.net/bug.php?id=59286edit=1
Req #60045 [Opn]: Number of updated files
Edit report at https://bugs.php.net/bug.php?id=60045edit=1 ID: 60045 Updated by: yann...@php.net Reported by:b...@php.net Summary:Number of updated files Status: Open Type: Feature/Change Request Package:Online Doc Editor problem PHP Version:5.4.0beta1 -Assigned To: +Assigned To:yannick Block user comment: N Private report: N New Comment: What do you mean ? You want to display the number of YOUR file who need to be updated ? Something like this, in the title of the module : Need update (6 files - 3 of yours) Previous Comments: [2011-10-12 12:00:47] b...@php.net *maintainer could see number of files need to be updated. [2011-10-12 11:54:20] b...@php.net Description: It would be usefull if user could see which of translated files need to be updated. It would be better to add this number in string that contains all files that need to be updated. -- Edit this bug report at https://bugs.php.net/bug.php?id=60045edit=1
Bug #53074 [Csd]: Sending php-fpm service a HUP signal causes problems with daemontools
Edit report at https://bugs.php.net/bug.php?id=53074edit=1 ID: 53074 User updated by:juangiordana at gmail dot com Reported by:juangiordana at gmail dot com Summary:Sending php-fpm service a HUP signal causes problems with daemontools Status: Closed Type: Bug Package:FPM related Operating System: Linux (funtoo/gentoo) PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: Hello fat, I forgot to run the patch at that time and since it has been incorporated to the core, I thought it would be good to send the information again. Tested using PHP version 5.3.8. Output has been shortened for the sake of brevity. See PIDs 4645 to 4649 in the php-fpm-address.log file See PIDs 4942 to 4946 in the php-fpm-address.log file. When binding to address:port it doesn't start again. When binding to a socket it starts again but previous childs are detached from the master process. Previous Comments: [2010-10-21 23:17:46] f...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. This could be the same problem as bug 52501. Can you test the patch attached to the bug 52501 please ? [2010-10-15 11:30:56] juangiordana at gmail dot com Description: I'm running php-fpm with DJB daemontools (daemonize = no) process supervisor. Every time I send the process a HUP signal (graceful reload) the process is in some way detached from daemontools so it's not possible to reload it because it's already runninng. Since the children processes aren't properly (?) terminated, php-fpm refuses to start: Test script: --- # ps axf 1806 ?Ss 0:00 /bin/sh /command/svscanboot 1809 ?S 0:02 \_ svscan /service 1811 ?S 0:00 | \_ supervise nginx 1861 ?S 0:00 | | \_ nginx: master process /usr/local/sbin/nginx -c /usr/local/etc/nginx/nginx.conf 1947 ?S 0:00 | | \_ nginx: worker process 1812 ?S 0:00 | \_ supervise log 1862 ?S 0:00 | | \_ /command/multilog t s1000 n30 /var/log/nginx 1824 ?S 0:00 | \_ supervise php-fpm 20807 ?Ss 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 20808 ?S 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 20809 ?S 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 20810 ?S 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 1825 ?S 0:00 | \_ supervise log # svc -h /service/php-fpm # ps axf 14606 ?S 0:01 /srv/bin/php-cgi --fpm --fpm-config /srv/etc/php/php-fpm.conf 14607 ?S 0:00 /srv/bin/php-cgi --fpm --fpm-config /srv/etc/php/php-fpm.conf 14608 ?S 0:01 /srv/bin/php-cgi --fpm --fpm-config /srv/etc/php/php-fpm.conf # tailf /var/log/php-fpm/current @40004cb81c1f223b929c Oct 15 06:17:09.545883 [ERROR] bind() for address '127.0.0.1:9000' failed: Address already in use (98) @40004cb81c1f34789c0c Oct 15 06:17:09.880267 [WARNING] [pool www] pm.start_servers is not set. It's been set to 3. @40004cb81c1f35767854 Oct 15 06:17:09.880736 [ERROR] bind() for address '127.0.0.1:9000' failed: Address already in use (98) @40004cb81c203798141c Oct 15 06:17:10.932654 [WARNING] [pool www] pm.start_servers is not set. It's been set to 3. -- Edit this bug report at https://bugs.php.net/bug.php?id=53074edit=1
Bug #53074 [Csd-Asn]: Sending php-fpm service a HUP signal causes problems with daemontools
Edit report at https://bugs.php.net/bug.php?id=53074edit=1 ID: 53074 Updated by: f...@php.net Reported by:juangiordana at gmail dot com Summary:Sending php-fpm service a HUP signal causes problems with daemontools -Status: Closed +Status: Assigned Type: Bug Package:FPM related Operating System: Linux (funtoo/gentoo) PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N Previous Comments: [2011-10-12 19:55:15] juangiordana at gmail dot com Hello fat, I forgot to run the patch at that time and since it has been incorporated to the core, I thought it would be good to send the information again. Tested using PHP version 5.3.8. Output has been shortened for the sake of brevity. See PIDs 4645 to 4649 in the php-fpm-address.log file See PIDs 4942 to 4946 in the php-fpm-address.log file. When binding to address:port it doesn't start again. When binding to a socket it starts again but previous childs are detached from the master process. [2010-10-21 23:17:46] f...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. This could be the same problem as bug 52501. Can you test the patch attached to the bug 52501 please ? [2010-10-15 11:30:56] juangiordana at gmail dot com Description: I'm running php-fpm with DJB daemontools (daemonize = no) process supervisor. Every time I send the process a HUP signal (graceful reload) the process is in some way detached from daemontools so it's not possible to reload it because it's already runninng. Since the children processes aren't properly (?) terminated, php-fpm refuses to start: Test script: --- # ps axf 1806 ?Ss 0:00 /bin/sh /command/svscanboot 1809 ?S 0:02 \_ svscan /service 1811 ?S 0:00 | \_ supervise nginx 1861 ?S 0:00 | | \_ nginx: master process /usr/local/sbin/nginx -c /usr/local/etc/nginx/nginx.conf 1947 ?S 0:00 | | \_ nginx: worker process 1812 ?S 0:00 | \_ supervise log 1862 ?S 0:00 | | \_ /command/multilog t s1000 n30 /var/log/nginx 1824 ?S 0:00 | \_ supervise php-fpm 20807 ?Ss 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 20808 ?S 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 20809 ?S 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 20810 ?S 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 1825 ?S 0:00 | \_ supervise log # svc -h /service/php-fpm # ps axf 14606 ?S 0:01 /srv/bin/php-cgi --fpm --fpm-config /srv/etc/php/php-fpm.conf 14607 ?S 0:00 /srv/bin/php-cgi --fpm --fpm-config /srv/etc/php/php-fpm.conf 14608 ?S 0:01 /srv/bin/php-cgi --fpm --fpm-config /srv/etc/php/php-fpm.conf # tailf /var/log/php-fpm/current @40004cb81c1f223b929c Oct 15 06:17:09.545883 [ERROR] bind() for address '127.0.0.1:9000' failed: Address already in use (98) @40004cb81c1f34789c0c Oct 15 06:17:09.880267 [WARNING] [pool www] pm.start_servers is not set. It's been set to 3. @40004cb81c1f35767854 Oct 15 06:17:09.880736 [ERROR] bind() for address '127.0.0.1:9000' failed: Address already in use (98) @40004cb81c203798141c Oct 15 06:17:10.932654 [WARNING] [pool www] pm.start_servers is not set. It's been set to 3. -- Edit this bug report at https://bugs.php.net/bug.php?id=53074edit=1
Bug #53074 [Asn]: Sending php-fpm service a HUP signal causes problems with daemontools
Edit report at https://bugs.php.net/bug.php?id=53074edit=1 ID: 53074 User updated by:juangiordana at gmail dot com Reported by:juangiordana at gmail dot com Summary:Sending php-fpm service a HUP signal causes problems with daemontools Status: Assigned Type: Bug Package:FPM related Operating System: Linux (funtoo/gentoo) PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: Fat, I can't find a way to attach a file. Let me know and I'll send you the raw text output via e-mail if you need it. Thanks. # php-fpm-address.log # php -v PHP 5.3.8 (cli) (built: Aug 29 2011 19:45:22) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies # php-fpm -v PHP 5.3.8 (fpm-fcgi) (built: Aug 29 2011 19:45:20) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies # grep -v '^;' /usr/local/etc/php/php-fpm.conf [global] pid = /var/run/php-fpm.pid error_log = /var/log/php-fpm.log daemonize = no [www] listen = 127.0.0.1:9000 user = apache group = apache pm = dynamic pm.max_children = 10 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 5 pm.status_path = /status ping.path = /ping request_slowlog_timeout = 10 slowlog = /var/log/php-fpm.log.slow --- --- Step 1: Empty log. --- # /var/log/php-fpm/current # ps axfu USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 2 0.0 0.0 0 0 ?S15:18 0:00 [kthreadd] root 1 0.0 0.0 3892 712 ?Ss 15:18 0:00 init [3] root 876 0.0 0.0 12516 860 ?Ss 15:18 0:00 /sbin/udevd --daemon root 1375 0.0 0.0 12512 812 ?S 15:18 0:00 \_ /sbin/udevd --daemon root 1376 0.0 0.0 12512 812 ?S 15:18 0:00 \_ /sbin/udevd --daemon root 2592 0.0 0.0 18464 808 ?Ss 15:18 0:00 /usr/sbin/cron root 2609 0.0 0.0 14296 828 tty2 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty2 linux root 2610 0.0 0.0 14296 836 tty3 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty3 linux root 2611 0.0 0.0 14296 836 tty4 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty4 linux root 2612 0.0 0.0 14296 836 tty5 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty5 linux root 2613 0.0 0.0 14296 832 tty6 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty6 linux root 2614 0.0 0.0 9232 1256 ?Ss 15:18 0:00 /bin/sh /command/svscanboot root 2616 0.0 0.0 3916 448 ?S15:18 0:00 \_ svscan /service root 2629 0.0 0.0 3744 392 ?S15:18 0:00 | \_ supervise php-fpm root 2630 0.0 0.0 3744 292 ?S15:18 0:00 | \_ supervise log root 2617 0.0 0.0 3732 296 ?S15:18 0:00 \_ readproctitle service errors: root 4595 0.0 0.0 58316 1636 tty1 Ss 16:23 0:00 /bin/login -- root 4596 0.2 0.1 21104 3364 tty1 S16:23 0:00 \_ -bash root 4635 0.0 0.0 11252 1344 tty1 S+ 16:25 0:00 \_ /bin/sh -x ./fpm-test.sh root 4639 0.0 0.0 16936 1088 tty1 R+ 16:25 0:00 \_ ps axfu --- --- Step 2: Start service. --- # svc -u /service/php-fpm/log /service/php-fpm # sleep 10 # ps axfu USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 2 0.0 0.0 0 0 ?S15:18 0:00 [kthreadd] root 1 0.0 0.0 3892 712 ?Ss 15:18 0:00 init [3] root 876 0.0 0.0 12516 860 ?Ss 15:18 0:00 /sbin/udevd --daemon root 1375 0.0 0.0 12512 812 ?S 15:18 0:00 \_ /sbin/udevd --daemon root 1376 0.0 0.0 12512 812 ?S 15:18 0:00 \_ /sbin/udevd --daemon root 2592 0.0 0.0 18464 808 ?Ss 15:18 0:00 /usr/sbin/cron root 2609 0.0 0.0 14296 828 tty2 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty2 linux root 2610 0.0 0.0 14296 836 tty3 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty3 linux root 2611 0.0 0.0 14296 836 tty4 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty4 linux root 2612 0.0 0.0 14296 836 tty5
Bug #53074 [Com]: Sending php-fpm service a HUP signal causes problems with daemontools
Edit report at https://bugs.php.net/bug.php?id=53074edit=1 ID: 53074 Comment by: f...@php.net Reported by:juangiordana at gmail dot com Summary:Sending php-fpm service a HUP signal causes problems with daemontools Status: Assigned Type: Bug Package:FPM related Operating System: Linux (funtoo/gentoo) PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: thx It seems enough for me for now. I should be able to reproduce the problem on my side. I'll let you know. I don't have any ETA to give you yet as I'm quite busy those days. Previous Comments: [2011-10-12 20:02:53] juangiordana at gmail dot com Fat, I can't find a way to attach a file. Let me know and I'll send you the raw text output via e-mail if you need it. Thanks. # php-fpm-address.log # php -v PHP 5.3.8 (cli) (built: Aug 29 2011 19:45:22) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies # php-fpm -v PHP 5.3.8 (fpm-fcgi) (built: Aug 29 2011 19:45:20) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies # grep -v '^;' /usr/local/etc/php/php-fpm.conf [global] pid = /var/run/php-fpm.pid error_log = /var/log/php-fpm.log daemonize = no [www] listen = 127.0.0.1:9000 user = apache group = apache pm = dynamic pm.max_children = 10 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 5 pm.status_path = /status ping.path = /ping request_slowlog_timeout = 10 slowlog = /var/log/php-fpm.log.slow --- --- Step 1: Empty log. --- # /var/log/php-fpm/current # ps axfu USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 2 0.0 0.0 0 0 ?S15:18 0:00 [kthreadd] root 1 0.0 0.0 3892 712 ?Ss 15:18 0:00 init [3] root 876 0.0 0.0 12516 860 ?Ss 15:18 0:00 /sbin/udevd --daemon root 1375 0.0 0.0 12512 812 ?S 15:18 0:00 \_ /sbin/udevd --daemon root 1376 0.0 0.0 12512 812 ?S 15:18 0:00 \_ /sbin/udevd --daemon root 2592 0.0 0.0 18464 808 ?Ss 15:18 0:00 /usr/sbin/cron root 2609 0.0 0.0 14296 828 tty2 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty2 linux root 2610 0.0 0.0 14296 836 tty3 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty3 linux root 2611 0.0 0.0 14296 836 tty4 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty4 linux root 2612 0.0 0.0 14296 836 tty5 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty5 linux root 2613 0.0 0.0 14296 832 tty6 Ss+ 15:18 0:00 /sbin/agetty --noclear 38400 tty6 linux root 2614 0.0 0.0 9232 1256 ?Ss 15:18 0:00 /bin/sh /command/svscanboot root 2616 0.0 0.0 3916 448 ?S15:18 0:00 \_ svscan /service root 2629 0.0 0.0 3744 392 ?S15:18 0:00 | \_ supervise php-fpm root 2630 0.0 0.0 3744 292 ?S15:18 0:00 | \_ supervise log root 2617 0.0 0.0 3732 296 ?S15:18 0:00 \_ readproctitle service errors: root 4595 0.0 0.0 58316 1636 tty1 Ss 16:23 0:00 /bin/login -- root 4596 0.2 0.1 21104 3364 tty1 S16:23 0:00 \_ -bash root 4635 0.0 0.0 11252 1344 tty1 S+ 16:25 0:00 \_ /bin/sh -x ./fpm-test.sh root 4639 0.0 0.0 16936 1088 tty1 R+ 16:25 0:00 \_ ps axfu --- --- Step 2: Start service. --- # svc -u /service/php-fpm/log /service/php-fpm # sleep 10 # ps axfu USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 2 0.0 0.0 0 0 ?S15:18 0:00 [kthreadd] root 1 0.0 0.0 3892 712 ?Ss 15:18 0:00 init [3] root 876 0.0 0.0 12516 860 ?Ss 15:18 0:00 /sbin/udevd --daemon root 1375 0.0 0.0 12512 812 ?S 15:18 0:00 \_ /sbin/udevd --daemon root 1376 0.0 0.0 12512 812 ?S 15:18 0:00 \_ /sbin/udevd --daemon root 2592 0.0 0.0 18464 808 ?Ss 15:18 0:00 /usr/sbin/cron root 2609 0.0 0.0 14296 828 tty2 Ss+
Bug #59976 [Opn-Csd]: [NEEDS PATCH] svn build fails on PHP5.4 (OSX maybe others)
Edit report at https://bugs.php.net/bug.php?id=59976edit=1 ID: 59976 Updated by: fel...@php.net Reported by:shal at semantic-fidelity dot org Summary:[NEEDS PATCH] svn build fails on PHP5.4 (OSX maybe others) -Status: Open +Status: Closed Type: Bug Package:svn Operating System: MacOSX 10.6.8 PHP Version:5_4 SVN-2011-09-29 (dev) -Assigned To: +Assigned To:felipe Block user comment: N Private report: N New Comment: Fixed in svn. Thanks. Previous Comments: [2011-09-29 14:40:18] shal at semantic-fidelity dot org The same package works like a charm with PHP 5.3.8 (there are various warning messages about use of deprecated functions but executing `make` produces the actual extension) [2011-09-29 10:27:39] shal at semantic-fidelity dot org Apparently, the ZEND API version of PHP 5.4 enables the execution of a snippet of code which might be responsible for raising an error [2011-09-29 08:44:20] shal at semantic-fidelity dot org I have Subversion 1.6.16 and I've also tried with 1.6.17 and the output tells there's an error in svn.c (which most likely belongs to the pecl package) [2011-09-29 08:11:15] shal at semantic-fidelity dot org Description: after passing paths to Subversion prefix and APR installation used with Subversion, `make` after `configure` would not succeed Expected result: compilation success Actual result: -- cc -I/usr/include/subversion-1 - I/opt/subversion/include/apr-1 -DDARWIN - DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I. - I/private/tmp/pear/temp/svn -DPHP_ATOM_INC - I/private/tmp/pear/temp/pear-build-rootU9asYo/svn- 1.0.1/include -I/private/tmp/pear/temp/pear-build- rootU9asYo/svn-1.0.1/main -I/private/tmp/pear/temp/svn - I/opt/local/bin/php-5.4-dev/include/php - I/opt/local/bin/php-5.4-dev/include/php/main - I/opt/local/bin/php-5.4-dev/include/php/TSRM - I/opt/local/bin/php-5.4-dev/include/php/Zend - I/opt/local/bin/php-5.4-dev/include/php/ext - I/opt/local/bin/php-5.4-dev/include/php/ext/date/lib - I/usr/include/subversion-1 -I/opt/subversion/include/apr-1 - DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp - DHAVE_CONFIG_H -g -O2 -c /private/tmp/pear/temp/svn/svn.c - fno-common -DPIC -o .libs/svn.o /private/tmp/pear/temp/svn/svn.c:126: error: expected =, ,, ;, asm or __attribute__ before svn_methods /private/tmp/pear/temp/svn/svn.c:137: error: expected =, ,, ;, asm or __attribute__ before svn_functions /private/tmp/pear/temp/svn/svn.c:207: error: svn_functions undeclared here (not in a function) /private/tmp/pear/temp/svn/svn.c: In function php_svn_handle_error: /private/tmp/pear/temp/svn/svn.c:273: warning: format not a string literal and no format arguments /private/tmp/pear/temp/svn/svn.c: In function init_svn_client: /private/tmp/pear/temp/svn/svn.c:350: warning: svn_client_get_simple_provider is deprecated (declared at /usr/include/subversion-1/svn_client.h:161) /private/tmp/pear/temp/svn/svn.c:353: warning: svn_client_get_username_provider is deprecated (declared at /usr/include/subversion-1/svn_client.h:208) /private/tmp/pear/temp/svn/svn.c:356: warning: svn_client_get_ssl_server_trust_prompt_provider is deprecated (declared at /usr/include/subversion- 1/svn_client.h:278) /private/tmp/pear/temp/svn/svn.c:360: warning: svn_client_get_ssl_server_trust_file_provider is deprecated (declared at /usr/include/subversion- 1/svn_client.h:225) /private/tmp/pear/temp/svn/svn.c:363: warning: svn_client_get_ssl_client_cert_file_provider is deprecated (declared at /usr/include/subversion-1/svn_client.h:242) /private/tmp/pear/temp/svn/svn.c:366: warning: svn_client_get_ssl_client_cert_pw_file_provider is deprecated (declared at /usr/include/subversion- 1/svn_client.h:259) /private/tmp/pear/temp/svn/svn.c: In function zif_svn_import: /private/tmp/pear/temp/svn/svn.c:493: warning: svn_client_import is deprecated (declared at /usr/include/subversion-1/svn_client.h:1654) /private/tmp/pear/temp/svn/svn.c: In function zm_startup_svn: /private/tmp/pear/temp/svn/svn.c:527: error: svn_methods undeclared (first use in this function) /private/tmp/pear/temp/svn/svn.c:527: error: (Each undeclared identifier is reported only once /private/tmp/pear/temp/svn/svn.c:527: error: for each function it appears in.) -- Edit this bug report at https://bugs.php.net/bug.php?id=59976edit=1
Bug #59866 [Opn-Csd]: http_api.c:256: error: too few arguments to function 'php_ob_handler_used
Edit report at https://bugs.php.net/bug.php?id=59866edit=1 ID: 59866 Updated by: fel...@php.net Reported by:mattsch at gmail dot com Summary:http_api.c:256: error: too few arguments to function 'php_ob_handler_used -Status: Open +Status: Closed Type: Bug Package:pecl_http Operating System: Gentoo Linux PHP Version:5.3.6 -Assigned To: +Assigned To:felipe Block user comment: N Private report: N New Comment: Try a newer version. Previous Comments: [2011-08-23 06:34:56] bombadil at bosqueviejo dot net Versión 1.7.0 works fine. You can write this: pecl install pecl_http-1.7.0 to install it. [2011-07-22 11:11:22] mattsch at gmail dot com Description: pecl-http-1.7.1 refuses to compile with either php 5.2 or php 5.3: /var/tmp/portage/dev-php5/pecl-http-1.7.1/work/php5.3/http_api.c: In function '_http_exit_ex': /var/tmp/portage/dev-php5/pecl-http-1.7.1/work/php5.3/http_api.c:256: error: too few arguments to function 'php_ob_handler_used' /var/tmp/portage/dev-php5/pecl-http-1.7.1/work/php5.3/http_api.c:256: error: too few arguments to function 'php_ob_handler_used' make: *** [http_api.lo] Error 1 make: *** Waiting for unfinished jobs Additional information (environmenent, etc): https://bugs.gentoo.org/show_bug.cgi?id=368595 Expected result: pecl-http compiles Actual result: -- pecl-http does not compile -- Edit this bug report at https://bugs.php.net/bug.php?id=59866edit=1
Bug #59933 [Opn-Asn]: problem in dbus.c:1860
Edit report at https://bugs.php.net/bug.php?id=59933edit=1 ID: 59933 Updated by: fel...@php.net Reported by:chenwen at fiberlogic dot com Summary:problem in dbus.c:1860 -Status: Open +Status: Assigned Type: Bug Package:DBus Operating System: linux PHP Version:5.2.17 -Assigned To: +Assigned To:derick Block user comment: N Private report: N Previous Comments: [2011-09-06 08:39:59] yc_huang at fiberlogic dot com The key point is not using char[8] or dbus_int64_t to store. It should do type casting by pointer way rather than type casting directly to avoid the endian problem. Here is a patch can work well on mips, x86 and x64 platform: http://codepad.org/8hp25Mfo [2011-09-02 07:41:37] chenwen at fiberlogic dot com Description: In dbus.c:1860 I suggest that we should use char stat[8] instead of dbus_int64_t stat. Just like dbus document says: On some really obscure platforms dbus_uint64_t might not exist This code was broken in my MIPS(BE) machine. ref: http://dbus.freedesktop.org/doc/api/html/group__DBusMessage.h tml#ga41c23a05e552d0574d0444d4693d18ab -- Edit this bug report at https://bugs.php.net/bug.php?id=59933edit=1
Bug #59934 [Opn-Csd]: Compilation fails
Edit report at https://bugs.php.net/bug.php?id=59934edit=1
ID: 59934
Updated by: fel...@php.net
Reported by:arjenjb at gmail dot com
Summary:Compilation fails
-Status: Open
+Status: Closed
Type: Bug
Package:solr
Operating System: Windows
PHP Version:Irrelevant
-Assigned To:
+Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
Fixed in SVN.
Thanks.
Previous Comments:
[2011-09-03 12:28:47] arjenjb at gmail dot com
Description:
Cannot compile solr on windows using the instructions found
at: https://wiki.php.net/internals/windows/stepbystepbuild.
'nmake' gives me the following error:
..\pecl\solr\solr_functions_helpers.c(1115) : error C2059:
syntax error : '}'
NMAKE : fatal error U1077: 'C:\Program Files
(x86)\Microsoft Visual Studio 9.0\VC\Bin\cl.exe' : return
code '0x2'
Stop.
The following patch fixes the problem:
===
--- solr_functions_helpers.c(revision 316077)
+++ solr_functions_helpers.c(working copy)
@@ -1112,7 +1112,7 @@
HashTable *global_function_table =
EG(function_table);
/* json_last_error() */
- zval *json_last_error_params[] = { };
+ zval *json_last_error_params[] = { NULL };
json_decode_ret_val_ptr = json_decode_ret_val;
--
Edit this bug report at https://bugs.php.net/bug.php?id=59934edit=1
Bug #59909 [Opn-Asn]: Gearman Workers Run Away causing gearmand cpu load to 99%
Edit report at https://bugs.php.net/bug.php?id=59909edit=1
ID: 59909
Updated by: fel...@php.net
Reported by:mike at digitalstruct dot com
Summary:Gearman Workers Run Away causing gearmand cpu load
to 99%
-Status: Open
+Status: Assigned
Type: Bug
Package:gearman
Operating System: RHEL 5.6
PHP Version:5.3.5
Assigned To:hradtke
Block user comment: N
Private report: N
Previous Comments:
[2011-08-22 22:50:51] mike at digitalstruct dot com
Unfortunately it is extremely hard to rule out either the
extension or libgearman at this point. I've gone back and
forth between both areas but I do not see any clear
definition between the two in where it is breaking.
Any ideas to help diagnose?
[2011-08-22 20:07:36] hrad...@php.net
Did we rule out libgearman?
[2011-08-22 17:12:36] mike at digitalstruct dot com
Description:
See the following bug report:
https://bugs.launchpad.net/gearmand/+bug/802850
It seems like it happens at random and only under heavier
load. When the workers are killed the server returns to
normal and
after the restart of the worker it seems to function fine.
What I've noticed is two main things between a working worker
and a non-working worker (basically when things are fried).
The
working ones block and the non-working ones stop blocking but
simply DDoS the gearmand process.
Expected result:
I would think that the duration of time should not matter
that the worker is running. The fact that it stops blocking
should never happen while it is sitting in it's while loop.
The fact that it DDoS the gearmand process means that it is
likely losing some pointer to the connection and unable to
resolve itself. It does not give any useful error message
but continues in the way above until killed.
Actual result:
--
Working:
poll([{fd=13, events=POLLIN}], 1, 1000) = 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
sendto(13, \0REQ\0\0\0'\0\0\0\0, 12, MSG_NOSIGNAL, NULL,
0) = 12
recvfrom(13, \0RES\0\0\0\n\0\0\0\0, 8192, 0, NULL, NULL) =
12
sendto(13, \0REQ\0\0\0\4\0\0\0\0, 12, MSG_NOSIGNAL, NULL,
0) = 12
poll([{fd=13, events=POLLIN}], 1, 1000 unfinished ...
Non-Working:
getsockopt(13, SOL_SOCKET, SO_ERROR, [284636038280773632],
[4]) = 0
sendto(13, \0REQ\0\0\0'\0\0\0\0, 12, MSG_NOSIGNAL, NULL,
0) = 12
sendto(13, \0REQ\0\0\0\4\0\0\0\0, 12, MSG_NOSIGNAL, NULL,
0) = 12
poll([{fd=13, events=POLLIN}], 1, 1000) = 1 ([{fd=13,
revents=POLLIN}])
getsockopt(13, SOL_SOCKET, SO_ERROR, [284636038280773632],
[4]) = 0
sendto(13, \0REQ\0\0\0'\0\0\0\0, 12, MSG_NOSIGNAL, NULL, 0
unfinished ...
--
Edit this bug report at https://bugs.php.net/bug.php?id=59909edit=1
Bug #59866 [Com]: http_api.c:256: error: too few arguments to function 'php_ob_handler_used
Edit report at https://bugs.php.net/bug.php?id=59866edit=1 ID: 59866 Comment by: mattsch at gmail dot com Reported by:mattsch at gmail dot com Summary:http_api.c:256: error: too few arguments to function 'php_ob_handler_used Status: Closed Type: Bug Package:pecl_http Operating System: Gentoo Linux PHP Version:5.3.6 Assigned To:felipe Block user comment: N Private report: N New Comment: Which version is it fixed in? I don't see any new stable version. Previous Comments: [2011-10-12 21:22:23] fel...@php.net Try a newer version. [2011-08-23 06:34:56] bombadil at bosqueviejo dot net Versión 1.7.0 works fine. You can write this: pecl install pecl_http-1.7.0 to install it. [2011-07-22 11:11:22] mattsch at gmail dot com Description: pecl-http-1.7.1 refuses to compile with either php 5.2 or php 5.3: /var/tmp/portage/dev-php5/pecl-http-1.7.1/work/php5.3/http_api.c: In function '_http_exit_ex': /var/tmp/portage/dev-php5/pecl-http-1.7.1/work/php5.3/http_api.c:256: error: too few arguments to function 'php_ob_handler_used' /var/tmp/portage/dev-php5/pecl-http-1.7.1/work/php5.3/http_api.c:256: error: too few arguments to function 'php_ob_handler_used' make: *** [http_api.lo] Error 1 make: *** Waiting for unfinished jobs Additional information (environmenent, etc): https://bugs.gentoo.org/show_bug.cgi?id=368595 Expected result: pecl-http compiles Actual result: -- pecl-http does not compile -- Edit this bug report at https://bugs.php.net/bug.php?id=59866edit=1
Bug #60037 [Com]: The octal interpreter wrongs...
Edit report at https://bugs.php.net/bug.php?id=60037edit=1 ID: 60037 Comment by: anon at anon dot anon Reported by:seinghhaccoski at rocketmail dot com Summary:The octal interpreter wrongs... Status: Bogus Type: Bug Package:*General Issues Operating System: Linux Ubuntu PHP Version:5.3.8 Block user comment: N Private report: N New Comment: You've gotta admit though, even by PHP standards, this is an appalling quirk. Previous Comments: [2011-10-11 22:16:36] fel...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php See the documentation about the behavior with invalid octal numbers: http://docs.php.net/integer Thanks. [2011-10-11 07:59:37] seinghhaccoski at rocketmail dot com Description: The octal interpreter wrongs... Test script: --- echo 010 + 090; Expected result: an error. Actual result: -- 8 -- Edit this bug report at https://bugs.php.net/bug.php?id=60037edit=1
Bug #60038 [PATCH]: SIGALRM cause segfault in php_error_cb
Edit report at https://bugs.php.net/bug.php?id=60038edit=1
ID: 60038
Patch added by: larue...@php.net
Reported by:larue...@php.net
Summary:SIGALRM cause segfault in php_error_cb
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.8
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug60038.patch
Revision: 1318466568
URL:
https://bugs.php.net/patch-display.php?bug=60038patch=bug60038.patchrevision=1318466568
Previous Comments:
[2011-10-11 09:31:54] larue...@php.net
Assign to myself, if there is no objections in ML, I will apply the patch.
[2011-10-11 09:27:18] larue...@php.net
actully, there are two issue about this segfault I have explained before in my
blog: http://www.laruence.com/2011/01/27/1854.html and
http://www.laruence.com/2008/12/31/647.html
so the point is do you think this is worth fixing?
[2011-10-11 09:16:19] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60038.patch
Revision: 1318324579
URL:
https://bugs.php.net/patch-display.php?bug=60038patch=bug60038.patchrevision=1318324579
[2011-10-11 09:13:55] larue...@php.net
Description:
in php_error_cb:
freeing PG(last_error_message) and PG(last_error_file) without blocking alarm
signal.
so there is a chance that php will segfault when max_execution_time limit
reachead.
since zend_signal was introduced in PHP 5.4, so I think it's okey to add
signal
block mechanism for this codes.
Test script:
---
?php
error_reporting(E_ALL|E_NOTICE);
set_time_limit(1);
while(1) {
$a = $arr['index_miss'];
}
?
do following steps:
1. gdb php
2. b php_error_cb
3. r above script
4. when breakpoint reach:
893 if (PG(last_error_message)) {
(gdb)
894 free(PG(last_error_message));
5. signal SIGPROF
6. next (*n)
*** glibc detected *** double free or corruption (fasttop): 0x01207ca0
***
Expected result:
no segfault
Actual result:
--
segfault
--
Edit this bug report at https://bugs.php.net/bug.php?id=60038edit=1
Bug #60038 [Com]: SIGALRM cause segfault in php_error_cb
Edit report at https://bugs.php.net/bug.php?id=60038edit=1
ID: 60038
Comment by: larue...@php.net
Reported by:larue...@php.net
Summary:SIGALRM cause segfault in php_error_cb
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.8
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
updated patch, signal block mechanism only take effect when zend signal enabled.
Previous Comments:
[2011-10-13 00:42:48] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60038.patch
Revision: 1318466568
URL:
https://bugs.php.net/patch-display.php?bug=60038patch=bug60038.patchrevision=1318466568
[2011-10-11 09:31:54] larue...@php.net
Assign to myself, if there is no objections in ML, I will apply the patch.
[2011-10-11 09:27:18] larue...@php.net
actully, there are two issue about this segfault I have explained before in my
blog: http://www.laruence.com/2011/01/27/1854.html and
http://www.laruence.com/2008/12/31/647.html
so the point is do you think this is worth fixing?
[2011-10-11 09:16:19] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60038.patch
Revision: 1318324579
URL:
https://bugs.php.net/patch-display.php?bug=60038patch=bug60038.patchrevision=1318324579
[2011-10-11 09:13:55] larue...@php.net
Description:
in php_error_cb:
freeing PG(last_error_message) and PG(last_error_file) without blocking alarm
signal.
so there is a chance that php will segfault when max_execution_time limit
reachead.
since zend_signal was introduced in PHP 5.4, so I think it's okey to add
signal
block mechanism for this codes.
Test script:
---
?php
error_reporting(E_ALL|E_NOTICE);
set_time_limit(1);
while(1) {
$a = $arr['index_miss'];
}
?
do following steps:
1. gdb php
2. b php_error_cb
3. r above script
4. when breakpoint reach:
893 if (PG(last_error_message)) {
(gdb)
894 free(PG(last_error_message));
5. signal SIGPROF
6. next (*n)
*** glibc detected *** double free or corruption (fasttop): 0x01207ca0
***
Expected result:
no segfault
Actual result:
--
segfault
--
Edit this bug report at https://bugs.php.net/bug.php?id=60038edit=1
Bug #55760 [Com]: Can not load php_ldap.dll
Edit report at https://bugs.php.net/bug.php?id=55760edit=1 ID: 55760 Comment by: ramki067 at gmail dot com Reported by:mod4wb at heysoft dot de Summary:Can not load php_ldap.dll Status: Bogus Type: Bug Package:LDAP related Operating System: Windows PHP Version:5.3.8 Block user comment: N Private report: N New Comment: You have said in your earlier posts as, Add the internet explorer directory to your path. Is this the solution to the problem? If yes, how where should the internet explorer path be added. Please advice. Thanks. Previous Comments: [2011-10-12 10:53:51] paj...@php.net See my previous comment, not much we can do against that. Also to fix your setup is rather easy. [2011-10-12 10:32:07] ramki067 at gmail dot com Same problem here: Installed XAMPP 1.7.7 and enabled extension=php_ldap.dll in php.ini file in C:\xampp\php\php.ini path. After restarting apache, i'm getting an error: php_ldap.dll file could not be loaded. Module could not be found. The package has PHP 5.3.8 version. Is LDAP not supported or the support is not added in this PHP release? or am i missing something? Mods Please reply. Thanks. [2011-09-29 14:25:08] nrenou at free dot fr Same problem : With xampp 1.7.7 on a Windows 2003 Server, if you enable php_ldap.dll, Apache won't start ssleay32.dll, libeay32.dll, libsasl.sll and php5ts.dll are in c:\xampp\php and Apache doesn't start if you don't copy these files into c:\xampp\php\ext (the same folder than php_ldap.dll) Regards [2011-09-22 11:15:46] paj...@php.net And for the record here: it is a dependency of Crypt32.dll which is used by libsasl.dll. [2011-09-22 11:09:51] paj...@php.net Directory of c:\Program Files\Internet Explorer 03/15/2011 09:44 AM 887,296 iedvtool.dll 03/15/2011 09:44 AM 546,816 ieproxy.dll 07/22/2011 07:34 AM 304,640 IEShims.dll 03/15/2011 09:44 AM 498,688 jsdbgui.dll 03/15/2011 09:44 AM 140,800 jsdebuggeride.dll 03/15/2011 09:44 AM66,048 JSProfilerCore.dll 03/15/2011 09:44 AM 194,560 jsprofilerui.dll 06/10/2009 10:30 PM 358,904 msdbg2.dll 03/15/2011 09:44 AM 455,680 networkinspection.dll 03/15/2011 09:44 AM 537,088 pdm.dll 07/22/2011 07:55 AM 174,384 sqmapi.dll 11 File(s) 4,164,904 bytes For any support question please use php-windows or php-install mailing list, bugs.php.net is only about actual issues. Thanks for your attention. 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 https://bugs.php.net/bug.php?id=55760 -- Edit this bug report at https://bugs.php.net/bug.php?id=55760edit=1
[PHP-BUG] Bug #60047 [NEW]: allow_url_fopen has inconsistent 'Changable' locations
From: Operating system: N/A PHP version: Irrelevant Package: Documentation problem Bug Type: Bug Bug description:allow_url_fopen has inconsistent 'Changable' locations Description: allow_url_fopen is listed as having a Changable mode of PHP_INI_ALL on http://www.php.net/manual/en/ini.list.php and a Changeable mode of PHP_INI_SYSTEM on http://www.php.net/manual/en/filesystem.configuration.php. There is also a 'Note:' which says This setting can only be set in php.ini due to security reasons. on the latter page. I believe the listing on http://www.php.net/manual/en/filesystem.configuration.php is correct and the note is incorrect (at least in PHP 5.1.6). This information should be propagated to the main list and the note removed if this is the case. Test script: --- Visit each website Expected result: They are consistent in where allow_url_fopen is allowed to be changed. Actual result: -- They are not consistent in where allow_url_fopen is allowed to be changed. -- Edit bug report at https://bugs.php.net/bug.php?id=60047edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60047r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60047r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60047r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60047r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60047r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60047r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60047r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60047r=needscript Try newer version: https://bugs.php.net/fix.php?id=60047r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60047r=support Expected behavior: https://bugs.php.net/fix.php?id=60047r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60047r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60047r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60047r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60047r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60047r=dst IIS Stability: https://bugs.php.net/fix.php?id=60047r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60047r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60047r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60047r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60047r=mysqlcfg
