#49993 [Bgs]: switch: default is triggering every time
ID: 49993
Updated by: s...@php.net
Reported By: sworddragon2 at aol dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP Professional SP3
PHP Version: 5.3.0
New Comment:
Hint: read what Rasmus wrote about "hint."
Previous Comments:
[2009-10-26 00:27:10] sworddragon2 at aol dot com
I have allready read the documentation. Maybe it's a misunderstanding
because the switch documentation isn't translated in my language but the
documentation says the following:
A special case is the default case. This case matches anything that
wasn't matched by the other cases. For example:
If this issue is working correctly the documentation is wrong i think.
[2009-10-25 23:35:50] ras...@php.net
Please read the documentation on switch/case (for any language)
carefully. This is expected behaviour. Hint, read about "break".
[2009-10-25 23:33:08] sworddragon2 at aol dot com
Description:
In this example default is triggering although the case statement is
triggering before.
Reproduce code:
---
switch(1)
{
case 1: echo "case 1: triggered\n";
default: echo 'default: triggered';
}
Expected result:
case 1: triggered
Actual result:
--
case 1: triggered
default: triggered
--
Edit this bug report at http://bugs.php.net/?id=49993&edit=1
#49195 [Fbk->Csd]: cannot call mysql functions although mysql ext. installed
ID: 49195 User updated by: sean dot everlast at gmail dot com Reported By: sean dot everlast at gmail dot com -Status: Feedback +Status: Closed Bug Type: MySQL related Operating System: Fedora Core 9 2.6.25-14.fc9.i686 PHP Version: 5.2SVN-2009-08-08 (snap) New Comment: It's really weird, sometimes it's happening, but a server restart gets it fixed until the next one. Since I'm only using PHP for some backend cron jobs, will probably switch to perl. Previous Comments: [2009-08-12 05:14:33] erikhartog at yahoo dot com This error occurred for me on the install of version 5.2.10. I noticed that my Windows installer did not upgrade the ext directory to the 5.2.10 versions. Once I manually installed the correct ext libraries all of the files worked. It seems the installer was not properly modified. [2009-08-09 14:52:41] j...@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. ---- [2009-08-08 05:01:23] sean dot everlast at gmail dot com Description: Fatal error: Call to undefined function mysql_connect() in. mysql extension is installed properly. yes, I'm positively 100% sure it is. Reproduce code: --- http://bugs.php.net/?id=49195&edit=1
#49195 [NEW]: cannot call mysql functions although mysql ext. installed
From: sean dot everlast at gmail dot com Operating system: Fedora Core 9 2.6.25-14.fc9.i686 PHP version: 5.2SVN-2009-08-08 (snap) PHP Bug Type: MySQL related Bug description: cannot call mysql functions although mysql ext. installed Description: Fatal error: Call to undefined function mysql_connect() in. mysql extension is installed properly. yes, I'm positively 100% sure it is. Reproduce code: --- http://bugs.php.net/?id=49195&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49195&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49195&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49195&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49195&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49195&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49195&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49195&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49195&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49195&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49195&r=support Expected behavior: http://bugs.php.net/fix.php?id=49195&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49195&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49195&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49195&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49195&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49195&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49195&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49195&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49195&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49195&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49195&r=mysqlcfg
#48305 [NEW]: SORT_VERSION for sort functions
From: sean at wdsolutions dot com
Operating system: Linux
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: SORT_VERSION for sort functions
Description:
It would be awesome to have a SORT_VERSION flag for the sort family of
functions, whose behavior would be to sort most common multi-number version
strings (with possible support for detecting -cvs, -rc, -svn, and other
suffixes).
For example, SORT_NUMERIC and SORT_STRING both fail to properly sort the
following version numbers:
1.2.1
1.2.2
1.2.10
1.20.5
1.22.50
They get sorted as:
1.20.5
1.2.1
1.2.10
1.2.2
1.22.50
Code I used to work around it is below:
Reproduce code:
---
function vercmp($a, $b) {
$as = explode('.', $a);
$bs = explode('.', $b);
for ($i = 0, $e = max(count($as), count($bs)); $i != $e; ++$i) {
if ($as[$i] < $bs[$i])
return -1;
elseif ($as[$i] > $bs[$i])
return 1;
}
return 0;
}
--
Edit bug report at http://bugs.php.net/?id=48305&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48305&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48305&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48305&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48305&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48305&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48305&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48305&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48305&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48305&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48305&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48305&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48305&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48305&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48305&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48305&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48305&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48305&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48305&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48305&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48305&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48305&r=mysqlcfg
#48205 [Bgs]: RecursiveIteratorIterator->callGetChildren() raises InvalidArgumentException
ID: 48205
User updated by: sean at practicalweb dot co dot uk
Reported By: sean at practicalweb dot co dot uk
Status: Bogus
Bug Type: SPL related
Operating System: *
PHP Version: 5.*, 6CVS (2009-05-09)
New Comment:
Hi,
I should have included the error message in the bug report.
It reads:
"Passed variable is not an array or object, using empty array instead"
I can understand throwing an exception here, but neither the type of
exception nor message make much sense to me.
The error is cause by using callGetChildren() on an item that has no
children - but the exception and message are about invalid arguments.
I can see how this happens from the php source - but it doesn't
helpfully reflect the error the user has made.
Would it be possible to have a new class of error and a message that
says something like "getChildren called on an object with no children" ?
Previous Comments:
[2009-05-09 20:36:19] col...@php.net
That's expected, callGetChildren will call
RecursiveArrayIterator::getChildren when the current element is an
integer. getChildren will then instantiate an ArrayIterator object, and
pass the current element as argument, resulting in an exception since
it's not an array or an object.
[2009-05-09 19:18:42] j...@php.net
Please, when you do testing, test with PHP_5_2 also and HEAD. And set
the version string like I did now in case the bug exists in all
branches..
----
[2009-05-09 13:52:57] sean at practicalweb dot co dot uk
Description:
If the current element of a RecursiveIteratorIterator has no children
then callGetChildren() causes an error message like
Fatal error: Uncaught exception 'InvalidArgumentException' with message
'Passed variable is not an array or object, using empty array instead'
This is confusing because the PHP code does not pass an argument here.
I think that either the method should return null when there are no
children - or at least the error message could be clearer.
This has been found as part of phptestfest 09 - an XFail test will be
commited from PHPLondon
My Apologies if this is expected behaviour, I realise the code is
undocumented, but I wanted to commit a test to cover this and filing a
bug seemed the best way to confirm one way or the other :-)
Reproduce code:
---
current());
$test->next();
var_dump($test->current());
try {
$output = $test->callGetChildren();
} catch (InvalidArgumentException $ilae){
$output = null;
print "invalid argument exception\n";
}
var_dump($output);
?>
Expected result:
array(3) {
[0]=>
int(7)
[1]=>
int(8)
[2]=>
int(9)
}
int(7)
NULL
Actual result:
--
array(3) {
[0]=>
int(7)
[1]=>
int(8)
[2]=>
int(9)
}
int(7)
invalid argument exception
NULL
--
Edit this bug report at http://bugs.php.net/?id=48205&edit=1
#48205 [NEW]: RecursiveIteratorIterator->callGetChildren() raises InvalidArgumentException
From: sean at practicalweb dot co dot uk
Operating system: Linux
PHP version: 5.3CVS-2009-05-09 (snap)
PHP Bug Type: SPL related
Bug description: RecursiveIteratorIterator->callGetChildren() raises
InvalidArgumentException
Description:
If the current element of a RecursiveIteratorIterator has no children then
callGetChildren() causes an error message like
Fatal error: Uncaught exception 'InvalidArgumentException' with message
'Passed variable is not an array or object, using empty array instead'
This is confusing because the PHP code does not pass an argument here.
I think that either the method should return null when there are no
children - or at least the error message could be clearer.
This has been found as part of phptestfest 09 - an XFail test will be
commited from PHPLondon
My Apologies if this is expected behaviour, I realise the code is
undocumented, but I wanted to commit a test to cover this and filing a bug
seemed the best way to confirm one way or the other :-)
Reproduce code:
---
current());
$test->next();
var_dump($test->current());
try {
$output = $test->callGetChildren();
} catch (InvalidArgumentException $ilae){
$output = null;
print "invalid argument exception\n";
}
var_dump($output);
?>
Expected result:
array(3) {
[0]=>
int(7)
[1]=>
int(8)
[2]=>
int(9)
}
int(7)
NULL
Actual result:
--
array(3) {
[0]=>
int(7)
[1]=>
int(8)
[2]=>
int(9)
}
int(7)
invalid argument exception
NULL
--
Edit bug report at http://bugs.php.net/?id=48205&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48205&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48205&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48205&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48205&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48205&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48205&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48205&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48205&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48205&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48205&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48205&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48205&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48205&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48205&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48205&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48205&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48205&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48205&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48205&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48205&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48205&r=mysqlcfg
#43592 [Com]: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing
ID: 43592
Comment by: sean at choonz dot com
Reported By: will at willspc dot net
Status: No Feedback
Bug Type: Compile Failure
Operating System: Linux 2.6.9-55.0.6.EL
PHP Version: 5.2.5
New Comment:
So the way I fixed this on 5.2.8 was simply to run
> sudo yum install libc-client-devel
and configure again
and then it worked. hope this helps someone!
Previous Comments:
[2009-01-22 03:06:15] sean at choonz dot com
Yes, the same problem installing php-5.2.8
on
Linux Redhat 2.6.18-xenU #1 SMP Thu Oct 4 12:23:41 BST 2007 x86_64
x86_64 x86_64 GNU/Linux
The last lines of config.log are:
##
configure:47185: checking for IMAP support
configure:47232: checking for IMAP Kerberos support
configure:47258: checking for IMAP SSL support
configure:47663:19: /mail.h: No such file or directory
configure:47682: checking for utf8_mime2text signature
configure:47700: gcc -c -I conftest.c 1>&5
gcc: no input files
configure: failed program was:
#line 47687 "configure"
#include "confdefs.h"
#include
#include
int main() {
SIZEDTEXT *src, *dst;
utf8_mime2text(src, dst);
; return 0; }
configure:47729: checking for U8T_CANONICAL
configure:47745: gcc -c -I conftest.c 1>&5
gcc: no input files
configure: failed program was:
#line 47734 "configure"
#include "confdefs.h"
#include
int main() {
int i = U8T_CANONICAL;
; return 0; }
##
I'm urgently trying to install php5 on my box but this is a blocker.
[2008-08-13 09:56:07] tkevans at tkevans dot com
Sorry, I meant Solaris 9, not Solaris 8.
[2008-08-13 09:54:58] tkevans at tkevans dot com
This error also occurs with Solaris 8 and PHP 4.4.9 (not seen in 4.4.7,
the last version I successfully built).
[2007-12-25 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-12-17 10:02:47] sni...@php.net
How did you install the c-client library? What OS are you using?
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/43592
--
Edit this bug report at http://bugs.php.net/?id=43592&edit=1
#43592 [Com]: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing
ID: 43592
Comment by: sean at choonz dot com
Reported By: will at willspc dot net
Status: No Feedback
Bug Type: Compile Failure
Operating System: Linux 2.6.9-55.0.6.EL
PHP Version: 5.2.5
New Comment:
Yes, the same problem installing php-5.2.8
on
Linux Redhat 2.6.18-xenU #1 SMP Thu Oct 4 12:23:41 BST 2007 x86_64
x86_64 x86_64 GNU/Linux
The last lines of config.log are:
##
configure:47185: checking for IMAP support
configure:47232: checking for IMAP Kerberos support
configure:47258: checking for IMAP SSL support
configure:47663:19: /mail.h: No such file or directory
configure:47682: checking for utf8_mime2text signature
configure:47700: gcc -c -I conftest.c 1>&5
gcc: no input files
configure: failed program was:
#line 47687 "configure"
#include "confdefs.h"
#include
#include
int main() {
SIZEDTEXT *src, *dst;
utf8_mime2text(src, dst);
; return 0; }
configure:47729: checking for U8T_CANONICAL
configure:47745: gcc -c -I conftest.c 1>&5
gcc: no input files
configure: failed program was:
#line 47734 "configure"
#include "confdefs.h"
#include
int main() {
int i = U8T_CANONICAL;
; return 0; }
##
I'm urgently trying to install php5 on my box but this is a blocker.
Previous Comments:
[2008-08-13 09:56:07] tkevans at tkevans dot com
Sorry, I meant Solaris 9, not Solaris 8.
[2008-08-13 09:54:58] tkevans at tkevans dot com
This error also occurs with Solaris 8 and PHP 4.4.9 (not seen in 4.4.7,
the last version I successfully built).
[2007-12-25 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-12-17 10:02:47] sni...@php.net
How did you install the c-client library? What OS are you using?
[2007-12-14 01:50:29] will at willspc dot net
Description:
5.2.5 does not build because it's missing the definition of
"U8T_CANONICAL" in the imap extension.
I checked utf8.h on my system (buried in perl) and it does not have
U8T_CANONICAL.
I'm using a CENTOS/BlueQuartz box, which uses a DoveCot implementation
of imap.
Oddly enough, I originally tried using the exact configure command for
4.3.9, according to phpinfo (which was originally installed) and it did
not build. I'm having to install many libraries to get it to work.
Reproduce code:
---
./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu
--target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include
--libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/usr/com --mandir=/usr/share/man
--infodir=/usr/share/info --cache-file=../config.cache
--with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d
--enable-force-cgi-redirect --disable-debug --enable-pic --disable-rpath
--enable-inline-optimization --with-bz2 --with-db4=/usr --with-curl
--with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr
--with-gd=shared --enable-gd-native-ttf --without-gdbm --with-gettext
--with-ncurses=shared --with-gmp --with-iconv --with-jpeg-dir=/usr
--with-openssl --with-png --with-pspell --with-xml --with-expat-dir=/usr
--with-dom=shared,/usr --with-dom-xslt=/usr --with-dom-exslt=/usr
--with-xmlrpc=shared --with-pcre-regex=/usr --with-zlib=/usr
--with-layout=GNU --enable-bcmath --enable-exif --enable-ftp
--enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm
--enable-track-vars --enable-trans-sid --enable-yp --enable-wddx
--with-pear=/usr/share/pear --with-imap=shared --with-imap-ssl
--with-kerberos --with-ldap=shared --with-mysql=shared,/usr
--with-pgsql=shared --with-snmp=shared,/usr --with-snmp=shared
--enable-ucd-snmp-hack --with-unixODBC=shared,/usr --enable-memory-limit
--enable-shmop --enable-calendar --enable-dbx --enable-dio
--enable-mbstring=shared --enable-mbstr-enc-trans --enable-mbregex
--with-mime-magic=/usr/share/file/magic.mime
Expected result:
I expect configure to succeed.
Actual result:
--
checking if your cpp allows macro usage in include lines... yes
checking for IMAP support... yes, shared
checking for IMAP Kerberos support... yes
checking for IMAP SSL support.
#46819 [NEW]: Getting £ when using
From: sean dot s at superior dot co dot uk Operating system: PHP version: 5.2.8 PHP Bug Type: *General Issues Bug description: Getting £ when using Description: Im inserting tables into my php document using the simple But it wont display the £ symbol on its own? It puts  before every £ symbol? appears like this £. Is this a bug? Reproduce code: --- -- price.php POSTERS 50 100 250 500 1,000 2,500 5,000 10,000 Leadtime A4 Poster £372 £393 £474 £649 £904 £1,300 £2,300 £3,900 3 days A3 Poster £372 £450 £580 £720 £1,100 £1,400 £2,333 £4,600 3 days A2 Poster £372 £575 £630 £823 £1,211 £1,500 £2,522 £7,200 5 days A1 Poster £372 £600 £711 £915 £1,400 £1,893 £2,601 £8,400 5 days Expected result: £1.99 Actual result: -- £1.99 -- Edit bug report at http://bugs.php.net/?id=46819&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46819&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46819&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46819&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46819&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46819&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46819&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46819&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46819&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46819&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46819&r=support Expected behavior: http://bugs.php.net/fix.php?id=46819&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46819&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46819&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46819&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46819&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46819&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46819&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46819&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46819&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46819&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46819&r=mysqlcfg
#43452 [Opn]: strtotime returns wrong date when requested day is same as first day of the mon
ID: 43452
User updated by: sean dot thorne at gmail dot com
Reported By: sean dot thorne at gmail dot com
Status: Open
Bug Type: Date/time related
Operating System: Mac OS X 10.4.11
PHP Version: 5.2CVS-2007-11-29 (CVS)
New Comment:
I ended up writing a compensator for the problem, because it appears
that the PHP Dev crew has better things to do then clean up the code
base...
I kept it simple and grabbed what day was the the first of the month
and then found where Thursday would be in comparison and knew the third
thursday was just 3 times whatever the date of the first thursday.
Previous Comments:
[2008-03-30 22:21:21] billyt at claritytech dot com
This is still a problem with 5.2.6RC4-dev!!!
This is causing us serious issues ... any ideas???
[2007-11-29 15:39:52] sean dot thorne at gmail dot com
Description:
When asking strtotime for the 3rd thursday in a month and the first day
of that month is thursday, it ignores the first thursday. It then begins
to count after that first Thursday and returns the fourth Thursday.
Reproduce code:
---
$day = strtotime("3 Thursday Nov 2007");
echo date("m-d-Y", $day);
Expected result:
11-15-2007
Actual result:
--
11-22-2007
--
Edit this bug report at http://bugs.php.net/?id=43452&edit=1
#43639 [Com]: php-5.2.5-win32-installer.msi stops before it is finished.
ID: 43639 Comment by: sean dot mccleary at gmail dot com Reported By: erik dot kullberg at telia dot com Status: No Feedback Bug Type: *General Issues Operating System: Windows Vista PHP Version: 5.2.5 New Comment: Found a work-around. Create a batch file to run the installer, and run the batch file as administrator. Batch file should contain the single line: msiexec /i C:\php-5.2.5-win32-installer.msi Save it, right-click on it, run as administrator. Previous Comments: [2008-01-06 12:53:48] sean dot mccleary at gmail dot com Same problem with 5.2.6-dev, by the way. [2008-01-06 12:49:30] sean dot mccleary at gmail dot com Same problem here. More info from the Windows event viewer: Product: PHP 5.2.5 -- Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action unconfigApache script error -2146828218, Microsoft VBScript runtime error: Permission denied Line 142, Column 5, [2007-12-30 01:00:02] 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-12-24 13:31:07] lehelkovach at hotmail dot com I also have the same problem having Vista Home Premium 32bit. I tried the installer provided in the reply but i got the same problem of the script not being able to run. [2007-12-22 17:12:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi 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/43639 -- Edit this bug report at http://bugs.php.net/?id=43639&edit=1
#43639 [Com]: php-5.2.5-win32-installer.msi stops before it is finished.
ID: 43639 Comment by: sean dot mccleary at gmail dot com Reported By: erik dot kullberg at telia dot com Status: No Feedback Bug Type: *General Issues Operating System: Windows Vista PHP Version: 5.2.5 New Comment: Same problem with 5.2.6-dev, by the way. Previous Comments: [2008-01-06 12:49:30] sean dot mccleary at gmail dot com Same problem here. More info from the Windows event viewer: Product: PHP 5.2.5 -- Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action unconfigApache script error -2146828218, Microsoft VBScript runtime error: Permission denied Line 142, Column 5, [2007-12-30 01:00:02] 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-12-24 13:31:07] lehelkovach at hotmail dot com I also have the same problem having Vista Home Premium 32bit. I tried the installer provided in the reply but i got the same problem of the script not being able to run. [2007-12-22 17:12:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-12-19 21:17:52] erik dot kullberg at telia dot com Description: I try to install PHP_5.2.5 by use of php-5.2.5-win32-installer.msi, but it stops before it is finished and delivers the following message: "There is a problem with this Windows Installer Package. A script required for this install to complete could not be run. Contact your support personnel or package vendor." I tried to run the installation with the wanted additions (MySQL and GD) and without any additions at all - the result is the same. System: Windows Vista, version 6.0 "Home Premium". Server: Apache 2.2.6 I cannot extract a cure from the answers to those similar questions in the database. Is there one? Or maybe a prognosis for a solution? -- Edit this bug report at http://bugs.php.net/?id=43639&edit=1
#43639 [Com]: php-5.2.5-win32-installer.msi stops before it is finished.
ID: 43639 Comment by: sean dot mccleary at gmail dot com Reported By: erik dot kullberg at telia dot com Status: No Feedback Bug Type: *General Issues Operating System: Windows Vista PHP Version: 5.2.5 New Comment: Same problem here. More info from the Windows event viewer: Product: PHP 5.2.5 -- Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action unconfigApache script error -2146828218, Microsoft VBScript runtime error: Permission denied Line 142, Column 5, Previous Comments: [2007-12-30 01:00:02] 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-12-24 13:31:07] lehelkovach at hotmail dot com I also have the same problem having Vista Home Premium 32bit. I tried the installer provided in the reply but i got the same problem of the script not being able to run. [2007-12-22 17:12:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-12-19 21:17:52] erik dot kullberg at telia dot com Description: I try to install PHP_5.2.5 by use of php-5.2.5-win32-installer.msi, but it stops before it is finished and delivers the following message: "There is a problem with this Windows Installer Package. A script required for this install to complete could not be run. Contact your support personnel or package vendor." I tried to run the installation with the wanted additions (MySQL and GD) and without any additions at all - the result is the same. System: Windows Vista, version 6.0 "Home Premium". Server: Apache 2.2.6 I cannot extract a cure from the answers to those similar questions in the database. Is there one? Or maybe a prognosis for a solution? -- Edit this bug report at http://bugs.php.net/?id=43639&edit=1
#43452 [NEW]: strtotime returns wrong date when requested day is same as first day of the mon
From: sean dot thorne at gmail dot com
Operating system: Mac OS X 10.4.11
PHP version: 5.2CVS-2007-11-29 (CVS)
PHP Bug Type: Date/time related
Bug description: strtotime returns wrong date when requested day is same as
first day of the mon
Description:
When asking strtotime for the 3rd thursday in a month and the first day of
that month is thursday, it ignores the first thursday. It then begins to
count after that first Thursday and returns the fourth Thursday.
Reproduce code:
---
$day = strtotime("3 Thursday Nov 2007");
echo date("m-d-Y", $day);
Expected result:
11-15-2007
Actual result:
--
11-22-2007
--
Edit bug report at http://bugs.php.net/?id=43452&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43452&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43452&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43452&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43452&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43452&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43452&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43452&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43452&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43452&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43452&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43452&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43452&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43452&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43452&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43452&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43452&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43452&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43452&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43452&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43452&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43452&r=mysqlcfg
#32330 [Com]: session_destroy, "Failed to initialize storage module", custom session handler
ID: 32330
Comment by: sean at oteams dot com
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: *
PHP Version: 6CVS, 5CVS, 4CVS (2005-03-17)
New Comment:
I struggled for several days with the "Failed to initialize storage
module: user" problem. I read everything I could find on php.net and
in this bug database. Finally, what solved the problem for me was
this:
Whenever I made a call in my code to session_start(), I used an include
statement to include the following from an include file:
And that did it.
Previous Comments:
[2006-01-16 16:41:52] ajithts at gmail dot com
Hi folks,
I have also had the same problem. My /tmp was not a separate partition
and it had full permissions.
I have then changed session.save_handler to "files" in php.ini.
Initially it was "user". Everything worked perfectly after I have
restarted httpd saving the changes.
Thanks and regards,
Ajith
[2005-06-04 00:25:54] [EMAIL PROTECTED]
PS(mod_data) gets set to NULL with these:
session_write_close(),
session_module_name('foo'),
session_destroy()
[2005-05-21 19:19:42] [EMAIL PROTECTED]
I think you are on the right track mfischer. It looks like PS(mod) and
PS(mod_data) can get out of synch which would cause this. And I think
all the others with seemingly unrelated issues are actually related.
If PS(mod_data) leaks out of the per-request sandbox and infects
subsequent requests all it takes is one application on a server to use
its own session handler and it could affect other seemingly trivial
standalone session apps on that server.
[2005-03-31 16:37:51] evenh+phpbug at pvv dot ntnu dot no
I experienced this one too, but only when using tavi.sourceforge.net.
This intrigued me, and I've developed a little script to give
information related to this issue.
The script at http://tavi.sourceforge.net/bug32330.php shows a counter
which jumps around at it own free will, seemingly. This due to the
changing host underneath, see changing $_SERVER['SERV_ADDR']. The
script always uses /tmp, and it's always writeable, but it's not on the
same computer!
This could be fixed by using a common path, as is done in
http://tavi.sourceforge.net/bug32330fix.php . And now the counter
works, and I don't get the "Failed to initialize..."-message either.
The reason for not getting the message, I've experienced, could be
related to accidentially calling session_start() twice... Either in the
same script, or script running in concurrent time space. Or maybe the
lack of session_write_close()?
Note that both the supplied script would include phpinfo() if adding
"?a" (or anything at all) after the script name. The scripts will be
available for some weeks. Feel free to copy them if needed... ;-)
But the messages seems to have gone away, so I'm happy. For now.
Regards,
Even Holen
[2005-03-17 10:37:29] [EMAIL PROTECTED]
I see that the php_session_destroy() is called in php_session_decode()
too..
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/32330
--
Edit this bug report at http://bugs.php.net/?id=32330&edit=1
#36516 [Opn]: Sybase library names have changed in Sybase 15.x
ID: 36516 User updated by: sean at digitalworkshop dot net Reported By: sean at digitalworkshop dot net Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: Solaris 10 PHP Version: 5.1.2 New Comment: Guys, if you can tell me where to upload files to, I'll happily provide patches to work around the changed library names. I thought I could attach them to this ticket but can't see how right now. Previous Comments: [2006-02-24 18:22:48] sean at digitalworkshop dot net Description: In the new 15.x release of Sybase ASE, they have changed the names of the client library files which the PHP extension links to. Up to and including Sybase ASE 12.5.x, these were: -lcs -lct -lcomn -lintl But now they are: -lsybcs -lsybct -lsybcomn -lsybintl This affects the following files in the PHP build: ./configure ./ext/sybase_ct/config.m4 I have patched the config scripts and successfully built/tested PHP with ASE 15.0 sybase_ct support. I'll attach patch files to this ticket for someone to play with ... the config scripts will need to me modified to check for which version of client library is present and set up the link arguments accordingly. I'll try to help out here if I manage to get some time to work on it! -- Edit this bug report at http://bugs.php.net/?id=36516&edit=1
#36516 [NEW]: Sybase library names have changed in Sybase 15.x
From: sean at digitalworkshop dot net Operating system: Solaris 10 PHP version: 5.1.2 PHP Bug Type: Sybase-ct (ctlib) related Bug description: Sybase library names have changed in Sybase 15.x Description: In the new 15.x release of Sybase ASE, they have changed the names of the client library files which the PHP extension links to. Up to and including Sybase ASE 12.5.x, these were: -lcs -lct -lcomn -lintl But now they are: -lsybcs -lsybct -lsybcomn -lsybintl This affects the following files in the PHP build: ./configure ./ext/sybase_ct/config.m4 I have patched the config scripts and successfully built/tested PHP with ASE 15.0 sybase_ct support. I'll attach patch files to this ticket for someone to play with ... the config scripts will need to me modified to check for which version of client library is present and set up the link arguments accordingly. I'll try to help out here if I manage to get some time to work on it! -- Edit bug report at http://bugs.php.net/?id=36516&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36516&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36516&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36516&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36516&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36516&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36516&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36516&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36516&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36516&r=support Expected behavior:http://bugs.php.net/fix.php?id=36516&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36516&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36516&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36516&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36516&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36516&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36516&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36516&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36516&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36516&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36516&r=mysqlcfg
#34904 [Bgs]: Relocation error in libphp5.so when starting Apache2
ID: 34904 User updated by: sean dot healey at bayernlb dot co dot uk Reported By: sean dot healey at bayernlb dot co dot uk Status: Bogus Bug Type: Sybase-ct (ctlib) related Operating System: Solaris 8 PHP Version: 5.0.5 New Comment: No, perhaps not a bug with PHP itself, but definitely an issue with the build process!! You telling me you're just going to leave Solaris users who need Sybase support swinging in the breeze? I strongly suspect the problem is to do with GCC - which uses the non-Sybase version of the libintl library, but haven't had time to investigate further. Previous Comments: [2005-11-01 11:24:51] [EMAIL PROTECTED] This still isn't PHP bug. [2005-10-27 18:46:49] sean dot healey at bayernlb dot co dot uk Just another thing to note: The following message appears during 'make install' ... "libtool: install: warning: remember to run `libtool --finish /var/build/php-5.0.5/libs'" I would expect to see the message ... -- Libraries have been installed in: /var/build/php-5.0.5/libs If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - use the `-RLIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- ... during the install phase, but this is missing. I presume this is purely informational? Sorry - I know this is unrelated to the above, just thought I should bring it to your attention. ---- [2005-10-27 18:18:23] sean dot healey at bayernlb dot co dot uk I have managed to get around the build problem by sym-linking libintl.so -> libintl.so.1 in the Sybase libraries path. Apache2 now starts with the php5 module configured. This seems to me to be an issue with the PHP build - we have no such problems compiling other CTLIB applications! Please note - the 'duplicate' name of the libintl library is NOT Sybase's problem. Sybase support say that they created that library 'years' before Solaris introduced one of the same name. Bittersweet victory though, because now sybase_connect() won't connect despite the interfaces file being present, correct and configured in php.ini. [2005-10-27 11:30:54] sean dot healey at bayernlb dot co dot uk Whoah! Please don't be misled by the configure script I submitted in this bug report - the LDFLAGS and CPPFLAGS variables were set during my attempts to work around the problem because I originally thought that the build was picking up the wrong libtcl.so. I have since verified that the only copies of this library on my system are under the Sybase paths. It does appear that the wrong libintl.so library is being picked up - it should be using the one under the Sybase path, but is ignoring it and using the one under /usr/lib instead. I have tried this build against both the Sybase 12.0 and 12.5 client libraries with identical results. My original configure script is: #!/usr/bin/sh DSQUERY=fx_dbserver2_ds SYBASE=/dpkg/sybase/sybase12_5 SYBASE_OCS=OCS-12_5 LD_LIBRARY_PATH=$SYBASE/$SYBASE_OCS/lib:/usr/local/lib:$LD_LIBRARY_PATH PATH=/usr/ccs/bin:$PATH export DSQUERY SYBASE SYBASE_OCS LD_LIBRARY_PATH PATH cd php-5.0.5 ./configure \ --prefix=/usr/local/php \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-sybase-ct=$SYBASE/$SYBASE_OCS \ --without-bz2 This produces a libphp5.so which is linked as follows: ldd /usr/local/apache2/modules/libphp5.so libtcl.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libtcl.so libintl.so.1 => /usr/lib/libintl.so.1 libcomn.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcomn.so libct.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libct.so libcs.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcs.so libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libiconv.so.2 => /usr/local/lib/libiconv
#34904 [Opn]: Relocation error in libphp5.so when starting Apache2
ID: 34904 User updated by: sean dot healey at bayernlb dot co dot uk Reported By: sean dot healey at bayernlb dot co dot uk Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: Solaris 8 PHP Version: 5.0.5 New Comment: Just another thing to note: The following message appears during 'make install' ... "libtool: install: warning: remember to run `libtool --finish /var/build/php-5.0.5/libs'" I would expect to see the message ... -- Libraries have been installed in: /var/build/php-5.0.5/libs If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - use the `-RLIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- ... during the install phase, but this is missing. I presume this is purely informational? Sorry - I know this is unrelated to the above, just thought I should bring it to your attention. Previous Comments: [2005-10-27 18:18:23] sean dot healey at bayernlb dot co dot uk I have managed to get around the build problem by sym-linking libintl.so -> libintl.so.1 in the Sybase libraries path. Apache2 now starts with the php5 module configured. This seems to me to be an issue with the PHP build - we have no such problems compiling other CTLIB applications! Please note - the 'duplicate' name of the libintl library is NOT Sybase's problem. Sybase support say that they created that library 'years' before Solaris introduced one of the same name. Bittersweet victory though, because now sybase_connect() won't connect despite the interfaces file being present, correct and configured in php.ini. ---- [2005-10-27 11:30:54] sean dot healey at bayernlb dot co dot uk Whoah! Please don't be misled by the configure script I submitted in this bug report - the LDFLAGS and CPPFLAGS variables were set during my attempts to work around the problem because I originally thought that the build was picking up the wrong libtcl.so. I have since verified that the only copies of this library on my system are under the Sybase paths. It does appear that the wrong libintl.so library is being picked up - it should be using the one under the Sybase path, but is ignoring it and using the one under /usr/lib instead. I have tried this build against both the Sybase 12.0 and 12.5 client libraries with identical results. My original configure script is: #!/usr/bin/sh DSQUERY=fx_dbserver2_ds SYBASE=/dpkg/sybase/sybase12_5 SYBASE_OCS=OCS-12_5 LD_LIBRARY_PATH=$SYBASE/$SYBASE_OCS/lib:/usr/local/lib:$LD_LIBRARY_PATH PATH=/usr/ccs/bin:$PATH export DSQUERY SYBASE SYBASE_OCS LD_LIBRARY_PATH PATH cd php-5.0.5 ./configure \ --prefix=/usr/local/php \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-sybase-ct=$SYBASE/$SYBASE_OCS \ --without-bz2 This produces a libphp5.so which is linked as follows: ldd /usr/local/apache2/modules/libphp5.so libtcl.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libtcl.so libintl.so.1 => /usr/lib/libintl.so.1 libcomn.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcomn.so libct.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libct.so libcs.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcs.so libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 NOTE that the reference to libintl is still linked to the wrong library. I have investigated further and found that libintl.so.1 doesn't exist under the Sybase path - only libintl.so is found there. I need to somehow force the build to pick up the Sybase library instead of the Solaris library.
#34904 [Opn]: Relocation error in libphp5.so when starting Apache2
ID: 34904 User updated by: sean dot healey at bayernlb dot co dot uk Reported By: sean dot healey at bayernlb dot co dot uk Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: Solaris 8 PHP Version: 5.0.5 New Comment: I have managed to get around the build problem by sym-linking libintl.so -> libintl.so.1 in the Sybase libraries path. Apache2 now starts with the php5 module configured. This seems to me to be an issue with the PHP build - we have no such problems compiling other CTLIB applications! Please note - the 'duplicate' name of the libintl library is NOT Sybase's problem. Sybase support say that they created that library 'years' before Solaris introduced one of the same name. Bittersweet victory though, because now sybase_connect() won't connect despite the interfaces file being present, correct and configured in php.ini. Previous Comments: ---- [2005-10-27 11:30:54] sean dot healey at bayernlb dot co dot uk Whoah! Please don't be misled by the configure script I submitted in this bug report - the LDFLAGS and CPPFLAGS variables were set during my attempts to work around the problem because I originally thought that the build was picking up the wrong libtcl.so. I have since verified that the only copies of this library on my system are under the Sybase paths. It does appear that the wrong libintl.so library is being picked up - it should be using the one under the Sybase path, but is ignoring it and using the one under /usr/lib instead. I have tried this build against both the Sybase 12.0 and 12.5 client libraries with identical results. My original configure script is: #!/usr/bin/sh DSQUERY=fx_dbserver2_ds SYBASE=/dpkg/sybase/sybase12_5 SYBASE_OCS=OCS-12_5 LD_LIBRARY_PATH=$SYBASE/$SYBASE_OCS/lib:/usr/local/lib:$LD_LIBRARY_PATH PATH=/usr/ccs/bin:$PATH export DSQUERY SYBASE SYBASE_OCS LD_LIBRARY_PATH PATH cd php-5.0.5 ./configure \ --prefix=/usr/local/php \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-sybase-ct=$SYBASE/$SYBASE_OCS \ --without-bz2 This produces a libphp5.so which is linked as follows: ldd /usr/local/apache2/modules/libphp5.so libtcl.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libtcl.so libintl.so.1 => /usr/lib/libintl.so.1 libcomn.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcomn.so libct.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libct.so libcs.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcs.so libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 NOTE that the reference to libintl is still linked to the wrong library. I have investigated further and found that libintl.so.1 doesn't exist under the Sybase path - only libintl.so is found there. I need to somehow force the build to pick up the Sybase library instead of the Solaris library. A solved case on the Sybase site mentions that the Solaris library /usr/lib/libintl.so.1 has nothing to do with the Sybase library of the same name, which is possibly why the object not found error since my build is linking to the wrong library! [2005-10-26 17:43:50] [EMAIL PROTECTED] Don't try outsmarting the configure. User error -> not PHP bug. [2005-10-18 11:03:24] sean dot healey at bayernlb dot co dot uk Description: I am getting the following error when trying to start Apache2 with the PHP plugin configured: # ./apachectl start Syntax error on line 232 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: ld.so.1: /usr/local/apache2/bin/httpd: fatal: relocation error: file /dpkg/sybase/OCS-12_0/lib/libtcl.so: symbol comn_free: referenced symbol not found When built without Sybase client library, the plugin starts up just fine. The php module DOES appear to be linked against the correct copy of libtcl.so - here are the without-sybase and with-sybase ldd outputs: # ldd libphp5.so.without_sybase libresolv.so.2 =>/usr
#34904 [Bgs->Opn]: Relocation error in libphp5.so when starting Apache2
ID: 34904 User updated by: sean dot healey at bayernlb dot co dot uk Reported By: sean dot healey at bayernlb dot co dot uk -Status: Bogus +Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: Solaris 8 PHP Version: 5.0.5 New Comment: Whoah! Please don't be misled by the configure script I submitted in this bug report - the LDFLAGS and CPPFLAGS variables were set during my attempts to work around the problem because I originally thought that the build was picking up the wrong libtcl.so. I have since verified that the only copies of this library on my system are under the Sybase paths. It does appear that the wrong libintl.so library is being picked up - it should be using the one under the Sybase path, but is ignoring it and using the one under /usr/lib instead. I have tried this build against both the Sybase 12.0 and 12.5 client libraries with identical results. My original configure script is: #!/usr/bin/sh DSQUERY=fx_dbserver2_ds SYBASE=/dpkg/sybase/sybase12_5 SYBASE_OCS=OCS-12_5 LD_LIBRARY_PATH=$SYBASE/$SYBASE_OCS/lib:/usr/local/lib:$LD_LIBRARY_PATH PATH=/usr/ccs/bin:$PATH export DSQUERY SYBASE SYBASE_OCS LD_LIBRARY_PATH PATH cd php-5.0.5 ./configure \ --prefix=/usr/local/php \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-sybase-ct=$SYBASE/$SYBASE_OCS \ --without-bz2 This produces a libphp5.so which is linked as follows: ldd /usr/local/apache2/modules/libphp5.so libtcl.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libtcl.so libintl.so.1 => /usr/lib/libintl.so.1 libcomn.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcomn.so libct.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libct.so libcs.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcs.so libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 NOTE that the reference to libintl is still linked to the wrong library. I have investigated further and found that libintl.so.1 doesn't exist under the Sybase path - only libintl.so is found there. I need to somehow force the build to pick up the Sybase library instead of the Solaris library. A solved case on the Sybase site mentions that the Solaris library /usr/lib/libintl.so.1 has nothing to do with the Sybase library of the same name, which is possibly why the object not found error since my build is linking to the wrong library! Previous Comments: [2005-10-26 17:43:50] [EMAIL PROTECTED] Don't try outsmarting the configure. User error -> not PHP bug. [2005-10-18 11:03:24] sean dot healey at bayernlb dot co dot uk Description: I am getting the following error when trying to start Apache2 with the PHP plugin configured: # ./apachectl start Syntax error on line 232 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: ld.so.1: /usr/local/apache2/bin/httpd: fatal: relocation error: file /dpkg/sybase/OCS-12_0/lib/libtcl.so: symbol comn_free: referenced symbol not found When built without Sybase client library, the plugin starts up just fine. The php module DOES appear to be linked against the correct copy of libtcl.so - here are the without-sybase and with-sybase ldd outputs: # ldd libphp5.so.without_sybase libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 # ldd libphp5.so libtcl.so => /dpkg/syba
#22873 [Com]: Pb to start Apache with sybase-ct option
ID: 22873 Comment by: sean dot healey at bayernlb dot co dot uk Reported By: theron at cines dot fr Status: No Feedback Bug Type: Sybase-ct (ctlib) related Operating System: Sun solaris 8 PHP Version: 4.3.2RC1 New Comment: (See BugID 34904) Previous Comments: [2005-10-24 12:05:10] sean dot healey at bayernlb dot co dot uk This is exactly the error I am facing with PHP 5.0.5. The problem occurs whether or not LD_LIBRARY_PATH is set, and in fact I have carefully set my LDDFLAGS -L and -R arguments to point the compiler in the right direction for the Sybase client libraries. [2003-04-28 11:14:20] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-04-23 04:40:14] [EMAIL PROTECTED] Is /opt/sybase-12.5/OCS-12_5/lib/ set in your LD_LIBRARY_PATH? [2003-03-26 02:41:18] theron at cines dot fr Here are the output of the ldd cmd: [EMAIL PROTECTED]:$PWD # ldd libphp4.so libdl.so.1 =>/usr/lib/libdl.so.1 libpam.so.1 => /usr/lib/libpam.so.1 libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1 libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libc.so.1 => /usr/lib/libc.so.1 libgen.so.1 => /usr/lib/libgen.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 [EMAIL PROTECTED]:$PWD # ldd /opt/sybase-12.5/OCS-12_5/lib/libtcl.so libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 Thanks. Regards [2003-03-25 17:10:03] [EMAIL PROTECTED] What is the output of: ldd /opt/php-4.2.3/.libs/libphp4.so and ldd /opt/sybase-12.5/OCS-12_5/lib/libtcl.so ? 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/22873 -- Edit this bug report at http://bugs.php.net/?id=22873&edit=1
#22873 [Com]: Pb to start Apache with sybase-ct option
ID: 22873 Comment by: sean dot healey at bayernlb dot co dot uk Reported By: theron at cines dot fr Status: No Feedback Bug Type: Sybase-ct (ctlib) related Operating System: Sun solaris 8 PHP Version: 4.3.2RC1 New Comment: This is exactly the error I am facing with PHP 5.0.5. The problem occurs whether or not LD_LIBRARY_PATH is set, and in fact I have carefully set my LDDFLAGS -L and -R arguments to point the compiler in the right direction for the Sybase client libraries. Previous Comments: [2003-04-28 11:14:20] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-04-23 04:40:14] [EMAIL PROTECTED] Is /opt/sybase-12.5/OCS-12_5/lib/ set in your LD_LIBRARY_PATH? [2003-03-26 02:41:18] theron at cines dot fr Here are the output of the ldd cmd: [EMAIL PROTECTED]:$PWD # ldd libphp4.so libdl.so.1 =>/usr/lib/libdl.so.1 libpam.so.1 => /usr/lib/libpam.so.1 libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1 libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libc.so.1 => /usr/lib/libc.so.1 libgen.so.1 => /usr/lib/libgen.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 [EMAIL PROTECTED]:$PWD # ldd /opt/sybase-12.5/OCS-12_5/lib/libtcl.so libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 Thanks. Regards [2003-03-25 17:10:03] [EMAIL PROTECTED] What is the output of: ldd /opt/php-4.2.3/.libs/libphp4.so and ldd /opt/sybase-12.5/OCS-12_5/lib/libtcl.so ? [2003-03-25 08:14:17] theron at cines dot fr Hello, I build apache 1.3.26, Sybase ASE 12.5 and php 4.2.3 (OS = Sun Solaris 8) with this configuration: ./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --enable-ftp \ --with-gettext \ --with-xml \ --with-domxml \ --with-mcrypt \ --with-iconv \ --enable-mbstring \ --with-jpeg --with-jpeg-dir=/opt/jpeg-6b \ --with-png --with-png-dir=/opt/libpng-1.2.5 \ --with-zlib --with-zlib-dir=/opt/zlib-1.1.4 \ --with-gd=/opt/gd-1.8.4 \ --with-sybase-ct=/opt/sybase-12.5/OCS-12_5 \ The build of PH is ok but, when i start the apache server I have this error message: Syntax error on line 237 of /home/admwww/cours_php/apache/conf/httpd.conf: Cannot load /opt/php-4.2.3/.libs/libphp4.so into server: ld.so.1: /usr/local/apache/bin/httpd: fatal: relocation error: file /opt/sybase-12.5/OCS-12_5/lib/libtcl.so: symbol comn_realloc: referenced symbol not found The gcc compiler is gcc 3.2.2 When i build with the dblib of sybase (option --with-sybase in the config file) THERE IS NO PROBLEM TO START APACHE ! Any idea please, i'm very stoped by this problem. Regards. JP THERON -- Edit this bug report at http://bugs.php.net/?id=22873&edit=1
#34904 [NEW]: Relocation error in libphp5.so when starting Apache2
From: sean dot healey at bayernlb dot co dot uk Operating system: Solaris 8 PHP version: 5.0.5 PHP Bug Type: Sybase-ct (ctlib) related Bug description: Relocation error in libphp5.so when starting Apache2 Description: I am getting the following error when trying to start Apache2 with the PHP plugin configured: # ./apachectl start Syntax error on line 232 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: ld.so.1: /usr/local/apache2/bin/httpd: fatal: relocation error: file /dpkg/sybase/OCS-12_0/lib/libtcl.so: symbol comn_free: referenced symbol not found When built without Sybase client library, the plugin starts up just fine. The php module DOES appear to be linked against the correct copy of libtcl.so - here are the without-sybase and with-sybase ldd outputs: # ldd libphp5.so.without_sybase libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 # ldd libphp5.so libtcl.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libtcl.so libintl.so.1 => /usr/lib/libintl.so.1 libcomn.so =>/dpkg/sybase/sybase12_5/OCS-12_5/lib/libcomn.so libct.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libct.so libcs.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcs.so libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 I have noticed that libintl.so.1 should be picked up from the Sybase client libs directory, but is linking from the system libs directory instead. Can't tell if this is related. I have tried this build both against client library vers 12.0 and 12.5 with identical results. Have noted similar bugs reported for previous versions of PHP. Setting LD_LIBRARY_PATH in the Apachectl script does not fix the problem. Reproduce code: --- #!/usr/bin/sh DSQUERY=fx_dbserver2_ds SYBASE=/dpkg/sybase/sybase12_5 SYBASE_OCS=OCS-12_5 LD_LIBRARY_PATH=$SYBASE/$SYBASE_OCS/lib:/usr/local/lib:$LD_LIBRARY_PATH PATH=$SYBASE/$SYBASE_OCS/bin:/usr/ccs/bin:/usr/local/bin:/usr/sbin:/usr/bin CPPFLAGS="-I$SYBASE/$SYBASE_OCS/include:/usr/local/include:/usr/include:/usr /dt/include:/usr/openwin/include:/usr/local/include/libxml2/libxml:/usr/loca l/include/libxml2/libxslt:/usr/local/include/libpng:/usr/local/BerkeleyDB.4. 2/include" LDFLAGS="-L$SYBASE/$SYBASE_OCS/lib:/usr/ccs/lib:/usr/local/lib:/usr/lib:/usr /dt/lib:/usr/openwin/lib:/usr/local/BerkeleyDB.4.2/lib: -R$SYBASE/$SYBASE_OCS/lib:/usr/ccs/lib:/usr/local/lib:/usr/lib:/usr/dt/lib:/ usr/openwin/lib:/usr/local/BerkeleyDB.4.2/lib" export DSQUERY SYBASE SYBASE_OCS LD_LIBRARY_PATH PATH CPPFLAGS LDFLAGS cd php-5.0.5 ./configure \ --prefix=/usr/local/php \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-sybase-ct=$SYBASE/$SYBASE_OCS \ --without-bz2 \ --enable-sysvmsg \ --enable-sysvsem \ --enable-sysvshm -- Edit bug report at http://bugs.php.net/?id=34904&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34904&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34904&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34904&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34904&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34904&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34904&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34904&r=needscript Try newer version:
#33931 [Opn->Ver]: __get and __set don't handle arrays correctly
ID: 33931
Updated by: [EMAIL PROTECTED]
Reported By: wkonkel at gmail dot com
-Status: Open
+Status: Verified
Bug Type: *General Issues
Operating System: n/a
PHP Version: 5.0.4
New Comment:
Happens to me on 5.0.3 as well.
Shorter code:
data[$key] = $val;
}
}
$A = new A();
$A->foo['bar'] = 'oink';
$A->foo['bar1'] = 'oink1';
var_dump($undefined);
$undefined[] = 'blah';
var_dump($undefined);
?>
Outputs:
NULL
array(2) {
["bar1"]=>
string(5) "oink1"
[0]=>
string(4) "blah"
}
Previous Comments:
[2005-07-30 22:39:55] wkonkel at gmail dot com
Description:
The __set and __get don't seem to handle arrays correctly. What's even
worse, is it adds data to memory which is allocated at a later time
($boz gets foo2 and foo3 of $myObj). The code example speaks for
itself.
Reproduce code:
---
data[$key] = $val;
}
function __get($key) {
return $this->data[$key];
}
}
$myObj = new buggy();
$myObj->somevar['foo1'] = 'bar1';
$myObj->somevar['foo2'] = 'bar2';
$myObj->somevar['foo3'] = 'bar3';
$boz[] = 'blah';
print_r($boz);
?>
Expected result:
Array
(
[0] => blah
)
Actual result:
--
Array
(
[foo2] => bar2
[foo3] => bar3
[0] => blah
)
--
Edit this bug report at http://bugs.php.net/?id=33931&edit=1
#33188 [Fbk->Opn]: Cannot instantiate a DOTNET object
ID: 33188
User updated by: sean at iplus dot plus dot com
Reported By: sean at iplus dot plus dot com
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: Windows 2000
PHP Version: 5CVS-2005-05-31
New Comment:
I have tested again after a reboot but still get the same result.
Whats the significance of a reboot ? What gets installed/modified ? I
though I just had to unzip the binaries and run PHP.EXE with a .PHP
script. Im not using PHP with a webserver - just using PHP.EXE on the
command line. I didnt think I had to install anything extra for PHP
(and the DOTNET extension) to work. Maybe I've missed something here ?
Thanks
Previous Comments:
[2005-05-30 23:56:59] [EMAIL PROTECTED]
Did you reboot..? :)
[2005-05-30 23:43:36] sean at iplus dot plus dot com
Tried the latest snapshot but still get same result as shown below:
C:\PHP\BUGS>php5-win32-latest\php.exe -v
PHP 5.1.0-dev (cli) (built: May 30 2005 20:22:11)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies
C:\PHP\BUGS>php5-win32-latest\php.exe dotnet-example.php
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
instantiate .Net object [CreateInstance] [0x80070057] The parameter is
incorrect.
' in C:\PHP\BUGS\dotnet-example.php:2
Stack trace:
#0 {main}
thrown in C:\PHP\BUGS\dotnet-example.php on line 2
#
[2005-05-30 23:00:59] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
----
[2005-05-30 18:57:03] sean at iplus dot plus dot com
Description:
When trying to instantiate a DOTNET object in Version 5.0.4 I get a
'com_exception'. I have Microsoft.NET 1.1 installed.
The bug appears similar to a previous bug:
BUG #29490 'Failed to instantiate .Net object' using PHP.NET docu
example
BUG #30461 "Failed to Instantiate .Net Object" error (again)
Bug #29490 was fixed in version 5.0.1.
I tried version 5.0.1, 5.0.2, 5.03 and could not instantiate a DOTNET
object. However the error message was different for different versions.
Version Error message
--
5.0.4 Failed to instantiate .Net object [CreateInstance] [0x80070057]
The parameter is incorrect
5.0.3 Failed to instantiate .Net object [CreateInstance] [0x80070057]
The parameter is incorrect
5.0.2 Failed to initialize .Net runtime
5.0.1 Failed to initialize .Net runtime
The full results of my tests are shown below.
##
Tests run on previous PHP versions - all with same reproduce code
##
##
PHP VERSION = 5.04
##
C:\PHP>php-5.0.4-Win32\php.exe -v
PHP 5.0.4 (cli) (built: Mar 31 2005 02:45:48)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies
C:\PHP>php-5.0.4-Win32\php.exe dotnet-example.php
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
instantiate .Net object [CreateInstance] [0x80070057] The parameter is
incorrect.
' in C:\PHP\dotnet-example.php:2
Stack trace:
#0 C:\PHP\dotnet-example.php(2): dotnet->dotnet('mscorlib',
'System.Collecti...')
#1 {main}
thrown in C:\PHP\dotnet-example.php on line 2
##
PHP VERSION = 5.03
##
C:\PHP>php-5.0.3-Win32\php.exe -v
PHP 5.0.3 (cli) (built: Dec 15 2004 08:07:57)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.3, Copyright (c) 1998-2004 Zend Technologies
C:\PHP>php-5.0.3-Win32\php.exe dotnet-example.php
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
instantiate .Net object [CreateInstance] [0x80070057] The parameter is
incorrect.
' in C:\PHP\dotnet-example.php:2
Stack trace:
#0 C:\PHP\dotnet-example.php(2): dotnet->dotnet('mscorlib',
'System.Collecti...')
#1 {main}
thrown in C:\PHP\dotnet-example.php on line 2
##
PHP VERSION = 5.02
##
C:\PHP>php-5.0.2-Win32\php.exe -v
PHP 5.0.2 (cli) (built: Sep 24 2004 01:25:41)
Co
#33188 [Fbk->Opn]: Cannot instantiate a DOTNET object
ID: 33188
User updated by: sean at iplus dot plus dot com
Reported By: sean at iplus dot plus dot com
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: Windows 2000
PHP Version: 5.0.4
New Comment:
Tried the latest snapshot but still get same result as shown below:
C:\PHP\BUGS>php5-win32-latest\php.exe -v
PHP 5.1.0-dev (cli) (built: May 30 2005 20:22:11)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies
C:\PHP\BUGS>php5-win32-latest\php.exe dotnet-example.php
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
instantiate .Net object [CreateInstance] [0x80070057] The parameter is
incorrect.
' in C:\PHP\BUGS\dotnet-example.php:2
Stack trace:
#0 {main}
thrown in C:\PHP\BUGS\dotnet-example.php on line 2
#
Previous Comments:
[2005-05-30 23:00:59] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
----
[2005-05-30 18:57:03] sean at iplus dot plus dot com
Description:
When trying to instantiate a DOTNET object in Version 5.0.4 I get a
'com_exception'. I have Microsoft.NET 1.1 installed.
The bug appears similar to a previous bug:
BUG #29490 'Failed to instantiate .Net object' using PHP.NET docu
example
BUG #30461 "Failed to Instantiate .Net Object" error (again)
Bug #29490 was fixed in version 5.0.1.
I tried version 5.0.1, 5.0.2, 5.03 and could not instantiate a DOTNET
object. However the error message was different for different versions.
Version Error message
--
5.0.4 Failed to instantiate .Net object [CreateInstance] [0x80070057]
The parameter is incorrect
5.0.3 Failed to instantiate .Net object [CreateInstance] [0x80070057]
The parameter is incorrect
5.0.2 Failed to initialize .Net runtime
5.0.1 Failed to initialize .Net runtime
The full results of my tests are shown below.
##
Tests run on previous PHP versions - all with same reproduce code
##
##
PHP VERSION = 5.04
##
C:\PHP>php-5.0.4-Win32\php.exe -v
PHP 5.0.4 (cli) (built: Mar 31 2005 02:45:48)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies
C:\PHP>php-5.0.4-Win32\php.exe dotnet-example.php
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
instantiate .Net object [CreateInstance] [0x80070057] The parameter is
incorrect.
' in C:\PHP\dotnet-example.php:2
Stack trace:
#0 C:\PHP\dotnet-example.php(2): dotnet->dotnet('mscorlib',
'System.Collecti...')
#1 {main}
thrown in C:\PHP\dotnet-example.php on line 2
##
PHP VERSION = 5.03
##
C:\PHP>php-5.0.3-Win32\php.exe -v
PHP 5.0.3 (cli) (built: Dec 15 2004 08:07:57)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.3, Copyright (c) 1998-2004 Zend Technologies
C:\PHP>php-5.0.3-Win32\php.exe dotnet-example.php
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
instantiate .Net object [CreateInstance] [0x80070057] The parameter is
incorrect.
' in C:\PHP\dotnet-example.php:2
Stack trace:
#0 C:\PHP\dotnet-example.php(2): dotnet->dotnet('mscorlib',
'System.Collecti...')
#1 {main}
thrown in C:\PHP\dotnet-example.php on line 2
##
PHP VERSION = 5.02
##
C:\PHP>php-5.0.2-Win32\php.exe -v
PHP 5.0.2 (cli) (built: Sep 24 2004 01:25:41)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.2, Copyright (c) 1998-2004 Zend Technologies
C:\PHP>php-5.0.2-Win32\php.exe dotnet-example.php
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
initialize .Net runtime' in C:\PHP\dotnet-example.php:2
Stack trace:
#0 {main}
thrown in C:\PHP\dotnet-example.php on line 2
##
PHP VERSION = 5.01
##
C:\PHP>php-5.0.1-Win32\php.exe -v
PHP 5.0.1 (cli) (built: Aug 12 2004 23:30:46)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.1, Copyright (c) 1998-2004 Ze
#33188 [NEW]: Cannot instantiate a DOTNET object
From: sean at iplus dot plus dot com
Operating system: Windows 2000
PHP version: 5.0.4
PHP Bug Type: COM related
Bug description: Cannot instantiate a DOTNET object
Description:
When trying to instantiate a DOTNET object in Version 5.0.4 I get a
'com_exception'. I have Microsoft.NET 1.1 installed.
The bug appears similar to a previous bug:
BUG #29490 'Failed to instantiate .Net object' using PHP.NET docu example
BUG #30461 "Failed to Instantiate .Net Object" error (again)
Bug #29490 was fixed in version 5.0.1.
I tried version 5.0.1, 5.0.2, 5.03 and could not instantiate a DOTNET
object. However the error message was different for different versions.
Version Error message
--
5.0.4 Failed to instantiate .Net object [CreateInstance] [0x80070057]
The parameter is incorrect
5.0.3 Failed to instantiate .Net object [CreateInstance] [0x80070057]
The parameter is incorrect
5.0.2 Failed to initialize .Net runtime
5.0.1 Failed to initialize .Net runtime
The full results of my tests are shown below.
##
Tests run on previous PHP versions - all with same reproduce code
##
##
PHP VERSION = 5.04
##
C:\PHP>php-5.0.4-Win32\php.exe -v
PHP 5.0.4 (cli) (built: Mar 31 2005 02:45:48)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies
C:\PHP>php-5.0.4-Win32\php.exe dotnet-example.php
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
instantiate .Net object [CreateInstance] [0x80070057] The parameter is
incorrect.
' in C:\PHP\dotnet-example.php:2
Stack trace:
#0 C:\PHP\dotnet-example.php(2): dotnet->dotnet('mscorlib',
'System.Collecti...')
#1 {main}
thrown in C:\PHP\dotnet-example.php on line 2
##
PHP VERSION = 5.03
##
C:\PHP>php-5.0.3-Win32\php.exe -v
PHP 5.0.3 (cli) (built: Dec 15 2004 08:07:57)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.3, Copyright (c) 1998-2004 Zend Technologies
C:\PHP>php-5.0.3-Win32\php.exe dotnet-example.php
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
instantiate .Net object [CreateInstance] [0x80070057] The parameter is
incorrect.
' in C:\PHP\dotnet-example.php:2
Stack trace:
#0 C:\PHP\dotnet-example.php(2): dotnet->dotnet('mscorlib',
'System.Collecti...')
#1 {main}
thrown in C:\PHP\dotnet-example.php on line 2
##
PHP VERSION = 5.02
##
C:\PHP>php-5.0.2-Win32\php.exe -v
PHP 5.0.2 (cli) (built: Sep 24 2004 01:25:41)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.2, Copyright (c) 1998-2004 Zend Technologies
C:\PHP>php-5.0.2-Win32\php.exe dotnet-example.php
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
initialize .Net runtime' in C:\PHP\dotnet-example.php:2
Stack trace:
#0 {main}
thrown in C:\PHP\dotnet-example.php on line 2
##
PHP VERSION = 5.01
##
C:\PHP>php-5.0.1-Win32\php.exe -v
PHP 5.0.1 (cli) (built: Aug 12 2004 23:30:46)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.1, Copyright (c) 1998-2004 Zend Technologies
C:\PHP>php-5.0.1-Win32\php.exe dotnet-example.php
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
initialize .Net runtime' in C:\PHP\dotnet-example.php:2
Stack trace:
#0 {main}
thrown in C:\PHP\dotnet-example.php on line 2
##
##
Reproduce code:
---
Push(".Net");
$stack->Push("Hello ");
echo $stack->Pop() . $stack->Pop();
?>
Expected result:
Hello .Net
Actual result:
--
Fatal error: Uncaught exception 'com_exception' with message 'Failed to
instantiate .Net object [CreateInstance] [0x80070057] The parameter is
incorrect.
in C:\PHP\dotnet-example.php:2
Stack trace:
#0 C:\PHP\dotnet-example.php(2): dotnet->dotnet('mscorlib',
'System.Collecti...')
#1 {main}
thrown in C:\PHP\dotnet-example.php on line 2
--
Edit bug report at http://bugs.php.net/?id=33188&edit=1
--
Try a CVS snapshot (php4):
#31142 [Csd->Opn]: imap_mail_compose() no longer works
ID: 31142
User updated by: sean-freebsd at farley dot org
Reported By: sean-freebsd at farley dot org
-Status: Closed
+Status: Open
Bug Type: IMAP related
Operating System: *
PHP Version: 4CVS, 5CVS (2004-12-17)
New Comment:
I think I need to give a better example. While the fix in CVS does fix
the example from the man page, I am having trouble when the envelope
includes custom_headers.
If you add the following line to the example script in the man page,
you should notice that the other headers are missing. I tested this
with a 20050104 CVS snapshot.
$envelope["custom_headers"] = array("X-Mailer: TestMailer");
Thank you for the earlier fix. It did help.
Previous Comments:
[2004-12-22 18:29:20] [EMAIL PROTECTED]
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.
[2004-12-20 20:01:17] rgeorge at umn dot edu
Can also confirm this bug -- my webmail stopped being
able to send messages on php upgrade. On investigation,
imap_mail_compose() was returning nothing but a mime-
part separator. Implementing the sample from the manual
yields the same behavior.
some info from phpinfo:
Configure Command
'./configure' '--with-apache=/usr/src/redhat/BUILD/
apache-ssl-php-1.3.33/apache_1.3.33' '--prefix=/usr/
local/apache' '--enable-calendar' '--enable-trans-sid'
'--enable-session' '--enable-sockets' '--enable-wddx'
'--enable-inline-optimization' '--enable-bcmath' '--
with-curl' '--enable-ftp' '--with-ldap' '--with-
kerberos' '--with-zlib' '--with-imap' '--with-imap-ssl'
PHP API
20020918
PHP Extension
20020429
Zend Extension
20021010
[2004-12-20 13:32:51] [EMAIL PROTECTED]
The example from manual does not work for me either.
c-client version 2001a
[2004-12-20 13:01:50] mcsoftware at alikuvkoutek dot cz
Configure Command: './configure' '--prefix=/www/php'
'--with-apache=/usr/src/apache_1.3.33' '--enable-safe-mode'
'--enable-exif' '--enable-track-vars' '--with-calendar=shared'
'--enable-magic-quotes' '--enable-trans-sid' '--enable-wddx'
'--enable-ftp' '--enable-inline-optimization' '--enable-memory-limit'
'--with-expat-dir' '--enable-xslt' '--with-xslt-sablot' '--with-xml'
'--with-imap-ssl' '--with-mysql' '--enable-dbase' '--enable-mbstring'
'--with-gd' '--with-zlib' '--enable-gd-native-tt' '--with-t1lib'
'--with-jpeg-dir' '--with-png-dir' '--with-zlib-dir' '--with-ttf'
'--with-freetype-dir' '--with-imap' '--with-mhash' '--with-mcrypt'
'--with-pdflib' '--with-tiff-dir' '--with-openssl' '--with-curl'
'--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm'
'--enable-bcmath' '--enable-mbregex' '--without-pear' '--with-iconv'
'--with-dom' '--with-libxml-dir' '--enable-gd-native-ttf'
'--enable-zend-multibyte' '--enable-soap' '--with-bz2'
'--without-sqlite' '--with-unixODBC' '--with-tidy'
PHP API: 20031224
PHP Extension: 20041030
Zend Extension: 220040412
Zend Optimizer
[2004-12-20 01:36:53] sean-freebsd at farley dot org
My sample script is the one from the man page:
http://us2.php.net/manual/en/function.imap-mail-compose.php
Apache modules:
core prefork http_core mod_so mod_access mod_auth mod_auth_anon
mod_auth_dbm mod_charset_lite mod_include mod_deflate mod_log_config
mod_logio mod_env mod_mime_magic mod_cern_meta mod_expires mod_headers
mod_usertrack mod_unique_id mod_setenvif mod_ssl mod_mime mod_status
mod_autoindex mod_asis mod_info mod_cgi mod_vhost_alias mod_negotiation
mod_dir mod_imap mod_actions mod_speling mod_userdir mod_alias
mod_rewrite sapi_apache2
PHP extensions:
imap, pcre, pgsql, session, standard, xml
PHP Configuration:
'./configure' '--enable-versioning' '--enable-memory-limit'
'--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php'
'--disable-all' '--with-regex=php' '--with-apxs2=/usr/local/sbin/apxs'
'--prefix=/usr/local' 'i386-portbld-freebsd4.9'
No Zend extensions/modules added.
The only unusual thing I noticed is according to phpinfo() I have an
older IMAP library than what is installed (2004a):
IMAP c-Client Version 2000
SSL Support enabled
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/31142
--
Edit this bug report at http://bugs.php.net/?id=31142&edit=1
#31142 [Fbk->Opn]: imap_mail_compose() no longer works
ID: 31142
User updated by: sean-freebsd at farley dot org
Reported By: sean-freebsd at farley dot org
-Status: Feedback
+Status: Open
Bug Type: IMAP related
Operating System: *
PHP Version: 4CVS, 5CVS (2004-12-17)
New Comment:
My sample script is the one from the man page:
http://us2.php.net/manual/en/function.imap-mail-compose.php
Apache modules:
core prefork http_core mod_so mod_access mod_auth mod_auth_anon
mod_auth_dbm mod_charset_lite mod_include mod_deflate mod_log_config
mod_logio mod_env mod_mime_magic mod_cern_meta mod_expires mod_headers
mod_usertrack mod_unique_id mod_setenvif mod_ssl mod_mime mod_status
mod_autoindex mod_asis mod_info mod_cgi mod_vhost_alias mod_negotiation
mod_dir mod_imap mod_actions mod_speling mod_userdir mod_alias
mod_rewrite sapi_apache2
PHP extensions:
imap, pcre, pgsql, session, standard, xml
PHP Configuration:
'./configure' '--enable-versioning' '--enable-memory-limit'
'--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php'
'--disable-all' '--with-regex=php' '--with-apxs2=/usr/local/sbin/apxs'
'--prefix=/usr/local' 'i386-portbld-freebsd4.9'
No Zend extensions/modules added.
The only unusual thing I noticed is according to phpinfo() I have an
older IMAP library than what is installed (2004a):
IMAP c-Client Version 2000
SSL Support enabled
Previous Comments:
[2004-12-19 21:10:37] mcsoftware at alikuvkoutek dot cz
Works fine before software upgrade (imap is the same as before)...
Now from php_info()
---
Loaded Modules: mod_php5, mod_gzip, apache_ssl, mod_headers,
mod_expires, mod_auth, mod_access, mod_rewrite, mod_alias, mod_imap,
mod_dir, mod_autoindex, mod_include, mod_negotiation, mod_mime,
mod_log_referer, mod_log_agent, mod_log_config, http_core
Apache Version: Apache/1.3.33 Ben-SSL/1.55 (Unix) PHP/5.0.3
mod_gzip/1.3.26.1a
IMAP c-Client Version: 2001
SSL Support: enabled
[2004-12-19 20:26:12] [EMAIL PROTECTED]
Works fine in latest CVS, do you have any Zend Modules loaded?
[2004-12-19 19:31:42] mcsoftware at alikuvkoutek dot cz
I hope, this is the same error as described in this bug report...
CODE
$envelope["from"]= '[EMAIL PROTECTED]';
$envelope["return_path"]= '[EMAIL PROTECTED]';
$part1["type"]=TYPETEXT;
$part1["subtype"]="plain";
$part1["encoding"]=ENCQUOTEDPRINTABLE ;
$part1["charset"]='iso-8859-2';
$part1["contents.data"]=imap_8bit('asn řkl');
$body[0]=$part1; // or [1] as well
$envelope = unserialize(serialize($envelope));
$body = unserialize(serialize($body));
$message = imap_mail_compose($envelope, $body);
echo $message;
EXPECTED RESULT
---
e-mail message in MIME format (headers, double new line, encoded body)
RESULT
--
the same text as in $part1["contents.data"].
----
[2004-12-19 19:20:02] [EMAIL PROTECTED]
Please provide a short example script.
[2004-12-17 07:33:12] sean-freebsd at farley dot org
Description:
I noticed the problem after upgrading from PHP v4.3.4 to v4.3.10.
ISMail (http://www.insidesystems.net/projects/project.php?projectid=4)
stopped working. None of the headers provided in the envelope argument
were being returned by the function.
I also attempted running the example code (using /etc/motd for the file
in the code) from the man page for this function without success:
begin output
--0-1804289383-1103265027=:94095--
end output
--
Edit this bug report at http://bugs.php.net/?id=31142&edit=1
#31142 [NEW]: imap_mail_compose() no longer works
From: sean-freebsd at farley dot org Operating system: FreeBSD 4.10 PHP version: 4.3.10 PHP Bug Type: IMAP related Bug description: imap_mail_compose() no longer works Description: I noticed the problem after upgrading from PHP v4.3.4 to v4.3.10. ISMail (http://www.insidesystems.net/projects/project.php?projectid=4) stopped working. None of the headers provided in the envelope argument were being returned by the function. I also attempted running the example code (using /etc/motd for the file in the code) from the man page for this function without success: begin output --0-1804289383-1103265027=:94095-- end output -- Edit bug report at http://bugs.php.net/?id=31142&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31142&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31142&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31142&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31142&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31142&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31142&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31142&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31142&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31142&r=support Expected behavior: http://bugs.php.net/fix.php?id=31142&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31142&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31142&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31142&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31142&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31142&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31142&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31142&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31142&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31142&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31142&r=mysqlcfg
#31103 [Opn]: "Please check your IMAP installation" error is misleading
ID: 31103 Updated by: [EMAIL PROTECTED] Reported By: tss at iki dot fi Status: Open -Bug Type: Documentation problem +Bug Type: Compile Warning Operating System: any PHP Version: Irrelevant New Comment: This string is in configure/the autoconf stuff. So, the doc guys can't do anything about it. Made it "compile warning" S Previous Comments: [2004-12-15 21:21:58] tss at iki dot fi Description: "Cannot find rfc822.h. Please check your IMAP installation". Please change this to say "check your c-client library installation". I see way too often people asking in IMAP server lists about this, thinking they can't use PHP with the server because it doesn't have this file. -- Edit this bug report at http://bugs.php.net/?id=31103&edit=1
#30593 [Fbk->Opn]: --with-ingres option generates broken Makefile
ID: 30593 User updated by: sean dot lincolne at gmail dot com Reported By: sean dot lincolne at gmail dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: RedHat Linux 9.0 PHP Version: 4.3.9 New Comment: I was trying everything to see if I could force 'configure' to recognise that it needs the 'libpthread' library. Either way it has no impact on the problem, nor does it impact on the use of libpthread. Currently the only workaround is to manually edit 'Makefile' after 'configure' but before 'make'. Not particularly friendly or elegant. Previous Comments: [2004-11-24 01:35:15] [EMAIL PROTECTED] WHY do you want to use the --with-tsrm-phtreads option? You're compiling an apache 1.x module which isn't multithreaded.. [2004-10-31 04:44:59] sean dot lincolne at gmail dot com Configuration command as follows: ./configure --with-apxs --without-mysql \ --with-ingres --with-ldap \ --without-pear --disable-shared \ --enable-static --with-tsrm-pthreads Make fails with the following error: /opt/ingres/lib/libingres.a(louniq.o): In function `LOuniq': louniq.o(.text+0x16d): the use of `mktemp' is dangerous, better use `mkstemp' /opt/ingres/lib/libingres.a(mepages.o): In function `IIMEget_pages': mepages.o(.text+0x1c5): undefined reference to `pthread_mutex_trylock' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 [EMAIL PROTECTED] php-4.3.9]# The 'config.log' file can be found at http://www.batute.com/config.log Thanks, Sean [2004-10-28 08:11:15] [EMAIL PROTECTED] Please provide your 1. configure line, 2. the error itself, 3. a link to the output of config.log (do not paste it here!) ---- [2004-10-28 02:07:21] sean dot lincolne at gmail dot com Description: Configuring a PHP build with the '--with-ingres' option results in an incomplete Makefile. When you attempt to make PHP the make fails. If you manually edit the Makefile after configure, and add '-lpthread' to the 'EXTRA_LIBS' line the make will complete successfully. Specifiying the '--with-tsrm-pthreads' as a configure option does not fix this. Can someone examine the Ingres build code in PHP and ensure that when the '--with-ingres' option is specified the 'libpthread' library is included in the library list ? -- Edit this bug report at http://bugs.php.net/?id=30593&edit=1
#30593 [Fbk->Opn]: --with-ingres option generates broken Makefile
ID: 30593 User updated by: sean dot lincolne at gmail dot com Reported By: sean dot lincolne at gmail dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: RedHat Linux 9.0 PHP Version: 4.3.9 New Comment: Configuration command as follows: ./configure --with-apxs --without-mysql \ --with-ingres --with-ldap \ --without-pear --disable-shared \ --enable-static --with-tsrm-pthreads Make fails with the following error: /opt/ingres/lib/libingres.a(louniq.o): In function `LOuniq': louniq.o(.text+0x16d): the use of `mktemp' is dangerous, better use `mkstemp' /opt/ingres/lib/libingres.a(mepages.o): In function `IIMEget_pages': mepages.o(.text+0x1c5): undefined reference to `pthread_mutex_trylock' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 [EMAIL PROTECTED] php-4.3.9]# The 'config.log' file can be found at http://www.batute.com/config.log Thanks, Sean Previous Comments: [2004-10-28 08:11:15] [EMAIL PROTECTED] Please provide your 1. configure line, 2. the error itself, 3. a link to the output of config.log (do not paste it here!) ---- [2004-10-28 02:07:21] sean dot lincolne at gmail dot com Description: Configuring a PHP build with the '--with-ingres' option results in an incomplete Makefile. When you attempt to make PHP the make fails. If you manually edit the Makefile after configure, and add '-lpthread' to the 'EXTRA_LIBS' line the make will complete successfully. Specifiying the '--with-tsrm-pthreads' as a configure option does not fix this. Can someone examine the Ingres build code in PHP and ensure that when the '--with-ingres' option is specified the 'libpthread' library is included in the library list ? -- Edit this bug report at http://bugs.php.net/?id=30593&edit=1
#30593 [NEW]: --with-ingres option generates broken Makefile
From: sean dot lincolne at gmail dot com Operating system: RedHat Linux 9.0 PHP version: 4.3.9 PHP Bug Type: Compile Failure Bug description: --with-ingres option generates broken Makefile Description: Configuring a PHP build with the '--with-ingres' option results in an incomplete Makefile. When you attempt to make PHP the make fails. If you manually edit the Makefile after configure, and add '-lpthread' to the 'EXTRA_LIBS' line the make will complete successfully. Specifiying the '--with-tsrm-pthreads' as a configure option does not fix this. Can someone examine the Ingres build code in PHP and ensure that when the '--with-ingres' option is specified the 'libpthread' library is included in the library list ? -- Edit bug report at http://bugs.php.net/?id=30593&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30593&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30593&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30593&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30593&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30593&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30593&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30593&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30593&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30593&r=support Expected behavior: http://bugs.php.net/fix.php?id=30593&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30593&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30593&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30593&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30593&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30593&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30593&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30593&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30593&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30593&r=mysqlcfg
#28714 [Com]: Type hint error completely useless
ID: 28714 Comment by: sean at acidreign dot net Reported By: nlhowell at cableone dot net Status: Open Bug Type: Feature/Change Request Operating System: WinXP Pro 2600 SP1 PHP Version: 5CVS-2004-06-09 (dev) New Comment: This bug is related to the one posted here: http://bugs.php.net/bug.php?id=27290 Previous Comments: [2004-06-09 20:53:43] nlhowell at cableone dot net Description: When you have a type-hint error (ie: you pass an incompatible object to a function with a type hint), the error message is completely useless. It tells you where the function with the type hint is defined; it *should* tell you where you tried to pass the invalid object. Logically, this makes sense. If I pass an object that doesn't fit the type hint, it's not the function that's at fault; it's mine. Reproduce code: --- Expected result: Fatal error: Argument 1 must be an instance of x in c:\Inetpub\wwwroot\test.php5 on line 12 Actual result: -- Fatal error: Argument 1 must be an instance of x in c:\Inetpub\wwwroot\test.php5 on line 8 -- Edit this bug report at http://bugs.php.net/?id=28714&edit=1
#27290 [Com]: warning msg on missing function argument should mention file/line of caller too
ID: 27290 Comment by: sean at acidreign dot net Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Feature/Change Request PHP Version: 5CVS-2004-02-17 (dev) New Comment: over the last few days, I've had to tack down dozens of errors, with out knowing the file/line they actually occur in. reporting the line of the function declaration rather then the line of the offending expression is completely useless. It makes tracking bugs extremely difficult, because it has to be done on a trial and error basis, looking for and testing every place a function is called. Previous Comments: [2004-02-17 11:11:08] [EMAIL PROTECTED] Description: usually the location of the caller what you really want to know here, especially if you are trying to track this down from not-so-recent messages in your error_log ... Reproduce code: --- Expected result: Warning: Missing argument 1 for foo() in foo.php on line 2, called in foo.php on line 4 Actual result: -- Warning: Missing argument 1 for foo() in - on line 2 -- Edit this bug report at http://bugs.php.net/?id=27290&edit=1
#29972 [NEW]: array_combine issues warning on empty arrays
From: sean at acidreign dot net
Operating system: all
PHP version: 5.0.1
PHP Bug Type: Feature/Change Request
Bug description: array_combine issues warning on empty arrays
Description:
array_combine issues a warning when empty arrays are passed as arguments,
I submit that empty arrays should be valid input for this function, and
the result should also be an empty array (rather than FALSE and a
warning).
On top of that, the warning is non-sensical, as it states that "Both
parameters should have number of elements at least 0"
Reproduce code:
---
$a = array();
$b = array();
$c = array_combine( $a, $b );
var_dump( $c );
Expected result:
array(0) { }
Actual result:
--
Warning: array_combine() [function.array-combine]: Both parameters should
have number of elements at least 0 in /var/www/vhosts/.../test.php on line
4
bool(false)
--
Edit bug report at http://bugs.php.net/?id=29972&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29972&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29972&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29972&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29972&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29972&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29972&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29972&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29972&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29972&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29972&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29972&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29972&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29972&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29972&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29972&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29972&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29972&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29972&r=float
#27728 [Asn]: Segfault in combination of php_check_syntax() and exit.
ID: 27728
Updated by: [EMAIL PROTECTED]
Reported By: mail at patrickwitte dot de
Status: Assigned
Bug Type: Reproducible crash
Operating System: *
PHP Version: 5.0.0RC1
Assigned To: ilia
New Comment:
I also stumbled upon this, today.
Here is my reproduce code:
if (!php_check_syntax(NULL)) { die(); }
(segfaults)
Seems this is not related to __FILE__
I concur that if exit (die) is not called, no segfault.
S
Previous Comments:
[2004-03-27 16:30:33] mail at patrickwitte dot de
I made a few more test to get more systematic results:
1) Check of file(test.php) with parse error, no matter if
'php_check_syntax()' is followed by 'exit' or not, results in debug
message:
/home/patrick/php-5.0.0RC1/main/streams/streams.c(371) : Stream of type
'STDIO' 0x4047363c (path:test.php) was not closed
2) Check of correct or non-existant file:
2a) without following 'exit': result as expected
2b) with following 'exit': segfault
After looking in streams.c it seems to be a memory leak.
[2004-03-27 08:39:10] [EMAIL PROTECTED]
Valgrind reports errors while parsing the parameter. Perhaps we free
the __FILE__ stuff too early? Assigning to Ilia :)
==3720== Invalid read of size 4
==3720==at 0x8293343: zend_parse_arg_impl (zend_API.c:301)
==3720==by 0x8293887: zend_parse_arg (zend_API.c:450)
==3720==by 0x8293BC1: zend_parse_va_args (zend_API.c:542)
==3720==by 0x8293C43: zend_parse_parameters (zend_API.c:569)
==3720==by 0x81BF10C: zif_php_check_syntax
(basic_functions.c:2247)
==3720==by 0x82B89D4: zend_do_fcall_common_helper
(zend_execute.c:2689)
==3720==by 0x82B90D0: zend_do_fcall_handler (zend_execute.c:2818)
==3720==by 0x82B53C6: execute (zend_execute.c:1381)
==3720== Address 0x4B20E38C is not stack'd, malloc'd or free'd
==3720==
[2004-03-27 07:47:38] mail at patrickwitte dot de
Description:
This happens no matter if the checked file is syntactically ok or not
or even doesn't exists.
In all cases the result of php_check_syntax() is the expexted, but if
exit (or die()) is called afterwards you get a segfault.
Experienced with sapi-module and cli on linux and cli on win32.
(win32-sapi not tested)
Reproduce code:
---
Expected result:
Ok
Actual result:
--
Ok
segfault
Backtrace:
#0 _emalloc (size=Cannot access memory at address 0xc
) at /home/patrick/php-5.0.0RC1/Zend/zend_alloc.c:140
140 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(size);
--
Edit this bug report at http://bugs.php.net/?id=27728&edit=1
#28645 [Com]: SMTP value won't load although configured in php.ini
ID: 28645 Comment by: sean at govbt dot com Reported By: herps at raqtweak dot com Status: Open Bug Type: Mail related Operating System: Windows XP Professional PHP Version: 4.3.7 New Comment: on window make sure in the php.ini the smtp= is uppercase iow SMTP=mailserver.mail.com Previous Comments: [2004-06-11 13:17:38] herps at raqtweak dot com sniper, why do you always provide useless comments and blame others before you know all details? Don't you think I tried everything I could? I searched google for hours, to find out what was wrong. Search the internet, plenty of people have this problem. I searched and searched for a resolution, can not find one. Even looked it up in my PHP Bible... Could someone please have a look at why it won't load the values? Like I said, it loads the rest, but NOT the SMTP value... [2004-06-11 12:33:57] [EMAIL PROTECTED] You're doing something wrong, this works fine. [2004-06-07 17:16:45] herps at raqtweak dot com Apache2 module. Only 1 PHP.ini file. Searched entire system. I AM using "show extensions" option in WinXP, so I do not have php.ini.ini [2004-06-07 17:07:13] [EMAIL PROTECTED] Are you using PHP as Apache module or CGI? Do you have php.ini files anywhere else on the system? [2004-06-07 07:34:58] herps at raqtweak dot com OK just did that, still nothing!! 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/28645 -- Edit this bug report at http://bugs.php.net/?id=28645&edit=1
#28377 [NEW]: debug_backtrace is intermittently passing args
From: sean at caedmon dot net Operating system: Linux PHP version: 4CVS-2004-05-12 (stable) PHP Bug Type: Scripting Engine problem Bug description: debug_backtrace is intermittently passing args Description: debug_backtrace() behaves strangely when passed as a function argument. This does not happen if debug_backtrace is dereferenced (see code), nor if debug_backtrace() is the first parameter to my custom_callback function (not denoted in code) I'll be happy to provide additional details. This SEEMS like #27397 but is not a ZE2 problem (I'm using 4.3) and is NOT fixed in CVS. Thanks, S Reproduce code: --- Expected result: dereferenced -- args: exists direct -- args: exists Actual result: -- dereferenced -- args: exists direct -- args: does not exist -- Edit bug report at http://bugs.php.net/?id=28377&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28377&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28377&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28377&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28377&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28377&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28377&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28377&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28377&r=support Expected behavior: http://bugs.php.net/fix.php?id=28377&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28377&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28377&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28377&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28377&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28377&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28377&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28377&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28377&r=float
#27992 [Bgs]: Resource Leak
ID: 27992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Class/Object related Operating System: Linux (any) PHP Version: 4.3.6RC3 New Comment: Ah, now that you point that out, it's clear. Thank you. This is why I posted to internals@, first. Agreed. Bogus. S Previous Comments: [2004-04-15 10:34:13] [EMAIL PROTECTED] Hi. This isn't a bug. In your constructor, you stick a reference to $this in $_PEAR_destructor_object_list. This gives the object a refcount of 2, so it isn't destructed when it falls out of scope. This is expected behavior here. [2004-04-15 10:15:26] [EMAIL PROTECTED] Segfault: understandable My real concern is that it seems resources are not being released in this context. 65k is a big number (segfault). 1k not so much (warning; unable to open resource). S [2004-04-15 10:05:43] [EMAIL PROTECTED] The segfault is a known (and I believe wont-be-fixed-in -4) bug in the reference counting implementation. [2004-04-15 10:02:33] [EMAIL PROTECTED] First, $sock should get re-allocated in each iteration, thereby forcing the former $sock (and it's ->fp) out of scope. Second, the connect() method for $sock checks to see if it already has an allocated $fp; and if so, does an fclose. While this example isn't practical, this problem directly affects PEAR's HTTP_Request code (but this still isn't a PEAR issue). S [2004-04-14 22:34:20] [EMAIL PROTECTED] Why woudln't it run out of file handles when you never CLOSE the socket..? 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/27992 -- Edit this bug report at http://bugs.php.net/?id=27992&edit=1
#27992 [Fbk]: Resource Leak
ID: 27992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Class/Object related Operating System: Linux (any) PHP Version: 4.3.6RC3 New Comment: Segfault: understandable My real concern is that it seems resources are not being released in this context. 65k is a big number (segfault). 1k not so much (warning; unable to open resource). S Previous Comments: [2004-04-15 10:05:43] [EMAIL PROTECTED] The segfault is a known (and I believe wont-be-fixed-in -4) bug in the reference counting implementation. [2004-04-15 10:02:33] [EMAIL PROTECTED] First, $sock should get re-allocated in each iteration, thereby forcing the former $sock (and it's ->fp) out of scope. Second, the connect() method for $sock checks to see if it already has an allocated $fp; and if so, does an fclose. While this example isn't practical, this problem directly affects PEAR's HTTP_Request code (but this still isn't a PEAR issue). S [2004-04-14 22:34:20] [EMAIL PROTECTED] Why woudln't it run out of file handles when you never CLOSE the socket..? [2004-04-14 11:41:00] [EMAIL PROTECTED] Description: See the attached code; it has been isolated from PEAR (core) and PEAR::Net_Socket. Basically, after a certain number of iterations (Linux, PHP4.3.4 and 4.3.6RC3, likely others), PHP runs out of file resources. Warning: fsockopen(): unable to connect to 192.168.100.51:80 in /home/sean/www/dev3/crashing_resources.php on line 51 ERROR: 24 - Too many open files This SEEMS to be a leak (file handles are never closed?) in method_exists, get_classname or get_parent_classname, because if I remove the ShrunkenPEAR constructor (OR, the _ShrunkenPEAR method), the code does not fail. Additionally, if I instanciate ShrunkenSocket as $sock = new ShrunkenSocket() (value instead of reference), the error is also absent. The reason I'm using a reference: PEAR::HTTP_Request instanciates Net_Socket as such. Also, as mentioned in a comment in the code, if I change the die to an echo, the script segfaults after ~65535 iterations (which seems like an overflow problem). ** Note: this was originally posted to internals@ (PHP-DEV), but did not get a response.** This COULD be a critical overflow problem (when segfaulting), but I don't know enough about the matter to declare it so. Reproduce code: --- http://sean.caedmon.net/php/crashing_resources.phps Expected result: (see description) Actual result: -- (see description) -- Edit this bug report at http://bugs.php.net/?id=27992&edit=1
#27992 [Fbk]: Resource Leak
ID: 27992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Class/Object related Operating System: Linux (any) PHP Version: 4.3.6RC3 New Comment: First, $sock should get re-allocated in each iteration, thereby forcing the former $sock (and it's ->fp) out of scope. Second, the connect() method for $sock checks to see if it already has an allocated $fp; and if so, does an fclose. While this example isn't practical, this problem directly affects PEAR's HTTP_Request code (but this still isn't a PEAR issue). S Previous Comments: [2004-04-14 22:34:20] [EMAIL PROTECTED] Why woudln't it run out of file handles when you never CLOSE the socket..? [2004-04-14 11:41:00] [EMAIL PROTECTED] Description: See the attached code; it has been isolated from PEAR (core) and PEAR::Net_Socket. Basically, after a certain number of iterations (Linux, PHP4.3.4 and 4.3.6RC3, likely others), PHP runs out of file resources. Warning: fsockopen(): unable to connect to 192.168.100.51:80 in /home/sean/www/dev3/crashing_resources.php on line 51 ERROR: 24 - Too many open files This SEEMS to be a leak (file handles are never closed?) in method_exists, get_classname or get_parent_classname, because if I remove the ShrunkenPEAR constructor (OR, the _ShrunkenPEAR method), the code does not fail. Additionally, if I instanciate ShrunkenSocket as $sock = new ShrunkenSocket() (value instead of reference), the error is also absent. The reason I'm using a reference: PEAR::HTTP_Request instanciates Net_Socket as such. Also, as mentioned in a comment in the code, if I change the die to an echo, the script segfaults after ~65535 iterations (which seems like an overflow problem). ** Note: this was originally posted to internals@ (PHP-DEV), but did not get a response.** This COULD be a critical overflow problem (when segfaulting), but I don't know enough about the matter to declare it so. Reproduce code: --- http://sean.caedmon.net/php/crashing_resources.phps Expected result: (see description) Actual result: -- (see description) -- Edit this bug report at http://bugs.php.net/?id=27992&edit=1
#21544 [Csd->Opn]: --with-mssql uses a lot of undeclared functions
ID: 21544 Updated by: [EMAIL PROTECTED] Reported By: php at dark-id dot de -Status: Closed +Status: Open Bug Type: MSSQL related Operating System: ANY PHP Version: 4.3.0 New Comment: re-opened. This is still happening (or again happening) for me. 4.3.6RC3 (and CVS HEAD (4_3)). Attached is a patch to fix this. I'm not a c guy, though, so please verify. S --- Index: ext/mssql/php_mssql.c === RCS file: /repository/php-src/ext/mssql/php_mssql.c,v retrieving revision 1.86.2.31 diff -u -r1.86.2.31 php_mssql.c --- ext/mssql/php_mssql.c 30 Mar 2004 17:54:38 - 1.86.2.31 +++ ext/mssql/php_mssql.c 14 Apr 2004 15:18:18 - @@ -336,7 +336,7 @@ dbsetlogintime(MS_SQL_G(connect_timeout)); if (MS_SQL_G(timeout) < 0) MS_SQL_G(timeout) = 60; dbsettime(MS_SQL_G(timeout)); - dbsetmaxprocs((SHORT)MS_SQL_G(max_procs)); + dbsetmaxprocs((int)MS_SQL_G(max_procs)); return SUCCESS; } Previous Comments: [2003-01-09 16:37:08] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Extended checks for where FreeTDS is installed has been added to the configure script [2003-01-09 08:42:20] [EMAIL PROTECTED] Even with the latest freetds, it looks: DBMSGHANDLE_PROC is not defined, DBERRHANDLE is redefined, DBSETOPT is redefined, and dbsetopt hasn't got enough argument at line: 502,511,564,615,624. [2003-01-09 08:25:47] [EMAIL PROTECTED] It looks this happen because it uses by default /usr/local/freetds/ even if it doesn't exist. Not enough verifications on the config.m4... Reclassifing. [2003-01-09 08:22:41] [EMAIL PROTECTED] Verified... Due to the changes of fmk... [2003-01-09 06:37:58] php at dark-id dot de compiling of php 4.3.0 terminates with ../php-4.3.0/ext/mssql/php_mssql.c: In function `zm_activate_mssql': ../php-4.3.0/ext/mssql/php_mssql.c:334: `SHORT' undeclared (first use in this function) ../php-4.3.0/ext/mssql/php_mssql.c:334: (Each undeclared identifier is reported only once ../php-4.3.0/ext/mssql/php_mssql.c:334: for each function it appears in.) when configured with --with-mssql. Any hints? -- Edit this bug report at http://bugs.php.net/?id=21544&edit=1
#27760 [NEW]: file_exists function does not produce correct result
From: sean at bidamerica dot com
Operating system: Windows 2000 SP4
PHP version: 4.3.5
PHP Bug Type: *Directory/Filesystem functions
Bug description: file_exists function does not produce correct result
Description:
When using the file_exists function the function produces a only false
output.
Reproduce code:
---
Using:
Windows 2000
Service Pack 4
File System: NTFS
WebService: IIS 5
Example Function in Use:
if(file_exists('./hello.php')
{
}
The file does exist in the same directory, but however it produces a
false.
Expected result:
I expect it to output true.
Actual result:
--
False
--
Edit bug report at http://bugs.php.net/?id=27760&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27760&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27760&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27760&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27760&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27760&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27760&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27760&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27760&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27760&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27760&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27760&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27760&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27760&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27760&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27760&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27760&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27760&r=float
#27302 [Fbk->Bgs]: Odd behavior loading extensions (SQLite)
ID: 27302 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: Unknown/Other Function Operating System: Linux 2.4.24-6um PHP Version: 4.3.4 New Comment: You're 100% correct. Thanks for the pointer. It's really confusing that PHP reports the file, even though it's not actually using it, but I understand why. Closing (my own bogus (-: ) (how embarassing) Thanks again. S Previous Comments: [2004-02-18 01:09:38] [EMAIL PROTECTED] You probably misconfigured PHP when you built it: --with-config-file-path=PATH Sets the path in which to look for php.ini, defaults to PREFIX/lib This is a directory, not a path to the file name itself. [2004-02-18 00:25:08] [EMAIL PROTECTED] Description: Please take a look at: http://www.roguecoders.com/bugs/php_sqlite_load.txt You'll see the PHP reports that it will use php.ini, but SQLite doesn't get loaded unless I implicitly tell php to use the SAME php.ini. I've asked around.. nobody can figure it out. S Reproduce code: --- see http://www.roguecoders.com/bugs/php_sqlite_load.txt Expected result: see http://www.roguecoders.com/bugs/php_sqlite_load.txt Actual result: -- see http://www.roguecoders.com/bugs/php_sqlite_load.txt -- Edit this bug report at http://bugs.php.net/?id=27302&edit=1
#16057 [Com]: ftp_nlist() and ftp_rawlist() return nothing
ID: 16057 Comment by: sean at abcvoice dot com Reported By: ryan at wonko dot com Status: Closed Bug Type: FTP related Operating System: Windows 2000 Advanced Server PHP Version: 4.1.2 New Comment: Hate to be a "Me Too" poster, but: OS: Windows XP (SP1) PHP: 4.3.2 When connecting to an FTP and getting a rawlist, if I'm getting the root directory and it contains a colon (:) then rawlist (and nlist) return nothing. If I'm getting a rawlist of something in a subdirectory of root (even if root contains a colon) then it works every time. Previous Comments: [2004-01-10 13:19:21] bug at nexus-zone dot com same problem apears on version 4.3.4 will it ever work? [2003-12-23 14:35:29] mfeldNOSPAMPLEASE at mftronic dot de I'm using PHP 4.3.2 on WinXP SP1, and when using the ftp_Xlist() functions, it sometimes works and sometimes not (returns bool(false)) - almost randomly. Inserting a "var_dump()" has sometimes increased my chances that such a call works, like $dirlist = ftp_rawlist($conn_id, ""); var_dump($dirlist); [2003-12-16 04:55:45] mnares at cox dot net This issue is still not fixed...I am running PHP 4.3.3 on Windows XP SP 1, and I still get this error. [2003-12-12 16:19:23] pdavis at pobox dot com PHP 4.3.3 seems to be showing the same problem. When trying to connect to my own FTP server (Windows/IIS) and checking the FTP log file, it seems that the login and CWD are successful but no directory request ever comes through. I moved the code over to a Linux server and connected to the IIS FTP server that I was originally trying to connect to and everything worked fine. [2002-08-16 10:03:51] [EMAIL PROTECTED] Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php This issue appears to be fixed in the latest CVS. You can grab a snapshot of it here: http://snaps.php.net/win32/ 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/16057 -- Edit this bug report at http://bugs.php.net/?id=16057&edit=1
#25130 [Opn]: Typos in 'configure' script
ID: 25130
User updated by: sean dot healey at bayernlb dot co dot uk
Reported By: sean dot healey at bayernlb dot co dot uk
Status: Open
Bug Type: Compile Failure
Operating System: Solaris 9
PHP Version: 5.0.0b1 (beta1)
New Comment:
Ok, Not *quite* the same problem.
The issues in the configure script seem to have been resolved, however
we still seem to have the issue with the 'iconv' failing to load.
Previous Comments:
[2003-08-19 12:29:48] sean dot healey at bayernlb dot co dot uk
Tried the latest CVS snapshot, and got the same problem.
Here's the debug.log and my LD_LIBRARY_PATH / INCLUDE settings:
bash-2.05# cat debug.log
CONFIGURE: './configure' '--prefix=/opt/php'
'--localstatedir=/var/php' '--with-apache2=/usr/build/httpd-2.0.47'
'--with-apxs2=/opt/apache/2.0/bin/apxs'
'--with-sybase-ct=/opt/sybase/11.9.2' '--with-db4' '--enable-sysvmsg'
'--enable-sysvsem' '--enable-sysvshm'
CC: gcc
CFLAGS: -g -O2 -pthreads
CPPFLAGS:-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS
-D_REENTRANT
CXX:
CXXFLAGS:
INCLUDES:-I$(top_builddir)/Zend -I/usr/local/include/libxml2
LDFLAGS:-L/usr/local/BerkeleyDB.4.1/lib -ldb-4.1 -R/usr/ucblib
-L/usr/ucblib -R/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-R/usr/local/BerkeleyDB.4.1/lib -L/usr/local/BerkeleyDB.4.1/lib
-R/usr/local/lib -L/usr/local/lib
LIBS: -ldb-4.1 -lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2 -lz
-liconv -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl
DLIBS:
SAPI: apache2handler
PHP_RPATHS: /usr/ucblib
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
/usr/local/BerkeleyDB.4.1/lib /usr/local/lib
uname -a: SunOS tstsvr 5.9 Generic_112233-03 sun4m sparc
SUNW,SPARCstation-20
gcc -o conftest -g -O2 -pthreads -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -L/usr/local/BerkeleyDB.4.1/lib
-ldb-4.1 -R/usr/ucblib -L/usr/ucblib
-R/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-R/usr/local/BerkeleyDB.4.1/lib -L/usr/local/BerkeleyDB.4.1/lib
-R/usr/local/lib -L/usr/local/lib conftest.c -ldb-4.1 -lresolv -lm -ldl
-lnsl -lsocket -lgcc -lxml2 -lz -liconv -lm -lsocket -lnsl -lxml2 -lz
-liconv -lm -lsocket -lnsl 1>&5
ld: fatal: library -liconv: not found
ld: fatal: library -liconv: not found
ld: fatal: File processing errors. No output written to conftest
collect2: ld returned 1 exit status
bash-2.05#
bash-2.05#
bash-2.05# echo $LD_LIBRARY_PATH
/opt/sybase/11.9.2/lib:/usr/openwin/lib:/usr/local/lib:/usr/ccs/lib
bash-2.05# echo $INCLUDE
/opt/sybase/11.9.2/include:/usr/openwin/include:/usr/local/include
bash-2.05#
I just got PHP 4.3.2 to successfully build on this same platform, so
I'm probably not going to pursue the 5.0 route - unless it would be of
some help to you guys. I'm happy to carry on bashing away at this if it
will benefit your beta testing :-)) If not, let me know.
[2003-08-18 11:46:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
many bugs have been fixed in CVS since the beta was released.
[2003-08-18 11:43:42] sean dot healey at bayernlb dot co dot uk
Sorry, I should have mentioned that I did a search for the offending
library:
# find /usr -name iconv* -print
/usr/bin/iconv
/usr/lib/iconv
/usr/lib/iconv/iconv_data
/usr/include/iconv.h
/usr/build/php-5.0.0b1/ext/iconv
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv001.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv002.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv003.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_mime_decode.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_mime_encode.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_strlen.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_strpos.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_strrpos.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_substr.phpt
/usr/build/php-5.0.0b1/ext/iconv/iconv.c
/usr/build/php-5.0.0b1/ext/iconv/iconv.dsp
[2003-08-18 11:37:56] sean dot healey at bayernlb dot co dot uk
Description:
While trying to get PHP 5.0 to compile, I've found a couple of bugs in
the configure script.
1. There are 2 instances of a call 'grep -E {...args...}'
Under Solaris 9, the '-E' switch is only valid on the alternate version
of grep - '/usr/xpg4/bin/grep'. I added the necessary path to thes
#25130 [Fbk->Opn]: Typos in 'configure' script
ID: 25130
User updated by: sean dot healey at bayernlb dot co dot uk
Reported By: sean dot healey at bayernlb dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: Solaris 9
PHP Version: 5.0.0b1 (beta1)
New Comment:
Tried the latest CVS snapshot, and got the same problem.
Here's the debug.log and my LD_LIBRARY_PATH / INCLUDE settings:
bash-2.05# cat debug.log
CONFIGURE: './configure' '--prefix=/opt/php'
'--localstatedir=/var/php' '--with-apache2=/usr/build/httpd-2.0.47'
'--with-apxs2=/opt/apache/2.0/bin/apxs'
'--with-sybase-ct=/opt/sybase/11.9.2' '--with-db4' '--enable-sysvmsg'
'--enable-sysvsem' '--enable-sysvshm'
CC: gcc
CFLAGS: -g -O2 -pthreads
CPPFLAGS:-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS
-D_REENTRANT
CXX:
CXXFLAGS:
INCLUDES:-I$(top_builddir)/Zend -I/usr/local/include/libxml2
LDFLAGS:-L/usr/local/BerkeleyDB.4.1/lib -ldb-4.1 -R/usr/ucblib
-L/usr/ucblib -R/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-R/usr/local/BerkeleyDB.4.1/lib -L/usr/local/BerkeleyDB.4.1/lib
-R/usr/local/lib -L/usr/local/lib
LIBS: -ldb-4.1 -lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2 -lz
-liconv -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl
DLIBS:
SAPI: apache2handler
PHP_RPATHS: /usr/ucblib
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
/usr/local/BerkeleyDB.4.1/lib /usr/local/lib
uname -a: SunOS tstsvr 5.9 Generic_112233-03 sun4m sparc
SUNW,SPARCstation-20
gcc -o conftest -g -O2 -pthreads -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -L/usr/local/BerkeleyDB.4.1/lib
-ldb-4.1 -R/usr/ucblib -L/usr/ucblib
-R/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-R/usr/local/BerkeleyDB.4.1/lib -L/usr/local/BerkeleyDB.4.1/lib
-R/usr/local/lib -L/usr/local/lib conftest.c -ldb-4.1 -lresolv -lm -ldl
-lnsl -lsocket -lgcc -lxml2 -lz -liconv -lm -lsocket -lnsl -lxml2 -lz
-liconv -lm -lsocket -lnsl 1>&5
ld: fatal: library -liconv: not found
ld: fatal: library -liconv: not found
ld: fatal: File processing errors. No output written to conftest
collect2: ld returned 1 exit status
bash-2.05#
bash-2.05#
bash-2.05# echo $LD_LIBRARY_PATH
/opt/sybase/11.9.2/lib:/usr/openwin/lib:/usr/local/lib:/usr/ccs/lib
bash-2.05# echo $INCLUDE
/opt/sybase/11.9.2/include:/usr/openwin/include:/usr/local/include
bash-2.05#
I just got PHP 4.3.2 to successfully build on this same platform, so
I'm probably not going to pursue the 5.0 route - unless it would be of
some help to you guys. I'm happy to carry on bashing away at this if it
will benefit your beta testing :-)) If not, let me know.
Previous Comments:
[2003-08-18 11:46:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
many bugs have been fixed in CVS since the beta was released.
[2003-08-18 11:43:42] sean dot healey at bayernlb dot co dot uk
Sorry, I should have mentioned that I did a search for the offending
library:
# find /usr -name iconv* -print
/usr/bin/iconv
/usr/lib/iconv
/usr/lib/iconv/iconv_data
/usr/include/iconv.h
/usr/build/php-5.0.0b1/ext/iconv
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv001.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv002.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv003.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_mime_decode.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_mime_encode.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_strlen.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_strpos.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_strrpos.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_substr.phpt
/usr/build/php-5.0.0b1/ext/iconv/iconv.c
/usr/build/php-5.0.0b1/ext/iconv/iconv.dsp
[2003-08-18 11:37:56] sean dot healey at bayernlb dot co dot uk
Description:
While trying to get PHP 5.0 to compile, I've found a couple of bugs in
the configure script.
1. There are 2 instances of a call 'grep -E {...args...}'
Under Solaris 9, the '-E' switch is only valid on the alternate version
of grep - '/usr/xpg4/bin/grep'. I added the necessary path to these
calls and the error went away.
2. I found that there are a number of instances of paths being built
containing the string 'usrucb'. This should in fact be '/usr/ucb'.
3. Although I fixed the above, I still can't get it to compile - there
seems to be some issue w
#25130 [Opn]: Typos in 'configure' script
ID: 25130
User updated by: sean dot healey at bayernlb dot co dot uk
Reported By: sean dot healey at bayernlb dot co dot uk
Status: Open
Bug Type: Compile Failure
Operating System: Solaris 9
PHP Version: 5.0.0b1 (beta1)
New Comment:
Sorry, I should have mentioned that I did a search for the offending
library:
# find /usr -name iconv* -print
/usr/bin/iconv
/usr/lib/iconv
/usr/lib/iconv/iconv_data
/usr/include/iconv.h
/usr/build/php-5.0.0b1/ext/iconv
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv001.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv002.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv003.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_mime_decode.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_mime_encode.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_strlen.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_strpos.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_strrpos.phpt
/usr/build/php-5.0.0b1/ext/iconv/tests/iconv_substr.phpt
/usr/build/php-5.0.0b1/ext/iconv/iconv.c
/usr/build/php-5.0.0b1/ext/iconv/iconv.dsp
Previous Comments:
[2003-08-18 11:37:56] sean dot healey at bayernlb dot co dot uk
Description:
While trying to get PHP 5.0 to compile, I've found a couple of bugs in
the configure script.
1. There are 2 instances of a call 'grep -E {...args...}'
Under Solaris 9, the '-E' switch is only valid on the alternate version
of grep - '/usr/xpg4/bin/grep'. I added the necessary path to these
calls and the error went away.
2. I found that there are a number of instances of paths being built
containing the string 'usrucb'. This should in fact be '/usr/ucb'.
3. Although I fixed the above, I still can't get it to compile - there
seems to be some issue with inclusion of a library 'iconv'. I supply
the bebug.log file below:
# cat debug.log
CONFIGURE: './configure' '--prefix=/opt/php'
'--localstatedir=/var/php' '--with-apache2=/usr/build/httpd-2.0.47'
'--with-apxs2=/opt/apache/2.0/bin/apxs'
'--with-sybase-ct=/opt/sybase/11.9.2' '--with-db4' '--enable-sysvmsg'
'--enable-sysvsem' '--enable-sysvshm'
CC: gcc
CFLAGS: -g -O2 -pthreads
CPPFLAGS:-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS
-D_REENTRANT
CXX:
CXXFLAGS:
INCLUDES:-I/opt/apache/2.0/include -I$(top_builddir)/Zend
-I/usr/include/libxml2 -I/usr/local/include/libxml2
LDFLAGS:-L/usr/local/BerkeleyDB.4.1/lib -ldb-4.1
-R/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-R/usr/local/BerkeleyDB.4.1/lib -L/usr/local/BerkeleyDB.4.1/lib
-R/usr/local/lib -L/usr/local/lib
LIBS: -lz -ldb-4.1 -lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2
-lz -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl
DLIBS:
SAPI: apache2handler
PHP_RPATHS: /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
/usr/local/BerkeleyDB.4.1/lib /usr/local/lib
uname -a: SunOS tstsvr 5.9 Generic_112233-03 sun4m sparc
SUNW,SPARCstation-20
gcc -o conftest -g -O2 -pthreads -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -L/usr/local/BerkeleyDB.4.1/lib
-ldb-4.1 -R/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-R/usr/local/BerkeleyDB.4.1/lib -L/usr/local/BerkeleyDB.4.1/lib
-R/usr/local/lib -L/usr/local/lib conftest.c -lz -ldb-4.1 -lresolv -lm
-ldl -lnsl -lsocket -lgcc -lxml2 -lz -lm -lsocket -lnsl -lxml2 -lz
-liconv -lm -lsocket -lnsl 1>&5
ld: fatal: library -liconv: not found
ld: fatal: File processing errors. No output written to conftest
collect2: ld returned 1 exit status
In the meantime, I'm going to download and compile the latest stable
version.
Cheers :-)
--
Edit this bug report at http://bugs.php.net/?id=25130&edit=1
#25130 [NEW]: Typos in 'configure' script
From: sean dot healey at bayernlb dot co dot uk
Operating system: Solaris 9
PHP version: 5.0.0b1 (beta1)
PHP Bug Type: Compile Failure
Bug description: Typos in 'configure' script
Description:
While trying to get PHP 5.0 to compile, I've found a couple of bugs in the
configure script.
1. There are 2 instances of a call 'grep -E {...args...}'
Under Solaris 9, the '-E' switch is only valid on the alternate version of
grep - '/usr/xpg4/bin/grep'. I added the necessary path to these calls and
the error went away.
2. I found that there are a number of instances of paths being built
containing the string 'usrucb'. This should in fact be '/usr/ucb'.
3. Although I fixed the above, I still can't get it to compile - there
seems to be some issue with inclusion of a library 'iconv'. I supply the
bebug.log file below:
# cat debug.log
CONFIGURE: './configure' '--prefix=/opt/php' '--localstatedir=/var/php'
'--with-apache2=/usr/build/httpd-2.0.47'
'--with-apxs2=/opt/apache/2.0/bin/apxs'
'--with-sybase-ct=/opt/sybase/11.9.2' '--with-db4' '--enable-sysvmsg'
'--enable-sysvsem' '--enable-sysvshm'
CC: gcc
CFLAGS: -g -O2 -pthreads
CPPFLAGS:-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS
-D_REENTRANT
CXX:
CXXFLAGS:
INCLUDES:-I/opt/apache/2.0/include -I$(top_builddir)/Zend
-I/usr/include/libxml2 -I/usr/local/include/libxml2
LDFLAGS:-L/usr/local/BerkeleyDB.4.1/lib -ldb-4.1
-R/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-R/usr/local/BerkeleyDB.4.1/lib -L/usr/local/BerkeleyDB.4.1/lib
-R/usr/local/lib -L/usr/local/lib
LIBS: -lz -ldb-4.1 -lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2
-lz -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl
DLIBS:
SAPI: apache2handler
PHP_RPATHS: /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
/usr/local/BerkeleyDB.4.1/lib /usr/local/lib
uname -a: SunOS tstsvr 5.9 Generic_112233-03 sun4m sparc
SUNW,SPARCstation-20
gcc -o conftest -g -O2 -pthreads -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -L/usr/local/BerkeleyDB.4.1/lib
-ldb-4.1 -R/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-R/usr/local/BerkeleyDB.4.1/lib -L/usr/local/BerkeleyDB.4.1/lib
-R/usr/local/lib -L/usr/local/lib conftest.c -lz -ldb-4.1 -lresolv -lm
-ldl -lnsl -lsocket -lgcc -lxml2 -lz -lm -lsocket -lnsl -lxml2 -lz
-liconv -lm -lsocket -lnsl 1>&5
ld: fatal: library -liconv: not found
ld: fatal: File processing errors. No output written to conftest
collect2: ld returned 1 exit status
In the meantime, I'm going to download and compile the latest stable
version.
Cheers :-)
--
Edit bug report at http://bugs.php.net/?id=25130&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25130&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25130&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25130&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25130&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25130&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25130&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25130&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25130&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25130&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25130&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25130&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25130&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25130&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25130&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25130&r=gnused
#24929 [NEW]: date("G") returns nothing
From: sean at shrum dot net
Operating system: Linux
PHP version: 4.3.2
PHP Bug Type: Date/time related
Bug description: date("G") returns nothing
Description:
I get nothing back from the date("G") function call. Granted, I am using
a offset value with it but the offset works with every other date call so
I know the offset value is not the cause
Reproduce code:
---
$offset = strtotime("+3 hours");
$time_vars["hour_24"] = date("G", $offset);
Expected result:
$time_vars["hour_24"] should have the current hour in 24-hour format
without leading zeros. If it is 1 am, the result should be "4" (due to the
offset). If it is 5 pm, the result should be "22" (due to the offset).
Actual result:
--
nothing; blank value
--
Edit bug report at http://bugs.php.net/?id=24929&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24929&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24929&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24929&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24929&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24929&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24929&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24929&r=support
Expected behavior: http://bugs.php.net/fix.php?id=24929&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24929&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24929&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24929&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24929&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24929&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24929&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24929&r=gnused
#16585 [Com]: Use of $_SESSION to set variable doesn't save variable
ID: 16585
Comment by: sean at seansilas dot com
Reported By: cedric dot dufour at cogito-ergo-soft dot com
Status: No Feedback
Bug Type: Session related
Operating System: Windows XP
PHP Version: 4.1.2
New Comment:
This bug is EXTREMELEY ANNOYING, and very hard to replicate. Sometimes
it happens, other times it doesn't. Seems to happen more when the
server has been idle for awhile.
The big problem here, is that I cannot upgrade my PHP, because I am
using a remote hosting company that has 4.1.2 installed.
I have no idea what to do, and I'm extremely frustrated.
SS
Previous Comments:
[2002-05-14 00:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, 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".
[2002-04-13 14:11:08] [EMAIL PROTECTED]
It's propably the same issue as everyone else is having.
Please try the PHP 4.2.0RC3 from http://www.php.net/~derick/
as others have reported that it works fine for them.
And don't forget to replace the php4ts.dll in your system
with the one in the 4.2.0RC3 package.
[2002-04-13 06:50:03] cedric dot dufour at cogito-ergo-soft dot com
Following the 'Session handling' documentation and expriencing problems
with a production script, I wrote the following test script:
test.php:
\r\n";
if( !isset( $_SESSION['Test'] ) )
{
$_SESSION['Test'] = "bla bla bla";
echo "Defined : ".$_SESSION['Test']."\r\n";
}
else
{
echo "Existing : ".$_SESSION['Test']."\r\n";
}
//session_write_close();
?>
which I expect to set the 'Test' session variable on the first call to
the page and then return the 'Test' session variable on subsequent
calls to the script.
This works FINE with PHP 4.1.1 but DOES NOT WORK with PHP 4.1.2 (though
the session ID is the same). I had to revert to the old
'session_register()' function for the script to work in PHP 4.1.2,
$HTTP_SESSION_VARS not working either.
Any clue ?
Ce.D
--
Edit this bug report at http://bugs.php.net/?id=16585&edit=1
#16548 [NoF->Opn]: exec or system a daemon will catch the port for this session
ID: 16548 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: RED HAT Linux 7.2 PHP Version: 4.1.2 & 4.3.0 New Comment: Re-opened. I this has been happening to us, as well (php4.2.2 / CGI (command line) / RH7.3 x86). We are unable to reproduce this reliable, but our error trap is showing many "unable to fork" errors on exec calls. S Previous Comments: [2003-01-16 11:20:37] [EMAIL PROTECTED] I have a similar problem here : Apache 1.3.27, PHP 4.3.0 . It happens when i restart dhcpd via a setuid script launched using exec() inside PHP. Everything looks normal : tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN 6024/httpd But if i kill httpd : tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN 6457/dhcpd Tried launching the script with system() , exec(), putting nohup and & in the end... nothing works. I have to kill dhcpd before i have a chance to start httpd again... [2002-12-25 01:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, 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". [2002-12-07 01:54:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-29 11:04:07] [EMAIL PROTECTED] this bug does not relate to session module. [2002-09-26 10:43:24] [EMAIL PROTECTED] Related to #15642 and #15529. 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/16548 -- Edit this bug report at http://bugs.php.net/?id=16548&edit=1
#21650 [Com]: libphp4.so not found after a successful compile
ID: 21650 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: AIX 4.3.3 PHP Version: 4.3.0 New Comment: More info... box: pentium 133 os: redhat 7.2 configure: ./configure --with-apsx2=/usr/local/apache/bin/apxs --with-gettext --with-xml --with-mcrypt --with-imap --with-imap-ssl --with-mysql I've tried these things with no success: 1. updating to the latest libtool (libtool-1.4d.tar.gz) 2. adjusting libtool parameters build_libtool_libs & build_old_libs 3. rerunning the last libtool command without -lcrypt 4. make libs/libphp4.bundle (creates libphp4.so, but it won't load when I restart apache). 5. updating to latest php snapshot (php4-STABLE-200301200430.tar.gz) and retrying steps 2, 3, 4 All of this, just to get mysql to work with php for imp preferences (www.horde.org/imp/) Previous Comments: [2003-01-20 04:02:41] [EMAIL PROTECTED] build_libtool_libs already set to yes :) [2003-01-19 22:38:30] [EMAIL PROTECTED] I just hit this bug tonight. It appears this bug has been around in one form or another for over a year, but I haven't seen a solid solution yet. Basic bug: libphp4.la created instead of libphp4.so. Closest solution so far: The libphp4.so not is created by make because the libtool have a flag set to no. The libtool is created by configure; before you launch make, edit libtool and set build_libtool_libs=yes. After launched make, under .libs you find libphp4.so.0:move it under libs as libphp4.so and run make install. This did not work for me (libphp4.so.0 file never created - .libs directory isn't created until make install...). Maybe it will work for you. I will keep digging. If I find a solution, I will post it... Research: When I grep the Makefile for libphp4.so, I see: libs/libphp4.bundle: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OB JS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $@ && cp $@ libs/libphp4.so This is a hint towards the solution... [2003-01-15 02:40:17] [EMAIL PROTECTED] config : ./configure --with-apxs=/system/www/bin/apxs gcc version : 2.9-aix43-010414 (yep,this is compiled by IBM for rs/6000 platform) after a successful compiling phase following error message displayed... cut here Installing PHP SAPI module [activating module `php4' in /system/www/conf/httpd.conf] cp libs/libphp4.so /system/www/libexec/libphp4.so cp: libs/libphp4.so: A file or directory in the path name does not exist. apxs:Break: Command failed with rc=1 make: 1254-004 The error code from the last command is 1. Stop. - cut here there are libphp4.la and libphp4.a files in libs directory. -- Edit this bug report at http://bugs.php.net/?id=21650&edit=1
#21650 [Com]: libphp4.so not found after a successful compile
ID: 21650 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: AIX 4.3.3 PHP Version: 4.3.0 New Comment: I just hit this bug tonight. It appears this bug has been around in one form or another for over a year, but I haven't seen a solid solution yet. Basic bug: libphp4.la created instead of libphp4.so. Closest solution so far: The libphp4.so not is created by make because the libtool have a flag set to no. The libtool is created by configure; before you launch make, edit libtool and set build_libtool_libs=yes. After launched make, under .libs you find libphp4.so.0:move it under libs as libphp4.so and run make install. This did not work for me (libphp4.so.0 file never created - .libs directory isn't created until make install...). Maybe it will work for you. I will keep digging. If I find a solution, I will post it... Research: When I grep the Makefile for libphp4.so, I see: libs/libphp4.bundle: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OB JS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $@ && cp $@ libs/libphp4.so This is a hint towards the solution... Previous Comments: [2003-01-15 02:40:17] [EMAIL PROTECTED] config : ./configure --with-apxs=/system/www/bin/apxs gcc version : 2.9-aix43-010414 (yep,this is compiled by IBM for rs/6000 platform) after a successful compiling phase following error message displayed... cut here Installing PHP SAPI module [activating module `php4' in /system/www/conf/httpd.conf] cp libs/libphp4.so /system/www/libexec/libphp4.so cp: libs/libphp4.so: A file or directory in the path name does not exist. apxs:Break: Command failed with rc=1 make: 1254-004 The error code from the last command is 1. Stop. - cut here there are libphp4.la and libphp4.a files in libs directory. -- Edit this bug report at http://bugs.php.net/?id=21650&edit=1
#14754 [Com]: java.* configuration values from php.ini lost on subsequent executions
ID: 14754 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Java related Operating System: Windows XP Home / Apache 1.3.24 PHP Version: 4.2.1 & 4.3.0-dev New Comment: Some people have suggested that switching to use PHP in CGI-mode alleviates this problem. (However, I am unwilling to do this to solve the problem anyway.) Does this recommendation maybe shed some light on the cause? Previous Comments: [2002-11-05 09:58:27] [EMAIL PROTECTED] I have switched from hotspot jvm to classic jvm but the problem continues. [2002-10-27 12:31:34] [EMAIL PROTECTED] I have experienced the same problem. But switched from hotspot jvm to classic and problem disappeared. I am using: php 4.2.1, apache 1.3.xx Win2k, php.ini [Java] java.class.path = E:\php4.2.1\extensions\php_java.jar java.home = E:\jdk1.3\jre java.library = E:\jdk1.3\jre\bin\classic\jvm.dll [2002-10-24 06:23:03] [EMAIL PROTECTED] I experimented this from php 4.2.2. Now, I'm running php 4.2.4 (the snapshot from 23-Oct-2002 17:22) on Apache 1.3.27 and WinNT 4.0 and the error still appears. [2002-10-08 14:51:48] [EMAIL PROTECTED] Marking as open and updating version [2002-10-08 11:12:20] [EMAIL PROTECTED] Iam still facing this bug even after trying with the snapshot specified.Iam running on apache 1.3.26 and win2K. I first experienced this on Php 4.2.2. Actually I took a closer look at the source.It seems to me that the reference to the global pointer to jvm( java.c ) seems to be reset resulting in the call to jvm_create after the first request(when it shouldnt, as the pointer should still be valid as we are not releasing the jvm pointer). Since there was no call to jvm_destroy, I guess some internal resource has been locked up resulting in JNI_CreateVM returning -1(undefined error in JNI.h) on the subsequent calls. Any help would be highly appeciated 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/14754 -- Edit this bug report at http://bugs.php.net/?id=14754&edit=1
#19446 [Opn->Ver]: Incorrect Offset Reported
ID: 19446
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type: Date/time related
Operating System: Linux
PHP Version: 4.2.1
New Comment:
Confirmed. Also happens to newfoundland. Seems to be all fractional
offsets as stated:
\n";
putenv('TZ=Canada/Eastern');
print date('h:i:sa d/m/Y O T') ."\n";
?>
output:
12:55:52pm 18/09/2002 -021800 NDT
11:25:52am 18/09/2002 -0400 EDT
NOTE: Time is correct. Offset is incorrect.
S
Previous Comments:
[2002-09-16 21:30:51] [EMAIL PROTECTED]
Also occurs on other timezones that are not complete hours.
EG:
The Zones, Asia/Riyadh87, Asia/Riyadh88, Asia/Riyadh89 are the same and
suppose to be +0345. But I get +03424. Also the Abreviation is reported
as ?? I expected this to actually be either an actual abreviation.
[2002-09-16 21:00:53] [EMAIL PROTECTED]
I used this code to change timezones:
Asia/Calcutta has an offset of +0530 GMT or 5.5 hours ahead of GMT.
It reported the O date value as +051800 I expected it to be +0530 or
+053000
--
Edit this bug report at http://bugs.php.net/?id=19446&edit=1
#19467 [Opn]: Add a php-page to the distribution
ID: 19467 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Unknown/Other Function +Bug Type: Feature/Change Request Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: Changed category to "Feature/Change Request" Previous Comments: [2002-09-18 03:56:21] [EMAIL PROTECTED] Hi, Just a suggestion : I was very surprised not to find an example .php in the distribution. A tutorial should not really be covered but a couple of small examples would be nice. Geert -- Edit this bug report at http://bugs.php.net/?id=19467&edit=1
Bug #17530 Updated: PHP error mesage "File not uploaded" is unclear and misleading.
ID: 17530 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Output Control Operating System: Linux PHP Version: 4.2.1 New Comment: Just to clarify, is the current behavior going to remain? That is, if an [input type=file] field is left empty should I expect PHP to place "No file uploaded" in $php_errormsg? If so I can't see the benefit at all. It would be similar to PHP placing an error in $php_errormsg about a blank [input type=text] field saying "No characters entered". Tracking errors via $php_errormsg can be very useful for particular applications. However when junk like "No file uploaded" starts creeping in it clouds the intended purpose IMHO. Previous Comments: [2002-05-30 18:27:53] [EMAIL PROTECTED] Verified, even with current HEAD. The current code doesn't honor multiple fileloads regarding this error message. I also don't see much benefit in fixing this behaviour because if you're using multiple uploads you have to deal with them individually in the code anyway. How should the file upload deal with e.g. 5 uploads where only the first,third and fifth fields are actually uploaded with files? Output a message like "No file uploaded for field 2 and 4" ? Certainly not. There's a reason why track_errors isn't enabled by default. Unless you come up with a decent real-life sample where it is absolutely needed I don't see any need for it. [2002-05-30 15:26:19] [EMAIL PROTECTED] Visit: http://www.groupit.org/contribute/demonstrationarea/contenttypes/documents/b.21.html On this page there is one required file upload field, and a second optional field (for an image that can be automatically scaled and placed within the summary of the contribution). When a document file is specified, and an image is not, the error "File not uploaded" is stored within $php_errormsg. Presumably this is because the contrib_image variable is not set. Since this is not truly an error condition I think PHP should NOT log an error for this event. I imagine there are many other PHP-based sites with optional file upload fields that are now generating spurious error messages to site administrators (grin). This functionality was not evident in 4.1.2 or earlier versions. The $php_errormsg should contain actual errors only. Thanks for your time - and thanks for creating such a great development language! -- Edit this bug report at http://bugs.php.net/?id=17530&edit=1
Bug #17530: PHP error mesage "File not uploaded" is unclear and misleading.
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.1 PHP Bug Type: Output Control Bug description: PHP error mesage "File not uploaded" is unclear and misleading. Visit: http://www.groupit.org/contribute/demonstrationarea/contenttypes/documents/b.21.html On this page there is one required file upload field, and a second optional field (for an image that can be automatically scaled and placed within the summary of the contribution). When a document file is specified, and an image is not, the error "File not uploaded" is stored within $php_errormsg. Presumably this is because the contrib_image variable is not set. Since this is not truly an error condition I think PHP should NOT log an error for this event. I imagine there are many other PHP-based sites with optional file upload fields that are now generating spurious error messages to site administrators (grin). This functionality was not evident in 4.1.2 or earlier versions. The $php_errormsg should contain actual errors only. Thanks for your time - and thanks for creating such a great development language! -- Edit bug report at http://bugs.php.net/?id=17530&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17530&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17530&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17530&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17530&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17530&r=support Expected behavior: http://bugs.php.net/fix.php?id=17530&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17530&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17530&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17530&r=globals
Bug #17389: max_upload_filesize setting format is problematic
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.2.1
PHP Bug Type: *Configuration Issues
Bug description: max_upload_filesize setting format is problematic
The documentation states that max_upload_filesize is an
integer, although the result from ini_get is "2M". This is
problematic for the following reasons:
1. With the documentation stating the format as an
integer, code can be written to output BAD code such as:
$my_value = 2M;
I fell into this trap and didn't locate the problem easily
because my test installations (unfortunately) stated the
max_upload_filesize as a true integer inside php.ini.
2. It is not clear how PHP handles the output of GOOD code
like:
$my_value = "2M";
If I later have code like:
if ($my_value > $this_value)
// i.e., if ("2M" > "345")
Will it break? Will "2M" be considered an integer and
converted automatically to 2097152? If this is the case
then it is not immediately evident inside of the
documentation.
--
Edit bug report at http://bugs.php.net/?id=17389&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17389&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17389&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17389&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17389&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17389&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17389&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17389&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17389&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17389&r=globals
Bug #16976: preg_replace /e causes access violation
From: [EMAIL PROTECTED]
Operating system: Windows2000 / IIS5
PHP version: 4.1.2
PHP Bug Type: Regexps related
Bug description: preg_replace /e causes access violation
this code causes an access violation on IIS5/Windows2000/PHP4.1.2
Reports are that it works fine with apache4.0.6 (OS unknown):
code:' . htmlspecialchars('\\2') . ''", $str);
echo $str;
?>
S
--
Edit bug report at http://bugs.php.net/?id=16976&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16976&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16976&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16976&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16976&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16976&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16976&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16976&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16976&r=submittedtwice
Bug #16805 Updated: sem_remove(...) segfaults
ID: 16805 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Semaphore related Operating System: Linux 2.2.x (Debian) PHP Version: 4.0CVS-2002-04-24 Assigned To: derick New Comment: Creation is fine, but whenever I call sem_remove, segfault. Here's my complete system info: sean@adnagaporp:~$ uname -a Linux adnagaporp 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i686 unknown sean@adnagaporp:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 701.376 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 1399.19 sean@adnagaporp:~/bin$ ./php4-dev -v 4.3.0-dev (note: php4-dev is a symlink to my PHP4/CVS build) sean@adnagaporp:~/dev/sock$ php4-dev -q sem.php [Thu Apr 25 14:29:58 2002] Script: 'sem.php' --- /home/sean/cvs/php/php4/Zend/zend_execute.h(62) : Block 0x0822FEA8 status: Beginning: Overrun (magic=0x322E, expected=0x7312F8DC) End: Unknown --- Segmentation fault (sem.php is the script I posted above) if this helps: sean@adnagaporp:~/dev/sock$ ipcs -- Shared Memory Segments key shmid owner perms bytes nattchstatus 0x0200 15360 root 666 1024 13 0x00280267 132 root 644 1048576 1 -- Semaphore Arrays key semid owner perms nsems status 0x00280269 0 root 666 14 -- Message Queues key msqid owner perms used-bytes messages if I comment out the sem_remove line, I get a freshly created semaphore: -- Semaphore Arrays key semid owner perms nsems status 0x00280269 0 root 666 14 0x3241 1409 sean 666 3 and I can even do this, successfully, so I don't think it's a problem with my OS/config: sean@adnagaporp:~/dev/sock$ ipcrm sem 1409 resource deleted It segfaults as a regular user (sean) and also as root. PHP isn't generating core files for some reason, even though --enable-debug is on, or I'm just not looking in the right place.. ? Here's my gdb session: sean@adnagaporp:~/dev/sock$ gdb -q php4-dev (gdb) run -q sem.php Starting program: /home/sean/cvs/php/php4.3.0/php -q sem.php [Thu Apr 25 14:43:34 2002] Script: 'sem.php' --- /home/sean/cvs/php/php4/Zend/zend_execute.h(62) : Block 0x0822FA88 status: Beginning: Overrun (magic=0x331B, expected=0x7312F8DC) End: Unknown --- Program received signal SIGSEGV, Segmentation fault. 0x400e8bfe in free () from /lib/libc.so.6 (gdb) bt #0 0x400e8bfe in free () from /lib/libc.so.6 #1 0x400e8ad3 in free () from /lib/libc.so.6 #2 0x08165073 in shutdown_memory_manager (silent=0, clean_cache=0) at /home/sean/cvs/php/php4/Zend/zend_alloc.c:484 #3 0x08147a95 in php_request_shutdown (dummy=0x0) at /home/sean/cvs/php/php4/main/main.c:816 #4 0x0818c055 in main (argc=3, argv=0xbd84) at /home/sean/cvs/php/php4/sapi/cgi/cgi_main.c:1069 (gdb) frame 0 #0 0x400e8bfe in free () from /lib/libc.so.6 (gdb) frame 1 #1 0x400e8ad3 in free () from /lib/libc.so.6 (gdb) frame 2 #2 0x08165073 in shutdown_memory_manager (silent=0, clean_cache=0) at /home/sean/cvs/php/php4/Zend/zend_alloc.c:484 484 ZEND_DO_FREE(ptr); (gdb) frame 3 #3 0x08147a95 in php_request_shutdown (dummy=0x0) at /home/sean/cvs/php/php4/main/main.c:816 816 shutdown_memory_manager(CG(unclean_shutdown), 0 TSRMLS_CC); (gdb) frame 4 #4 0x0818c055 in main (argc=3, argv=0xbd84) at /home/sean/cvs/php/php4/sapi/cgi/cgi_main.c:1069 1069php_request_shutdown((void *) 0); (gdb) --- unfortunately, I don't know gdb any better than that. I can give you access to adnagaporp if you need it, Derick. Thanks again. S Previous Comments: [2002-04-25 14:21:56] [EMAIL PROTECTED] Can you please provide a self-contained script that should work but crashses? I can't reproduce this. Derick [2002-04-24 14:24:00] [EMAIL PROTECTED] sem_remove causes a segfau
Bug #16805: sem_remove(...) segfaults
From: [EMAIL PROTECTED] Operating system: Linux 2.2.x (Debian) PHP version: 4.0CVS-2002-04-24 PHP Bug Type: Semaphore related Bug description: sem_remove(...) segfaults sem_remove causes a segfault with the following script: * * Here's my terminal log: sean@adnagaporp:~/dev/sock$ php4-dev -v 4.3.0-dev sean@adnagaporp:~/dev/sock$ php4-dev -q sem.php [Wed Apr 24 14:21:56 2002] Script: 'sem.php' --- /home/sean/cvs/php/php4/Zend/zend_execute.h(62) : Block 0x08231DF0 status: Beginning: Overrun (magic=0x, expected=0x7312F8DC) End: Unknown --- Segmentation fault * And my php configuration: System Linux adnagaporp 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i686 Build Date Apr 24 2002 14:12:20 Configure Command './configure' '--enable-sockets' '--enable-pcntl' '--enable-shmop' '--enable-sysvsem' '--enable-debug' Server API CGI Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib Debug Build yes Thread Safety disabled PHP Streams enabled * S -- Edit bug report at http://bugs.php.net/?id=16805&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16805&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16805&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16805&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16805&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16805&r=support Expected behavior: http://bugs.php.net/fix.php?id=16805&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16805&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16805&r=submittedtwice
Bug #16771 Updated: posix_mkfifo does weird stuff with mode
ID: 16771
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: POSIX related
Operating System: Linux 2.2.x (Debian)
PHP Version: 4.0CVS-2002-04-23
New Comment:
Partially true (I tried it without the quotes before I updated from cvs
today):
posix_mkfifo('./FORK_FIFO', 666);
now gives:
prw-r--r--1 sean sean0 Apr 23 18:00 FORK_FIFO
better, but still not correct.
S
Previous Comments:
[2002-04-23 17:58:03] [EMAIL PROTECTED]
This is a usage error. You need to remove the quotes from around 0666.
[2002-04-23 17:47:49] [EMAIL PROTECTED]
posix_mkfifo('./FORK_FIFO', '0666'); // read&write by everyone
yeilds:
p-w---x--T1 sean sean0 Apr 23 17:47 FORK_FIFO
?
it SHOULD yeild:
prw-rw-rw-
The only way for me to get rw, it seems, is with '900', which gives:
prwr-T1 sean sean0 Apr 23 17:48 FORK_FIFO
(note: I don't even know what T is..)
It's messed up, to say the least.
S
--
Edit this bug report at http://bugs.php.net/?id=16771&edit=1
Bug #16771: posix_mkfifo does weird stuff with mode
From: [EMAIL PROTECTED]
Operating system: Linux 2.2.x (Debian)
PHP version: 4.0CVS-2002-04-23
PHP Bug Type: POSIX related
Bug description: posix_mkfifo does weird stuff with mode
posix_mkfifo('./FORK_FIFO', '0666'); // read&write by everyone
yeilds:
p-w---x--T1 sean sean0 Apr 23 17:47 FORK_FIFO
?
it SHOULD yeild:
prw-rw-rw-
The only way for me to get rw, it seems, is with '900', which gives:
prwr-T1 sean sean0 Apr 23 17:48 FORK_FIFO
(note: I don't even know what T is..)
It's messed up, to say the least.
S
--
Edit bug report at http://bugs.php.net/?id=16771&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16771&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16771&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16771&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16771&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16771&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16771&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16771&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16771&r=submittedtwice
Bug #16766: pcntl_waitpid segfaults on absence of third parameter
From: [EMAIL PROTECTED] Operating system: Linux 2.2.19pre17 i686 (Debian) PHP version: 4.0CVS-2002-04-23 PHP Bug Type: POSIX related Bug description: pcntl_waitpid segfaults on absence of third parameter Calling pcntl_waitpid without a third parameter causes a secmentation fault. Supplying it with 0 does not. (at least in my trials). Should be a simple fix. Sorry, I don't have --enable-debug, so I can't backtrace (no core). S -- Edit bug report at http://bugs.php.net/?id=16766&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16766&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16766&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16766&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16766&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16766&r=support Expected behavior: http://bugs.php.net/fix.php?id=16766&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16766&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16766&r=submittedtwice
Bug #16153 Updated: Kernel Panic on compile
ID: 16153 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Debian Unstable (sid) PHP Version: 4.0CVS-2002-03-18 New Comment: (yes, I know. I wasn't asking for support. Just reporting a kernel panic in case it really was PHP related. And yes, I know, that's a canned response. (-:) I just compiled again without the panic. Thanks for the quick response, but it looks like this is not PHP related after all. S Previous Comments: [2002-03-18 16:48:35] [EMAIL PROTECTED] A very likely cause is bad memory, or other broken hardware. Derick [2002-03-18 16:42:04] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php [2002-03-18 16:38:16] [EMAIL PROTECTED] I just got a kernel panic when running ./configure --enable-sockets. I did a (mostly) successful compile a few minutes ago, then a make clean, now, bye bye uptime. Attached it part of my terminal log. I'll try to reproduce it.. )-: S --- checking for sys/time.h... (cached) yes checking for sys/types.h... (cached) yes Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ... adnagaporp kernel: CPU 0: Machine Check Exception: 0004 Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ... adnagaporp kernel: Bank 4: b2040151<0>Kernel panic: CPU context corrupt -- Edit this bug report at http://bugs.php.net/?id=16153&edit=1
Bug #16153: Kernel Panic on compile
From: [EMAIL PROTECTED] Operating system: Debian Unstable (sid) PHP version: 4.0CVS-2002-03-18 PHP Bug Type: Compile Failure Bug description: Kernel Panic on compile I just got a kernel panic when running ./configure --enable-sockets. I did a (mostly) successful compile a few minutes ago, then a make clean, now, bye bye uptime. Attached it part of my terminal log. I'll try to reproduce it.. )-: S --- checking for sys/time.h... (cached) yes checking for sys/types.h... (cached) yes Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ... adnagaporp kernel: CPU 0: Machine Check Exception: 0004 Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ... adnagaporp kernel: Bank 4: b2040151<0>Kernel panic: CPU context corrupt -- Edit bug report at http://bugs.php.net/?id=16153&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16153&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16153&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16153&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16153&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16153&r=support Expected behavior: http://bugs.php.net/fix.php?id=16153&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16153&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16153&r=submittedtwice
Bug #15976 Updated: socket_get_status(...) returns nothing
ID: 15976 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Sockets related Operating System: Win32 (2000) AND Linux2.2 PHP Version: 4.1.2 New Comment: Oops. Regarding my previous comment: line 968 reads "what = zend_fetch_resource(socket TSRMLS_CC, -1, "File-Handle", &type, 1, le_socket);" in CVS, not what I posted above... S Previous Comments: [2002-03-12 21:44:49] [EMAIL PROTECTED] Alright. So, here's what I've dug up so far: file: [php]/ext/standard/file.c line: 968 code: zend_fetch_resource(socket_arg TSRMLS_CC,-1,"Socket -Handle",NULL,1,php_file_le_socket()); This always line returns false for a valid socket resource (I verified the resource using `is_resource($sock)` and `get_resource_type($sock)` for both my listen socket and my message socket. get_resource_type($sock) returns "Socket". So, when the next line (969), "ZEND_VERIFY_RESOURCE(what);" is called, it determines that 'what' is false and calls RETURN_NULL; I tried screwing with the args in zend_fetch_resource(...), but I don't know the API well enough (and my C/C++ is more than rusty). I hope someone takes a look at this soon, I currently have no way of knowing the status of my sockets (I need to know when a client disconnects -> eof ) S [2002-03-12 21:00:39] [EMAIL PROTECTED] It's a non-blocking socket, if that helps S [2002-03-09 17:34:26] [EMAIL PROTECTED] Also note: This is a listening socket (host / server / whatever) -- ie, not created with fsockopen; created with socket_create, socket_bind, socket_listen, socket_accept. There's a note in the manual about this not working properly, but I didn't see it in the bug DB. [2002-03-09 17:31:39] [EMAIL PROTECTED] socket_get_status is supposed to return an associative array, it _always_ returns null for me. No array, no object, no string print_r(socket_get_status($verifiedSocketResource)) prints nothing. I've tried this on two separate 4.1.x installs. The php4win version (4.1.1) and the Debian Unstable version (4.1.2 -- CGI). -- Edit this bug report at http://bugs.php.net/?id=15976&edit=1
Bug #15976 Updated: socket_get_status(...) returns nothing
ID: 15976 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Sockets related Operating System: Win32 (2000) AND Linux2.2 PHP Version: 4.1.2 New Comment: Alright. So, here's what I've dug up so far: file: [php]/ext/standard/file.c line: 968 code: zend_fetch_resource(socket_arg TSRMLS_CC,-1,"Socket -Handle",NULL,1,php_file_le_socket()); This always line returns false for a valid socket resource (I verified the resource using `is_resource($sock)` and `get_resource_type($sock)` for both my listen socket and my message socket. get_resource_type($sock) returns "Socket". So, when the next line (969), "ZEND_VERIFY_RESOURCE(what);" is called, it determines that 'what' is false and calls RETURN_NULL; I tried screwing with the args in zend_fetch_resource(...), but I don't know the API well enough (and my C/C++ is more than rusty). I hope someone takes a look at this soon, I currently have no way of knowing the status of my sockets (I need to know when a client disconnects -> eof ) S Previous Comments: [2002-03-12 21:00:39] [EMAIL PROTECTED] It's a non-blocking socket, if that helps S [2002-03-09 17:34:26] [EMAIL PROTECTED] Also note: This is a listening socket (host / server / whatever) -- ie, not created with fsockopen; created with socket_create, socket_bind, socket_listen, socket_accept. There's a note in the manual about this not working properly, but I didn't see it in the bug DB. [2002-03-09 17:31:39] [EMAIL PROTECTED] socket_get_status is supposed to return an associative array, it _always_ returns null for me. No array, no object, no string print_r(socket_get_status($verifiedSocketResource)) prints nothing. I've tried this on two separate 4.1.x installs. The php4win version (4.1.1) and the Debian Unstable version (4.1.2 -- CGI). -- Edit this bug report at http://bugs.php.net/?id=15976&edit=1
Bug #15976 Updated: socket_get_status(...) returns nothing
ID: 15976 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Sockets related Operating System: Win32 (2000) AND Linux2.2 PHP Version: 4.1.2 New Comment: It's a non-blocking socket, if that helps S Previous Comments: [2002-03-09 17:34:26] [EMAIL PROTECTED] Also note: This is a listening socket (host / server / whatever) -- ie, not created with fsockopen; created with socket_create, socket_bind, socket_listen, socket_accept. There's a note in the manual about this not working properly, but I didn't see it in the bug DB. [2002-03-09 17:31:39] [EMAIL PROTECTED] socket_get_status is supposed to return an associative array, it _always_ returns null for me. No array, no object, no string print_r(socket_get_status($verifiedSocketResource)) prints nothing. I've tried this on two separate 4.1.x installs. The php4win version (4.1.1) and the Debian Unstable version (4.1.2 -- CGI). -- Edit this bug report at http://bugs.php.net/?id=15976&edit=1
Bug #16010: phpinfo manual page bad grammar
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.1.2 PHP Bug Type: Documentation problem Bug description: phpinfo manual page bad grammar on http://www.php.net/manual/en/function.phpinfo.php, in the "phpinfo() options" table: Loaded modules and there respective settings. should be: Loaded modules and their respective settings. (is this the right place to report this sort of error?) S -- Edit bug report at http://bugs.php.net/?id=16010&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16010&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16010&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16010&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16010&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16010&r=support Expected behavior: http://bugs.php.net/fix.php?id=16010&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16010&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16010&r=submittedtwice
Bug #15976 Updated: socket_get_status(...) returns nothing
ID: 15976 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Sockets related Operating System: Win32 (2000) AND Linux2.2 PHP Version: 4.1.2 New Comment: Also note: This is a listening socket (host / server / whatever) -- ie, not created with fsockopen; created with socket_create, socket_bind, socket_listen, socket_accept. There's a note in the manual about this not working properly, but I didn't see it in the bug DB. Previous Comments: [2002-03-09 17:31:39] [EMAIL PROTECTED] socket_get_status is supposed to return an associative array, it _always_ returns null for me. No array, no object, no string print_r(socket_get_status($verifiedSocketResource)) prints nothing. I've tried this on two separate 4.1.x installs. The php4win version (4.1.1) and the Debian Unstable version (4.1.2 -- CGI). -- Edit this bug report at http://bugs.php.net/?id=15976&edit=1
Bug #15976: socket_get_status(...) returns nothing
From: [EMAIL PROTECTED] Operating system: Win32 (2000) AND Linux2.2 PHP version: 4.1.2 PHP Bug Type: Sockets related Bug description: socket_get_status(...) returns nothing socket_get_status is supposed to return an associative array, it _always_ returns null for me. No array, no object, no string print_r(socket_get_status($verifiedSocketResource)) prints nothing. I've tried this on two separate 4.1.x installs. The php4win version (4.1.1) and the Debian Unstable version (4.1.2 -- CGI). -- Edit bug report at http://bugs.php.net/?id=15976&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15976&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15976&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15976&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15976&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15976&r=support Expected behavior: http://bugs.php.net/fix.php?id=15976&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15976&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15976&r=submittedtwice
