#22937 [Com]: Valid http:// URL does not open with fopen()
ID: 22937
Comment by: dunkel at calamus dot net
Reported By: freddie at bingham dot net
Status: Open
Bug Type: Sockets related
Operating System: Redhat 7.3
PHP Version: 4.3.2
New Comment:
In my problem case, the remote file does NOT exist. This is what I want
to find out with fopen(). The according code looks like this:
// don't check remote files with file_exists() !!!
if ($lan == cz)
{
$file = fopen($url_docu, rb);
if ($file)
{
echo blockquote\n;
echo a href=\$url_docu\ class=\h4\;
$this-echo_name($lan);
echo (HTML)/a\n;
echo /blockquote\n;
fclose($file);
}
else
[...]
}
In fact, $file is invalid here as it should. But in no case this
function call of fopen() should give a warning about this, shouldn't
it?
In http://www.calamus.net/cz/modules/aln.php, you see how it works with
existing remote files.
In http://www.calamus.net/us/modules/aln.php, you can see how the
result should be (refer to 'Manual' instead of the Czech 'Prirucka').
Previous Comments:
[2003-06-08 20:15:31] freddie at bingham dot net
It very well does exist. Perhaps you just clicked on the url as
presented on this page which adds a ', to the end.
[2003-06-08 19:33:23] [EMAIL PROTECTED]
Why shouldn't it give that error? The first url in your
script does not exist.
[2003-06-08 11:18:35] dunkel at calamus dot net
For me, a similar problem exists in PHP 4.1.2 (on Apache):
Take a look at http://www.calamus.net/cz/modules/wmf.php, please.
In the paragraph P#345;íru#269;ka: (Documentation:) I want to
fopen() a page on a Czech server. As this page does not exist, a
visible warning is been returned which should probably NOT occur here.
Instead, I expect the function call to ONLY give back an invalid $fp.
[2003-06-07 12:06:48] freddie at bingham dot net
This is still happening in the 4.3.2 release
This is the result of the above script:
Warning: fopen(http://pub133.ezboard.com/bonesixthwarriors): failed to
open stream: HTTP request failed! k in test.php on line 3
[2003-04-07 12:16:53] psvanvicat at yahoodot dot com
I have a similar problem, but my virtual host has upgraded to 4.3.1 and
I can't convince them to go back to a stable snapshot...anything I can
do in my scripts to fix this? Any updates they can do?
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/22937
--
Edit this bug report at http://bugs.php.net/?id=22937edit=1
#21909 [Ver-Csd]: storing lambda functions into object properties
ID: 21909
Updated by: [EMAIL PROTECTED]
Reported By: ulf dot wendel at phpdoc dot de
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Windows XP Professional
PHP Version: 5CVS-2003-01-27 (dev)
New Comment:
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.
Previous Comments:
[2003-03-10 06:42:07] [EMAIL PROTECTED]
Verified on WinXP with latest snap.
~ Andrew Heebner
[2003-01-27 13:09:14] ulf dot wendel at phpdoc dot de
Try this, it simply let's my PHP crash:
class foo {
public $newfunc;
public function __construct() {
$this-newfunc = create_function('$a,$b','print ln($a) + ln($b) =
.log($a * $b);');
call_user_func(array($this, $this-newfunc), 1, 2);
//$this-$newfunc(1, 2);
}
}
$f = new foo();
Ok, ok - this is really, well, weird code, however...
PHP:
PHP Version 5.0.0-dev
System Windows NT localhost 5.1 build 2600
Build Date Jan 26 2003 16:10:39
Server API CGI/FastCGI
Virtual Directory Support enabled
Configuration File (php.ini) Path E:\php\php.ini
PHP API 20020918
PHP Extension 20020429
Zend Extension 90021012
Debug Build no
Thread Safety enabled
Registered PHP Streams php, http, ftp, compress.zlib
Zend Engine v2.0.0-dev,
--
Edit this bug report at http://bugs.php.net/?id=21909edit=1
#24087 [Opn-Fbk]: Make temporary_directory available in userland
ID: 24087 Updated by: [EMAIL PROTECTED] Reported By: philip at cornado dot com -Status: Open +Status: Feedback Bug Type: Feature/Change Request Operating System: all PHP Version: 5CVS-2003-06-08 (dev) New Comment: I don't really see the use of this. Why would this be useful? Previous Comments: [2003-06-08 22:33:05] philip at cornado dot com How about making the result from get_temporary_directory() available in user land, most likely as a constant named TEMPORARY_DIRECTORY This would be useful in that we'd know where this is, in both Windows and *nix. The code that defines the internal variable temporary_directory is here: http://lxr.php.net/source/php4/main/php_open_temporary_file.c#164 I'm not a devel guy, but the following hack seems mildly appropriate: REGISTER_STRING_CONSTANT(TEMPORARY_DIRECTORY, get_temporary_directory(), strlen(get_temporary_directory()), 0); Not sure where to put it though, or if it's fully correct (doubtful), but please consider this idea as it would be nice. One *possible* concern is security but I think it's worth it, *maybe* disable this option in safe_mode. It's not like the TEMP directory is a big secret, nor is viewing various related directives like session.save_path and upload_tmp_dir. -- Edit this bug report at http://bugs.php.net/?id=24087edit=1
#24088 [Opn-Bgs]: gb2312 charset can't display
ID: 24088 Updated by: [EMAIL PROTECTED] Reported By: sanry at now dot net dot cn -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: redhat8.0 PHP Version: 4.3.2 New Comment: Most likely an Apache problem, please report it to them. Previous Comments: [2003-06-08 23:20:19] sanry at now dot net dot cn php4.3.2 and apache2 gb2312 charset can't display you must set in php.ini default charset=gb2312 or the page can't display ok . apache1.3.x doesn't have this problem -- Edit this bug report at http://bugs.php.net/?id=24088edit=1
#22937 [Opn-Fbk]: Valid http:// URL does not open with fopen()
ID: 22937
Updated by: [EMAIL PROTECTED]
Reported By: freddie at bingham dot net
-Status: Open
+Status: Feedback
Bug Type: Sockets related
Operating System: Redhat 7.3
PHP Version: 4.3.2
New Comment:
dunkel at calamus dot net:
fopen will raise a warning if it could not open the file. That is how
it works. To hide the warning, use the @ operator.
freddie at bingham dot net:
please try this little script:
$p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
and paste the result here
Previous Comments:
[2003-06-09 01:29:22] dunkel at calamus dot net
In my problem case, the remote file does NOT exist. This is what I want
to find out with fopen(). The according code looks like this:
// don't check remote files with file_exists() !!!
if ($lan == cz)
{
$file = fopen($url_docu, rb);
if ($file)
{
echo blockquote\n;
echo a href=\$url_docu\ class=\h4\;
$this-echo_name($lan);
echo (HTML)/a\n;
echo /blockquote\n;
fclose($file);
}
else
[...]
}
In fact, $file is invalid here as it should. But in no case this
function call of fopen() should give a warning about this, shouldn't
it?
In http://www.calamus.net/cz/modules/aln.php, you see how it works with
existing remote files.
In http://www.calamus.net/us/modules/aln.php, you can see how the
result should be (refer to 'Manual' instead of the Czech 'Prirucka').
[2003-06-08 20:15:31] freddie at bingham dot net
It very well does exist. Perhaps you just clicked on the url as
presented on this page which adds a ', to the end.
[2003-06-08 19:33:23] [EMAIL PROTECTED]
Why shouldn't it give that error? The first url in your
script does not exist.
[2003-06-08 11:18:35] dunkel at calamus dot net
For me, a similar problem exists in PHP 4.1.2 (on Apache):
Take a look at http://www.calamus.net/cz/modules/wmf.php, please.
In the paragraph P#345;íru#269;ka: (Documentation:) I want to
fopen() a page on a Czech server. As this page does not exist, a
visible warning is been returned which should probably NOT occur here.
Instead, I expect the function call to ONLY give back an invalid $fp.
[2003-06-07 12:06:48] freddie at bingham dot net
This is still happening in the 4.3.2 release
This is the result of the above script:
Warning: fopen(http://pub133.ezboard.com/bonesixthwarriors): failed to
open stream: HTTP request failed! k in test.php on line 3
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/22937
--
Edit this bug report at http://bugs.php.net/?id=22937edit=1
#24075 [Opn]: PHP 4.3.2 does not find extensions in a folder with spec ..\php\extensions
ID: 24075 User updated by: Sven dot Schnitzke at t-online dot de Reported By: Sven dot Schnitzke at t-online dot de Status: Open Bug Type: Dynamic loading Operating System: WIN98SE PHP Version: 4.3.2 New Comment: (IMHO the reason for this trouble is that relative extension dir spec is based upon cwd whereas it should be based upon the folder php resides in). Sorry, the problem was in go-pear.php. It tries to invoke php.exe -v to learn something of the returned string. With my inst the cli version of php is supposed to be invoked via PIF and cannot be launched directly via exec. It was this 'inner' call that issued the complaints about the missing dlls. Obviously with absolute path spec this call finds the extensions and everything is fine. Still don't know why e.g. a PHP4.4-dev (feb03 approx) works with relative specs? Previous Comments: [2003-06-07 11:25:04] Sven dot Schnitzke at t-online dot de Yes, I am 100% sure. Meanwhile I verified that an absolute path spec does work. It is _really_ strange: curiously I tried go_pear.php and I encounter the named problem. When executing other scripts this is not the case. There is another strange thing about go_pear.php: it thinks I am using cgi while I am using php4apache. I tried go_pear with a PHP 4.4-dev and it worked (with some minor gliches) !?!? I will investigate further. It seems it could be a pear issue. [2003-06-07 04:50:23] [EMAIL PROTECTED] Are you 100% sure you have really updated PHP and that you don't have duplicate php4ts.dll's in your system? And that the one you have is for PHP 4.3.2? And FYI: earlier extensions might not work with current php. [2003-06-07 03:49:11] Sven dot Schnitzke at t-online dot de I just downloaded PHP-4.3.2 final and wanted to install it. (extension dir is specified as ..\php\extensions) I have parallel folders with some versions of PHP4 from 4.0.6 thru 4.3.2-RC and some snapshot 4.4-dev which I arranged to have at hand by just copying PHP.INI to the Apache folder and renaming the PHP folder to be the one supposed to hold the active PHP. No parts of PHP outside these folders except some two PIFS used to start PHP from the command line. This works because the Apache folder and the active PHP folder are parallel in the same tree. All versions I have work well this way including an earlier 4.3.2-RC. Now 4.3.2 final does not! IMHO copying the extensions to the WINSYS folder is not a viable way because a) it clutters WINSYS b) you are unable to quickly go forth (and back in case of trouble) with upgrading PHP Maybe absolute path works but I don't think it is a good idea to have a lot of places where absolute path specs are required. -- Edit this bug report at http://bugs.php.net/?id=24075edit=1
#16325 [NoF-Opn]: Memory leak causes DLLHOST to become large
ID: 16325 User updated by: mail-php dot net at kimihia dot org dot nz Reported By: mail-php dot net at kimihia dot org dot nz -Status: No Feedback +Status: Open Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.3.2RC1 New Comment: I still watch this bug ocassionally, but as I no longer have access to the Windows 2000 Server it is little use. When I left, and when I stepped someone else through it recently when they upgraded, there were using ISAPI for a page that needed to set cookies. Due to the memory problems (which only appear when multiple PHP processes are running) it is not used throughout the entire site. Previous Comments: [2003-06-07 06:32:04] nicolai at petri dot cc Same shit still... Why not fix the bug instead of closing this pr constantly ? IIS + PHP + ISAPI is a no-go for all my testcases.. Is anybody actually using this successfully ? [2003-05-30 08:43:20] [EMAIL PROTECTED] No feedback from the ORIGINAL bug submitter. [2003-05-29 15:03:27] [EMAIL PROTECTED] reopen, there has been feedback. [2003-05-29 14:52:26] fer at onplaza dot com Same as others, normally HOSTDLL.EXE grows between 1-2 Mb per request. I've stopped all the rest of services, created a phpinfo.php whith only the named function and a phpinfo.htm; both in the same directory, and if only happens when calling the .php extension page. That's why I think that in this case we are not in front of an IIS problem. Looks like a big leak of memory that in some cases php is unable to handle This is my 6'th year using PHP. Fer [2003-04-21 07:25:24] nicolai at petri dot cc This happens also for me with both php 4.3.1 and 4.3.2 RC1. It also happens even if I don´t load any extensions, so the leak seems to be in the core php stuff. I tested with my own pages and phpinfo() pages. Each hit generates 2-3 Mb. of mem. leak. Another (maybe related) observation i did, was that when I run with mssql extension and use pconnect calls.. phpinfo() always shows 0 connections and 0 persistent connections. So maybe php cannot locate it's runtime datastructures and re-allocates them on each hit ? I cannot compile php from sources. But if anyone can point me to a debug build I can try that with memleak detection on. Best regards, Nicolai Petri 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/16325 -- Edit this bug report at http://bugs.php.net/?id=16325edit=1
#16325 [Opn-Ver]: Memory leak causes DLLHOST to become large
ID: 16325 Updated by: [EMAIL PROTECTED] Reported By: mail-php dot net at kimihia dot org dot nz -Status: Open +Status: Verified Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.3.2RC1 New Comment: Sorry for the spam. Who are code writers for IIS related stuff? I'm supposed to be the guy who examines all these IIS related bugs, but I've never had to modify the code. Previous Comments: [2003-06-09 03:45:08] mail-php dot net at kimihia dot org dot nz I still watch this bug ocassionally, but as I no longer have access to the Windows 2000 Server it is little use. When I left, and when I stepped someone else through it recently when they upgraded, there were using ISAPI for a page that needed to set cookies. Due to the memory problems (which only appear when multiple PHP processes are running) it is not used throughout the entire site. [2003-06-07 06:32:04] nicolai at petri dot cc Same shit still... Why not fix the bug instead of closing this pr constantly ? IIS + PHP + ISAPI is a no-go for all my testcases.. Is anybody actually using this successfully ? [2003-05-30 08:43:20] [EMAIL PROTECTED] No feedback from the ORIGINAL bug submitter. [2003-05-29 15:03:27] [EMAIL PROTECTED] reopen, there has been feedback. [2003-05-29 14:52:26] fer at onplaza dot com Same as others, normally HOSTDLL.EXE grows between 1-2 Mb per request. I've stopped all the rest of services, created a phpinfo.php whith only the named function and a phpinfo.htm; both in the same directory, and if only happens when calling the .php extension page. That's why I think that in this case we are not in front of an IIS problem. Looks like a big leak of memory that in some cases php is unable to handle This is my 6'th year using PHP. Fer 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/16325 -- Edit this bug report at http://bugs.php.net/?id=16325edit=1
#24063 [Bgs-Opn]: Notice: unserialize(): Error at offset ...
ID: 24063
User updated by: jparneodo at yahoo dot fr
Reported By: jparneodo at yahoo dot fr
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
Operating System: RH7.3
PHP Version: 4.3.2
New Comment:
Serialise on 4.3.2 and 4.3.0 has not the same result:
4.3.2= d:1E-06;
4.3.0= d::.E-7;
?php
echo phpversion();
$f=1.0e-6;
$s=serialize($f);
$ff=unserialize($s);
echo \n\n$s;
?
// Output with php-4.3.2/sapi/cli/php
4.3.2
Notice: unserialize(): Error at offset 0 of 8 bytes in - on line 5
d::.E-7;
// Output with php-4.3.0 apache 1.3.27 on RedHat
4.3.0
d:1E-06;
// Same result on RH9.0 with all php-4.3.2RCi
http://marc.theaimsgroup.com/?l=php-devm=105491350013813w=2
Previous Comments:
[2003-06-06 14:36:44] [EMAIL PROTECTED]
Withing RH 6.2 the original object is identical to the
one after serialize/unserialize. No bug here.
[2003-06-06 11:08:04] jparneodo at yahoo dot fr
class C {
var $bad_1 = 1e-6; // Bug in unserialize
var $bad_2 = 1.0e-6;// Bug in unserialize
var $ok__1 = 1.1e-6;
var $ok__2 = 9e-7;
}
$c=new C();
$s=serialize($c);
$cc=unserialize($s);
/*
Values like 0.1 (one)
seems to be fatal!
*/
--
Edit this bug report at http://bugs.php.net/?id=24063edit=1
#24010 [Opn]: Make failure
ID: 24010 User updated by: ronald_zeelenberg at hotmail dot com Reported By: ronald_zeelenberg at hotmail dot com Status: Open Bug Type: Compile Failure Operating System: Red Hat 8 PHP Version: 5CVS-2003-06-04 (dev) New Comment: Okay since two day i can make a correct version of the daily based PHP5 version. Accept some php-pages with DB-actions and PEAR based are crashing... Apache2 says killed the child etc. Daily based 4.3x does not have this problem. Is something changed in PHP5 which ic causing this? I did not change my code... Previous Comments: [2003-06-08 22:13:36] chrisgio at virtualscape dot net This is what I'm seeing: $ make install-pear-installer [PEAR] Archive_Tar- already installed: 0.9 [PEAR] Console_Getopt - already installed: 1.0 [PEAR] PEAR - already installed: 1.1 make: *** [install-pear-installer] Segmentation fault (core dumped) $gdb sapi/cli/php core -snip- Core was generated by `/usr/local/testbed/build/php5/sapi/cli/php -n -dsafe_mode 0 /usr/local/testbed/'. Program terminated with signal 11, Segmentation fault. -snip- #0 0x081b85b6 in _efree (ptr=0x8319990) at /usr/local/testbed/build/php5/Zend/zend_alloc.c:276 276 REMOVE_POINTER_FROM_LIST(p); (gdb) bt #0 0x081b85b6 in _efree (ptr=0x8319990) at /usr/local/testbed/build/php5/Zend/zend_alloc.c:276 #1 0x0818c72b in php_xml_free_wrapper (ptr=0x8319990) at /usr/local/testbed/build/php5/ext/xml/xml.c:185 #2 0x4033257c in xmlHashFree () from /usr/lib/libxml2.so.2 #3 0x4028c140 in xsltUnregisterExtModule () from /usr/lib/libxslt.so.1 #4 0x4028cbeb in xsltCleanupGlobals () from /usr/lib/libxslt.so.1 #5 0x0809fada in zm_shutdown_domxml (type=1, module_number=20, tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/ext/domxml/php_domxml.c:1569 #6 0x081cdb3c in module_destructor (module=0x831dd48) at /usr/local/testbed/build/php5/Zend/zend_API.c:1276 #7 0x081cfa78 in zend_hash_apply_deleter (ht=0x8294c00, p=0x831dd18) at /usr/local/testbed/build/php5/Zend/zend_hash.c:565 #8 0x081cfb06 in zend_hash_graceful_reverse_destroy (ht=0x8294c00) at /usr/local/testbed/build/php5/Zend/zend_hash.c:631 #9 0x081ca573 in zend_shutdown (tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/Zend/zend.c:684 #10 0x08199f81 in php_module_shutdown (tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/main/main.c:1457 #11 0x081e69c7 in main (argc=7, argv=0xbaf4) at /usr/local/testbed/build/php5/sapi/cli/php_cli.c:1020 Machine: Debain based 2.4.20 kernel on x86 GCC 3.2.3 bison 1.875a flex 2.5.4 apache 2.0.46 libxslt 1.0.30 libxml2 2.5.6 php 5.0.0-dev 20030608 with options: './configure' '--prefix=/usr/local/testbed/php5' '--with-openssl' '--with-apxs2=/usr/local/testbed/apache2/bin/apxs' '--with-config-file-path=/usr/local/testbed/php5/lib' '--enable-bcmath' '--enable-calendar' '--with-curl=/usr/local/testbed' '--with-curl-wrappers' '--enable-dba' '--with-gdbm' '--with-flatfile' '--enable-dio' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--with-dom5' '--enable-exif' '--enable-ftp' '--with-gd' '--with-imap-ssl' '--with-ldap' '--enable-mbstring' '--with-pgsql=/usr/local/testbed/pgsql' '--with-libedit' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-pic' '--with-zlib' [2003-06-04 04:12:24] ronald_zeelenberg at hotmail dot com Tried to compile since 1 week ago like i always do, install the latest PHP5dev. Still i haven't been able to make a succesfull compile.. Here is the latest part of the compile. The latest PHP43-dev doesn't have this failure. Anyone??? Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Installing PHP CLI binary:/var/www/php-dev/bin/ Installing PHP CLI man page: /var/www/php-dev/man/man1/ Installing PHP SAPI module /var/www/apache2//build/instdso.sh SH_LIBTOOL='/var/www/apache2//build/libtool' libphp5.la /var/www/apache2//modules /var/www/apache2//build/libtool --mode=install cp libphp5.la /var/www/apache2//modules/ cp .libs/libphp5.so /var/www/apache2//modules/libphp5.so cp .libs/libphp5.lai /var/www/apache2//modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /usr/src/php/php5-200306040730/libs' chmod 755 /var/www/apache2//modules/libphp5.so [activating module `php5' in /var/www/config//httpd.conf] Installing shared extensions: /var/www/php-dev/lib/php/extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /var/www/php-dev/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 -- Edit this bug report at http://bugs.php.net/?id=24010edit=1
#24089 [NEW]: Problem creating objects with names from class' fields
From: bartosz at webcity dot pl
Operating system: Linux
PHP version: 5CVS-2003-06-09 (dev)
PHP Bug Type: *General Issues
Bug description: Problem creating objects with names from class' fields
Analyse code below, it makes parse error:
?php
class foobar2
{
function foobar2()
{
echo phpversion();
}
}
class foobar
{
var $classname = 'foobar2';
var $obj;
function foobar()
{
// it works:
//
// $classname = $this - classname;
// $this - obj = new $classname;
//
// but it doesn't work:
$this - obj = new $this - classname;
}
}
$obj = new foobar;
?
My configure command:
'./configure' '--with-mysql=/usr' '--with-gd2' '--disable-xml'
'--with-apxs=/usr/sbin/apxs'
--
Edit bug report at http://bugs.php.net/?id=24089edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24089r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24089r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24089r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24089r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24089r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24089r=support
Expected behavior: http://bugs.php.net/fix.php?id=24089r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24089r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24089r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24089r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24089r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24089r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24089r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24089r=gnused
#24010 [Opn]: Make failure
ID: 24010 User updated by: ronald_zeelenberg at hotmail dot com Reported By: ronald_zeelenberg at hotmail dot com Status: Open Bug Type: Compile Failure Operating System: Red Hat 8 PHP Version: 5CVS-2003-06-04 (dev) New Comment: After setting LogLevel to debug in httpd.conf i found this extra info. [Mon Jun 09 06:12:27 2003] [notice] Apache/2.0.46 (Unix) DAV/2 PHP/5.0.0-dev configured -- resuming normal operations [Mon Jun 09 10:55:58 2003] [notice] child pid 21213 exit signal Segmentation fault (11) [Mon Jun 09 10:55:58 2003] [notice] child pid 21168 exit signal Segmentation fault (11) [Mon Jun 09 10:55:58 2003] [notice] child pid 21167 exit signal Segmentation fault (11) [Mon Jun 09 11:11:25 2003] [notice] caught SIGTERM, shutting down [Mon Jun 09 11:11:25 2003] [notice] Apache/2.0.46 (Unix) DAV/2 PHP/5.0.0-dev configured -- resuming normal oper ations [Mon Jun 09 11:11:25 2003] [info] Server built: Jun 1 2003 13:15:30 [Mon Jun 09 11:11:25 2003] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem) [Mon Jun 09 11:12:13 2003] [notice] child pid 21487 exit signal Segmentation fault (11) [Mon Jun 09 11:12:13 2003] [notice] child pid 21486 exit signal Segmentation fault (11) [Mon Jun 09 11:12:13 2003] [notice] child pid 21485 exit signal Segmentation fault (11) Previous Comments: [2003-06-09 03:55:03] ronald_zeelenberg at hotmail dot com Okay since two day i can make a correct version of the daily based PHP5 version. Accept some php-pages with DB-actions and PEAR based are crashing... Apache2 says killed the child etc. Daily based 4.3x does not have this problem. Is something changed in PHP5 which ic causing this? I did not change my code... [2003-06-08 22:13:36] chrisgio at virtualscape dot net This is what I'm seeing: $ make install-pear-installer [PEAR] Archive_Tar- already installed: 0.9 [PEAR] Console_Getopt - already installed: 1.0 [PEAR] PEAR - already installed: 1.1 make: *** [install-pear-installer] Segmentation fault (core dumped) $gdb sapi/cli/php core -snip- Core was generated by `/usr/local/testbed/build/php5/sapi/cli/php -n -dsafe_mode 0 /usr/local/testbed/'. Program terminated with signal 11, Segmentation fault. -snip- #0 0x081b85b6 in _efree (ptr=0x8319990) at /usr/local/testbed/build/php5/Zend/zend_alloc.c:276 276 REMOVE_POINTER_FROM_LIST(p); (gdb) bt #0 0x081b85b6 in _efree (ptr=0x8319990) at /usr/local/testbed/build/php5/Zend/zend_alloc.c:276 #1 0x0818c72b in php_xml_free_wrapper (ptr=0x8319990) at /usr/local/testbed/build/php5/ext/xml/xml.c:185 #2 0x4033257c in xmlHashFree () from /usr/lib/libxml2.so.2 #3 0x4028c140 in xsltUnregisterExtModule () from /usr/lib/libxslt.so.1 #4 0x4028cbeb in xsltCleanupGlobals () from /usr/lib/libxslt.so.1 #5 0x0809fada in zm_shutdown_domxml (type=1, module_number=20, tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/ext/domxml/php_domxml.c:1569 #6 0x081cdb3c in module_destructor (module=0x831dd48) at /usr/local/testbed/build/php5/Zend/zend_API.c:1276 #7 0x081cfa78 in zend_hash_apply_deleter (ht=0x8294c00, p=0x831dd18) at /usr/local/testbed/build/php5/Zend/zend_hash.c:565 #8 0x081cfb06 in zend_hash_graceful_reverse_destroy (ht=0x8294c00) at /usr/local/testbed/build/php5/Zend/zend_hash.c:631 #9 0x081ca573 in zend_shutdown (tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/Zend/zend.c:684 #10 0x08199f81 in php_module_shutdown (tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/main/main.c:1457 #11 0x081e69c7 in main (argc=7, argv=0xbaf4) at /usr/local/testbed/build/php5/sapi/cli/php_cli.c:1020 Machine: Debain based 2.4.20 kernel on x86 GCC 3.2.3 bison 1.875a flex 2.5.4 apache 2.0.46 libxslt 1.0.30 libxml2 2.5.6 php 5.0.0-dev 20030608 with options: './configure' '--prefix=/usr/local/testbed/php5' '--with-openssl' '--with-apxs2=/usr/local/testbed/apache2/bin/apxs' '--with-config-file-path=/usr/local/testbed/php5/lib' '--enable-bcmath' '--enable-calendar' '--with-curl=/usr/local/testbed' '--with-curl-wrappers' '--enable-dba' '--with-gdbm' '--with-flatfile' '--enable-dio' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--with-dom5' '--enable-exif' '--enable-ftp' '--with-gd' '--with-imap-ssl' '--with-ldap' '--enable-mbstring' '--with-pgsql=/usr/local/testbed/pgsql' '--with-libedit' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-pic' '--with-zlib' [2003-06-04 04:12:24] ronald_zeelenberg at hotmail dot com Tried to compile since 1 week ago like i always do, install the latest PHP5dev. Still i haven't been able to make a succesfull compile.. Here is the latest part of the compile. The latest PHP43-dev doesn't have this failure. Anyone??? Build complete. (It is safe to ignore
#24089 [Opn-Fbk]: Problem creating objects with names from class' fields
ID: 24089
Updated by: [EMAIL PROTECTED]
Reported By: bartosz at webcity dot pl
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5CVS-2003-06-09 (dev)
New Comment:
Where is the bug?
Previous Comments:
[2003-06-09 04:09:37] bartosz at webcity dot pl
Analyse code below, it makes parse error:
?php
class foobar2
{
function foobar2()
{
echo phpversion();
}
}
class foobar
{
var $classname = 'foobar2';
var $obj;
function foobar()
{
// it works:
//
// $classname = $this - classname;
// $this - obj = new $classname;
//
// but it doesn't work:
$this - obj = new $this - classname;
}
}
$obj = new foobar;
?
My configure command:
'./configure' '--with-mysql=/usr' '--with-gd2' '--disable-xml'
'--with-apxs=/usr/sbin/apxs'
--
Edit this bug report at http://bugs.php.net/?id=24089edit=1
#24089 [Fbk-Opn]: Problem creating objects with names from class' fields
ID: 24089
User updated by: bartosz at webcity dot pl
Reported By: bartosz at webcity dot pl
-Status: Feedback
+Status: Open
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5CVS-2003-06-09 (dev)
New Comment:
Look at 'foobar' method in 'foobar' class.
It makes parse error:
$this - obj = new $this - classname;
but it works:
$classname = $this - classname;
$this - obj = new $classname;
in php4
$this - obj = new $this - classname;
works correctly.
It isn't a bug?
Previous Comments:
[2003-06-09 04:18:28] [EMAIL PROTECTED]
Where is the bug?
[2003-06-09 04:09:37] bartosz at webcity dot pl
Analyse code below, it makes parse error:
?php
class foobar2
{
function foobar2()
{
echo phpversion();
}
}
class foobar
{
var $classname = 'foobar2';
var $obj;
function foobar()
{
// it works:
//
// $classname = $this - classname;
// $this - obj = new $classname;
//
// but it doesn't work:
$this - obj = new $this - classname;
}
}
$obj = new foobar;
?
My configure command:
'./configure' '--with-mysql=/usr' '--with-gd2' '--disable-xml'
'--with-apxs=/usr/sbin/apxs'
--
Edit this bug report at http://bugs.php.net/?id=24089edit=1
#24091 [NEW]: CLI Segfault
From: devon at sitetronics dot com Operating system: RHL 7.3/kern 2.4.21-rc6 PHP version: 4.3.1 PHP Bug Type: Scripting Engine problem Bug description: CLI Segfault Goofing around with shell scripting in PHP, I bumped into this problem. I scanned the other segfault bugs, but I didn't find one like this. Additionally, I haven't tried with any nightlies, so sorry, but here we go. When running a script with the CLI binary as so: # php -q somescript.php I receive a segfault. This should work as PHP should parse stuff from stdin, and this is just a pipe. Copying the script to stdin when calling PHP as #php -q I'm able to run the script successfully. Additionally, I can run the script by doing # php -q somescript.php I'm positive that this is because I have PHP reading its pipe from stdin and then requesting user input from stdin as well. But PHP should die gracefully and not segfault. Oh yeah, here's the really strange backtrace #0 0x081299f8 in zend_parse_arg (arg_num=1, arg=0x402c039c, va=0xbf800834, spec=0xbf800824, quiet=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:436 #1 0x08129df8 in zend_parse_va_args (num_args=2, type_spec=0x81568b6 ss|br, va=0xbf800834, flags=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:527 #2 0x08129e5b in zend_parse_parameters (num_args=2, type_spec=0x81568b6 ss|br) at /root/build/php/php-4.3.1/Zend/zend_API.c:554 #3 0x080a9c8e in php_if_fopen (ht=2, return_value=0x81d5884, this_ptr=0x0, return_value_used=1) at /root/build/php/php-4.3.1/ext/standard/file.c:1086 #4 0x4027f922 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #5 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #6 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #7 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #8 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #9 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #10 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #11 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #12 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #13 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #14 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #15 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #16 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #17 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so ... #11382 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #11383 0x08102869 in php_execute_script (primary_file=0xbac0) at /root/build/php/php-4.3.1/main/main.c:1573 #11384 0x08143610 in main (argc=2, argv=0xbb64) at /root/build/php/php-4.3.1/sapi/cli/php_cli.c:746 #11385 0x401331c4 in __libc_start_main () from /lib/libc.so.6 Aha! But before you say idiot, go email Nick, here's the backtrace with the loader turned off :P. It just proves that Nick's gotta fix his stuff also. #0 0x081299f8 in zend_parse_arg (arg_num=1, arg=0x824be44, va=0xbf800754, spec=0xbf800744, quiet=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:436 #1 0x08129df8 in zend_parse_va_args (num_args=2, type_spec=0x81568b6 ss|br, va=0xbf800754, flags=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:527 #2 0x08129e5b in zend_parse_parameters (num_args=2, type_spec=0x81568b6 ss|br) at /root/build/php/php-4.3.1/Zend/zend_API.c:554 #3 0x080a9c8e in php_if_fopen (ht=2, return_value=0x81d47c4, this_ptr=0x0, return_value_used=1) at /root/build/php/php-4.3.1/ext/standard/file.c:1086 #4 0x0813b09c in execute (op_array=0x81cffd0) at /root/build/php/php-4.3.1/Zend/zend_execute.c:1596 #5 0x0813b25a in execute (op_array=0x81d3e80) at /root/build/php/php-4.3.1/Zend/zend_execute.c:1640 #6 0x0813b25a in execute (op_array=0x81d3e80) at /root/build/php/php-4.3.1/Zend/zend_execute.c:1640 . #3908 0x0813b25a in execute (op_array=0x81d2d98) at /root/build/php/php-4.3.1/Zend/zend_execute.c:1640 #3909 0x0813b25a in execute (op_array=0x81cab7c) at /root/build/php/php-4.3.1/Zend/zend_execute.c:1640 #3910 0x08128cac in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/build/php/php-4.3.1/Zend/zend.c:864 #3911 0x08102869 in php_execute_script (primary_file=0xbac0) at /root/build/php/php-4.3.1/main/main.c:1573 #3912 0x08143610 in main (argc=2, argv=0xbb64) at /root/build/php/php-4.3.1/sapi/cli/php_cli.c:746 #3913 0x401331c4 in __libc_start_main () from /lib/libc.so.6 Ok, that's it. Devon -- Edit bug report at http://bugs.php.net/?id=24091edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24091r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24091r=fixedcvs
#24091 [Opn-Bgs]: CLI Segfault
ID: 24091 Updated by: [EMAIL PROTECTED] Reported By: devon at sitetronics dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: RHL 7.3/kern 2.4.21-rc6 PHP Version: 4.3.1 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. And disable any accelerator, caching and encoding products. Previous Comments: [2003-06-09 04:33:23] devon at sitetronics dot com Goofing around with shell scripting in PHP, I bumped into this problem. I scanned the other segfault bugs, but I didn't find one like this. Additionally, I haven't tried with any nightlies, so sorry, but here we go. When running a script with the CLI binary as so: # php -q somescript.php I receive a segfault. This should work as PHP should parse stuff from stdin, and this is just a pipe. Copying the script to stdin when calling PHP as #php -q I'm able to run the script successfully. Additionally, I can run the script by doing # php -q somescript.php I'm positive that this is because I have PHP reading its pipe from stdin and then requesting user input from stdin as well. But PHP should die gracefully and not segfault. Oh yeah, here's the really strange backtrace #0 0x081299f8 in zend_parse_arg (arg_num=1, arg=0x402c039c, va=0xbf800834, spec=0xbf800824, quiet=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:436 #1 0x08129df8 in zend_parse_va_args (num_args=2, type_spec=0x81568b6 ss|br, va=0xbf800834, flags=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:527 #2 0x08129e5b in zend_parse_parameters (num_args=2, type_spec=0x81568b6 ss|br) at /root/build/php/php-4.3.1/Zend/zend_API.c:554 #3 0x080a9c8e in php_if_fopen (ht=2, return_value=0x81d5884, this_ptr=0x0, return_value_used=1) at /root/build/php/php-4.3.1/ext/standard/file.c:1086 #4 0x4027f922 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #5 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #6 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #7 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #8 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #9 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #10 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #11 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #12 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #13 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #14 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #15 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #16 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #17 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so ... #11382 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #11383 0x08102869 in php_execute_script (primary_file=0xbac0) at /root/build/php/php-4.3.1/main/main.c:1573 #11384 0x08143610 in main (argc=2, argv=0xbb64) at /root/build/php/php-4.3.1/sapi/cli/php_cli.c:746 #11385 0x401331c4 in __libc_start_main () from /lib/libc.so.6 Aha! But before you say idiot, go email Nick, here's the backtrace with the loader turned off :P. It just proves that Nick's gotta fix his stuff also. #0 0x081299f8 in zend_parse_arg (arg_num=1, arg=0x824be44, va=0xbf800754, spec=0xbf800744, quiet=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:436 #1 0x08129df8 in zend_parse_va_args (num_args=2, type_spec=0x81568b6 ss|br, va=0xbf800754, flags=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:527 #2 0x08129e5b in zend_parse_parameters (num_args=2, type_spec=0x81568b6 ss|br) at /root/build/php/php-4.3.1/Zend/zend_API.c:554 #3 0x080a9c8e in php_if_fopen (ht=2, return_value=0x81d47c4, this_ptr=0x0, return_value_used=1) at /root/build/php/php-4.3.1/ext/standard/file.c:1086 #4 0x0813b09c in execute (op_array=0x81cffd0) at /root/build/php/php-4.3.1/Zend/zend_execute.c:1596 #5 0x0813b25a in execute (op_array=0x81d3e80) at /root/build/php/php-4.3.1/Zend/zend_execute.c:1640 #6 0x0813b25a in execute (op_array=0x81d3e80) at /root/build/php/php-4.3.1/Zend/zend_execute.c:1640 . #3908 0x0813b25a in execute (op_array=0x81d2d98) at
#24091 [Bgs-Opn]: CLI Segfault
ID: 24091 User updated by: devon at sitetronics dot com Reported By: devon at sitetronics dot com -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: RHL 7.3/kern 2.4.21-rc6 -PHP Version: 4.3.1 +PHP Version: 4.3.2 New Comment: Same in 4.3.2 Previous Comments: [2003-06-09 04:35:11] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. And disable any accelerator, caching and encoding products. [2003-06-09 04:33:23] devon at sitetronics dot com Goofing around with shell scripting in PHP, I bumped into this problem. I scanned the other segfault bugs, but I didn't find one like this. Additionally, I haven't tried with any nightlies, so sorry, but here we go. When running a script with the CLI binary as so: # php -q somescript.php I receive a segfault. This should work as PHP should parse stuff from stdin, and this is just a pipe. Copying the script to stdin when calling PHP as #php -q I'm able to run the script successfully. Additionally, I can run the script by doing # php -q somescript.php I'm positive that this is because I have PHP reading its pipe from stdin and then requesting user input from stdin as well. But PHP should die gracefully and not segfault. Oh yeah, here's the really strange backtrace #0 0x081299f8 in zend_parse_arg (arg_num=1, arg=0x402c039c, va=0xbf800834, spec=0xbf800824, quiet=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:436 #1 0x08129df8 in zend_parse_va_args (num_args=2, type_spec=0x81568b6 ss|br, va=0xbf800834, flags=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:527 #2 0x08129e5b in zend_parse_parameters (num_args=2, type_spec=0x81568b6 ss|br) at /root/build/php/php-4.3.1/Zend/zend_API.c:554 #3 0x080a9c8e in php_if_fopen (ht=2, return_value=0x81d5884, this_ptr=0x0, return_value_used=1) at /root/build/php/php-4.3.1/ext/standard/file.c:1086 #4 0x4027f922 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #5 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #6 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #7 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #8 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #9 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #10 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #11 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #12 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #13 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #14 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #15 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #16 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #17 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so ... #11382 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #11383 0x08102869 in php_execute_script (primary_file=0xbac0) at /root/build/php/php-4.3.1/main/main.c:1573 #11384 0x08143610 in main (argc=2, argv=0xbb64) at /root/build/php/php-4.3.1/sapi/cli/php_cli.c:746 #11385 0x401331c4 in __libc_start_main () from /lib/libc.so.6 Aha! But before you say idiot, go email Nick, here's the backtrace with the loader turned off :P. It just proves that Nick's gotta fix his stuff also. #0 0x081299f8 in zend_parse_arg (arg_num=1, arg=0x824be44, va=0xbf800754, spec=0xbf800744, quiet=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:436 #1 0x08129df8 in zend_parse_va_args (num_args=2, type_spec=0x81568b6 ss|br, va=0xbf800754, flags=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:527 #2 0x08129e5b in zend_parse_parameters (num_args=2, type_spec=0x81568b6 ss|br) at /root/build/php/php-4.3.1/Zend/zend_API.c:554 #3 0x080a9c8e in php_if_fopen (ht=2, return_value=0x81d47c4, this_ptr=0x0, return_value_used=1) at /root/build/php/php-4.3.1/ext/standard/file.c:1086 #4 0x0813b09c in execute (op_array=0x81cffd0) at /root/build/php/php-4.3.1/Zend/zend_execute.c:1596 #5 0x0813b25a in execute (op_array=0x81d3e80) at /root/build/php/php-4.3.1/Zend/zend_execute.c:1640 #6 0x0813b25a in execute (op_array=0x81d3e80)
#24089 [Com]: Problem creating objects with names from class' fields
ID: 24089
Comment by: neon at neon-line dot net
Reported By: bartosz at webcity dot pl
Status: Open
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5CVS-2003-06-09 (dev)
New Comment:
It's not a bug.
Previous Comments:
[2003-06-09 04:28:43] bartosz at webcity dot pl
Look at 'foobar' method in 'foobar' class.
It makes parse error:
$this - obj = new $this - classname;
but it works:
$classname = $this - classname;
$this - obj = new $classname;
in php4
$this - obj = new $this - classname;
works correctly.
It isn't a bug?
[2003-06-09 04:18:28] [EMAIL PROTECTED]
Where is the bug?
[2003-06-09 04:09:37] bartosz at webcity dot pl
Analyse code below, it makes parse error:
?php
class foobar2
{
function foobar2()
{
echo phpversion();
}
}
class foobar
{
var $classname = 'foobar2';
var $obj;
function foobar()
{
// it works:
//
// $classname = $this - classname;
// $this - obj = new $classname;
//
// but it doesn't work:
$this - obj = new $this - classname;
}
}
$obj = new foobar;
?
My configure command:
'./configure' '--with-mysql=/usr' '--with-gd2' '--disable-xml'
'--with-apxs=/usr/sbin/apxs'
--
Edit this bug report at http://bugs.php.net/?id=24089edit=1
#24063 [Opn]: Notice: unserialize(): Error at offset ...
ID: 24063
Updated by: [EMAIL PROTECTED]
Reported By: jparneodo at yahoo dot fr
Status: Open
Bug Type: Scripting Engine problem
Operating System: RH7.3
PHP Version: 4.3.2
New Comment:
Please correct the version error in your last message.
Previous Comments:
[2003-06-09 03:50:30] jparneodo at yahoo dot fr
Serialise on 4.3.2 and 4.3.0 has not the same result:
4.3.2= d:1E-06;
4.3.0= d::.E-7;
?php
echo phpversion();
$f=1.0e-6;
$s=serialize($f);
$ff=unserialize($s);
echo \n\n$s;
?
// Output with php-4.3.2/sapi/cli/php
4.3.2
Notice: unserialize(): Error at offset 0 of 8 bytes in - on line 5
d::.E-7;
// Output with php-4.3.0 apache 1.3.27 on RedHat
4.3.0
d:1E-06;
// Same result on RH9.0 with all php-4.3.2RCi
http://marc.theaimsgroup.com/?l=php-devm=105491350013813w=2
[2003-06-06 14:36:44] [EMAIL PROTECTED]
Withing RH 6.2 the original object is identical to the
one after serialize/unserialize. No bug here.
[2003-06-06 11:08:04] jparneodo at yahoo dot fr
class C {
var $bad_1 = 1e-6; // Bug in unserialize
var $bad_2 = 1.0e-6;// Bug in unserialize
var $ok__1 = 1.1e-6;
var $ok__2 = 9e-7;
}
$c=new C();
$s=serialize($c);
$cc=unserialize($s);
/*
Values like 0.1 (one)
seems to be fatal!
*/
--
Edit this bug report at http://bugs.php.net/?id=24063edit=1
#24063 [Opn]: Notice: unserialize(): Error at offset ...
ID: 24063
User updated by: jparneodo at yahoo dot fr
Reported By: jparneodo at yahoo dot fr
Status: Open
Bug Type: Scripting Engine problem
Operating System: RH7.3
PHP Version: 4.3.2
New Comment:
Sorry, you must read,
Serialise on 4.3.2 and 4.3.0 has not the same result on RH7.2:
4.3.0= d:1E-06;
4.3.2= d::.E-7;
Previous Comments:
[2003-06-09 05:16:20] [EMAIL PROTECTED]
Please correct the version error in your last message.
[2003-06-09 03:50:30] jparneodo at yahoo dot fr
Serialise on 4.3.2 and 4.3.0 has not the same result:
4.3.2= d:1E-06;
4.3.0= d::.E-7;
?php
echo phpversion();
$f=1.0e-6;
$s=serialize($f);
$ff=unserialize($s);
echo \n\n$s;
?
// Output with php-4.3.2/sapi/cli/php
4.3.2
Notice: unserialize(): Error at offset 0 of 8 bytes in - on line 5
d::.E-7;
// Output with php-4.3.0 apache 1.3.27 on RedHat
4.3.0
d:1E-06;
// Same result on RH9.0 with all php-4.3.2RCi
http://marc.theaimsgroup.com/?l=php-devm=105491350013813w=2
[2003-06-06 14:36:44] [EMAIL PROTECTED]
Withing RH 6.2 the original object is identical to the
one after serialize/unserialize. No bug here.
[2003-06-06 11:08:04] jparneodo at yahoo dot fr
class C {
var $bad_1 = 1e-6; // Bug in unserialize
var $bad_2 = 1.0e-6;// Bug in unserialize
var $ok__1 = 1.1e-6;
var $ok__2 = 9e-7;
}
$c=new C();
$s=serialize($c);
$cc=unserialize($s);
/*
Values like 0.1 (one)
seems to be fatal!
*/
--
Edit this bug report at http://bugs.php.net/?id=24063edit=1
#18926 [Ver-Csd]: cannot call self::method() or parent::method() via call_user_func_array()
ID: 18926 Updated by: [EMAIL PROTECTED] -Reported By: tater at potatoe dot com +Reported By: carl at thep dot lu dot se -Status: Verified +Status: Closed Bug Type: Zend Engine 2 problem -Operating System: All +Operating System: Linux PHP Version: 5.0.0-dev New Comment: 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. Previous Comments: [2003-02-09 09:57:01] [EMAIL PROTECTED] Related to bug #21849 [2002-10-29 19:16:16] tater at potatoe dot com Wrong summary, cut paste error. [2002-10-28 15:48:42] tater at potatoe dot com Still doesn't work on ZE2. [2002-10-28 15:46:45] tater at potatoe dot com If this is not a bug, then how exactly is one supposed to be able to make the function call self::method($a,$b,$etc) using call_user_func_array()??? or is that not supported? because this still doesn't work. a word or two of explanation would be polite. [2002-10-28 14:10:29] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php 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/18926 -- Edit this bug report at http://bugs.php.net/?id=18926edit=1
#24092 [NEW]: ncurses panel
From: garrote at dm dot com dot br
Operating system: linux 2.4.20
PHP version: 4CVS-2003-06-09 (stable)
PHP Bug Type: Unknown/Other Function
Bug description: ncurses panel
Good morning,
there is a problem with ncurses_panel_window. if you create more than one
panel it doesn´t sets the recurse correctly and return segment fault. i
have to use array to storage the information of window and panel.
one think...we use function to retrieve the information...but i don´t
think that it´s the problem.
function nova_janela($nr_linhas, $nr_colunas, $linha, $coluna, $cor)
{
global $WINDOW;
$win = ncurses_newwin($nr_linhas, $nr_colunas, $linha, $coluna);
if(!$win) // temos uma window
return false;
$janela = ncurses_new_panel($win);
if(!$janela) // temos uma janela
return false;
$WINDOW[$janela] = $win; // coloca na memoria o recurso
if(ncurses_has_colors() and $cor) { // temos cor no terminal
$fg = ($cor == NCURSES_COLOR_BLUE) ? NCURSES_COLOR_WHITE :
NCURSES_COLOR_BLACK;
$bg = $cor;
ncurses_init_pair($cor, $fg, $bg);
ncurses_wattron($win, (color_pair($cor) | ' '));
} else
ncurses_wbkgdsett($win, NCURSES_A_BOLD | ' ');
ncurses_wborder($win, 0,0,0,0,0,0,0,0);
$l = 1;
while($l $nr_linhas - 1) {
$c = 1;
ncurses_wmove($win, $l, 1);
while($c++ $nr_colunas - 1) {
ncurses_waddch($win, 32);
//ncurses_update_panels(); //oops
ncurses_wrefresh($win); //oops
}
$l++;
}
ncurses_update_panels();
ncurses_doupdate();
return $janela;
}
function remove_janela($janela)
{
global $WINDOW;
if(!$janela) // temos uma janela
return false;
//$win = ncurses_panel_window($janela); // error Segment fault
$win = $WINDOW[$janela]; // recupera recurso
if(!$win) // temos uma window
return false;
ncurses_del_panel($janela); // libera janela
ncurses_delwin($win); // libera window
ncurses_update_panels();
ncurses_doupdate();
return true;
}
$WINDOW=ARRAY();
ncurses_init();
if(ncurses_has_colors())
ncurses_start_color();
$i=0;
while($i 5) {
$a[$i] = nova_janela(10 + ($i * 2), 20 + ($i * 5), 10 + $i, 10 +
$i,$i + 1);
$i++;
}
$i=0;
while($i 5) {
remove_janela($a[$i]);
$i++;
}
ncurses_end();
exit;
PHP 4.3.3-dev (cgi) (built: Jun 6 2003 19:30:49)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
[PHP Modules]
ctype
mysql
ncurses
overload
pcre
posix
session
standard
tokenizer
xml
[Zend Modules]
--
Edit bug report at http://bugs.php.net/?id=24092edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24092r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24092r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24092r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24092r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24092r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24092r=support
Expected behavior: http://bugs.php.net/fix.php?id=24092r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24092r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24092r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24092r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24092r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24092r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24092r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24092r=gnused
#24093 [NEW]: fgets can't use you must use fread
From: sanry at now dot net dot cn Operating system: linux PHP version: 4.3.2 PHP Bug Type: Unknown/Other Function Bug description: fgets can't use you must use fread fgets can't use you must use fread -- Edit bug report at http://bugs.php.net/?id=24093edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24093r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24093r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24093r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24093r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24093r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24093r=support Expected behavior: http://bugs.php.net/fix.php?id=24093r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24093r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24093r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24093r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24093r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24093r=dst IIS Stability: http://bugs.php.net/fix.php?id=24093r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24093r=gnused
#24094 [NEW]: Strange segmentation fault
From: francesco dot laurita at fastweb dot it Operating system: Linux 2.4.20 PHP version: 4.3.2 PHP Bug Type: OCI8 related Bug description: Strange segmentation fault The php binary/CLI got segmentation fault at startup. I'm not shure it is a oci8 related but i hope to get it by gdb. This is my steps: [EMAIL PROTECTED] www]$ /usr/local/phpTEST/bin/php -v Segmentation fault (core dumped) [EMAIL PROTECTED] www]$ gdb /usr/local/phpTEST/bin/php GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run Starting program: /usr/local/phpTEST/bin/php [New Thread 1024 (LWP 9768)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 9768)] 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 (gdb) quit The program is running. Exit anyway? (y or n) y [EMAIL PROTECTED] www]$ gdb /usr/local/phpTEST/bin/php core.9766 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... Core was generated by `/usr/local/phpTEST/bin/php -v'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libsablot.so.0...done. Loaded symbols for /usr/lib/libsablot.so.0 Reading symbols from /usr/lib/libexpat.so.0...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /usr/local/freetds/lib/libct.so.1...done. Loaded symbols for /usr/local/freetds/lib/libct.so.1 Reading symbols from /usr/lib/libpng.so.2...done. Loaded symbols for /usr/lib/libpng.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0...done. Loaded symbols for /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /opt/oracle/product/9.0.1/lib/libwtc9.so...done. Loaded symbols for /opt/oracle/product/9.0.1/lib/libwtc9.so Reading symbols from /lib/i686/libpthread.so.0...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 (gdb) bt #0 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #1 0x407a4a67 in skgmidrealm () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #2 0x407a4571 in skgmlocate () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #3 0x407a3f6d in skgmcrone () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #4 0x407a7a2c in skgmcrmany () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #5 0x407a1e7b in skgmcreate () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #6 0x403c8e0d in kgupmcreate_sga () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #7 0x403c64e4 in kgup_startup () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #8 0x4033ec27 in kpushInit () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #9 0x407aee77 in kpummpin () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #10 0x4033ef69 in kpupin () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #11 0x40390f4c in OCIInitialize () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #12 0x0808bf74 in zm_startup_oci (type=1, module_number=10) at /root/php-4.3.2/ext/oci8/oci8.c:489 #13 0x0812cccb in zend_startup_module (module=0x81a3cc0) at /root/php-4.3.2/Zend/zend_API.c:1005 #14 0x08108acf in php_startup_extensions (ptr=0x81aeb84, count=16) at /root/php-4.3.2/main/main.c:1033 #15 0x08142f22 in php_startup_internal_extensions () at main/internal_functions.c:81 #16 0x08108e91 in php_module_startup (sf=0x81ae940, additional_modules=0x0, num_additional_modules=0) at /root/php-4.3.2/main/main.c:1200 #17 0x08142494 in main (argc=2, argv=0xbfffecc4) at
#24063 [Opn-Bgs]: Notice: unserialize(): Error at offset ...
ID: 24063
Updated by: [EMAIL PROTECTED]
Reported By: jparneodo at yahoo dot fr
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: RH7.3
PHP Version: 4.3.2
New Comment:
4.3.3-dev
d:1.E-6;
Previous Comments:
[2003-06-09 05:34:52] jparneodo at yahoo dot fr
Sorry, you must read,
Serialise on 4.3.2 and 4.3.0 has not the same result on RH7.2:
4.3.0= d:1E-06;
4.3.2= d::.E-7;
[2003-06-09 05:16:20] [EMAIL PROTECTED]
Please correct the version error in your last message.
[2003-06-09 03:50:30] jparneodo at yahoo dot fr
Serialise on 4.3.2 and 4.3.0 has not the same result:
4.3.2= d:1E-06;
4.3.0= d::.E-7;
?php
echo phpversion();
$f=1.0e-6;
$s=serialize($f);
$ff=unserialize($s);
echo \n\n$s;
?
// Output with php-4.3.2/sapi/cli/php
4.3.2
Notice: unserialize(): Error at offset 0 of 8 bytes in - on line 5
d::.E-7;
// Output with php-4.3.0 apache 1.3.27 on RedHat
4.3.0
d:1E-06;
// Same result on RH9.0 with all php-4.3.2RCi
http://marc.theaimsgroup.com/?l=php-devm=105491350013813w=2
[2003-06-06 14:36:44] [EMAIL PROTECTED]
Withing RH 6.2 the original object is identical to the
one after serialize/unserialize. No bug here.
[2003-06-06 11:08:04] jparneodo at yahoo dot fr
class C {
var $bad_1 = 1e-6; // Bug in unserialize
var $bad_2 = 1.0e-6;// Bug in unserialize
var $ok__1 = 1.1e-6;
var $ok__2 = 9e-7;
}
$c=new C();
$s=serialize($c);
$cc=unserialize($s);
/*
Values like 0.1 (one)
seems to be fatal!
*/
--
Edit this bug report at http://bugs.php.net/?id=24063edit=1
#24093 [Opn-Fbk]: fgets can't use you must use fread
ID: 24093 Updated by: [EMAIL PROTECTED] Reported By: sanry at now dot net dot cn -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: linux PHP Version: 4.3.2 New Comment: 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. Previous Comments: [2003-06-09 08:04:14] sanry at now dot net dot cn fgets can't use you must use fread -- Edit this bug report at http://bugs.php.net/?id=24093edit=1
#24043 [Opn-Bgs]: include()/require() not working properly with absolute URL
ID: 24043 Updated by: [EMAIL PROTECTED] Reported By: delmatto at genotec dot ch -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Debian GNU/Linux 3.0 / stable PHP Version: 4.3.2 New Comment: Both scripts work just fine. No bug. Previous Comments: [2003-06-07 05:03:32] delmatto at genotec dot ch I am Sorry, I understood you wantet a working link to see the scripts in action... This is the code of the two test files I use: ---begin test.php--- ?PHP include(http://gic-web-lin-01.genotec.ch/php/gd/index.php;); ? ---end--- ---begin test2.php--- ?PHP include(http://support.genotec.ch/main.asp;); ? ---end--- [2003-06-07 04:52:43] [EMAIL PROTECTED] I asked for a SOURCE of a script that I can run myself. [2003-06-07 02:54:51] delmatto at genotec dot ch use the following for a server running php 4.3.1 (original config) http://212.80.185.102/test.php (- http://212.80.185.102/php/gd/index.php) http://212.80.185.102/test2.php (- http://support.genotec.ch/main.asp) here the error happens, no matter wether I include from the same server or from an external one as in the later case. now these for the server running 4.3.3-dev snapshot http://212.80.185.101/test.php (- http://212.80.185.101/php/gd/index.php) http://212.80.185.101/test2.php (- http://support.genotec.ch/main.asp) here comes a very strange behaviour as it sometimes works without this 'headers' and sometimes the page even stays blank, then I find the following in the error log: [Sat Jun 7 09:34:29 2003] [error] PHP Warning: main(http://gic-web-lin-01.genotec.ch/php/gd/index.php): failed to open stream: HTTP request failed! [EMAIL PROTECTED]@P_P #9227;[EMAIL PROTECTED]@T #9227;#9532; /#9524;#9618;#9148;/#9252;#9228;#9228;/#9252;#9500;#9229;#9146;#9228;#9149;/#9229;#9226;°#9618;#9508;#9484;#9500;/#9500;#9226;#9149;#9500;.#9147;#9252;#9147; #9146;#9532; #9484;#9227;#9532;#9226; 4 to reproduce just try to reload the page a few times. I'm not sure wether this header problem is gone now, though the error shown in the log was only introduced when using the new snapshot. It seems like it would only happen when including from the same server, not from an external one, as I couldn't reproduce it on the second url. PHP4 ist running as mod_php in Apache. There is no mod_php3. CGI is not specifically configured in apache, however I didn't use the '--disable-cgi' switch when building PHP, if anyone happens to rename a .php file to .cgi and adds a #!/usr/bin/php to the top of the file, it would run over cgi/suexec. Normal .php/php3/phtml files run through mod_php. [2003-06-06 18:40:38] [EMAIL PROTECTED] Can you give some example script which definately fails for you everytime? (using some url anybody can access) Do you happen to have also CGI version of PHP configured in your Apache? Or PHP 3 as module? [2003-06-06 12:31:23] delmatto at genotec dot ch While another problem not mentioned here has gone, the one described still remains as of snapshot 4.3.3-200306061130. Could old dev headers be the source for this problem? I mean, not all dev-headers are up to date since I had to stick to some from debian stable... Just for your reference, I used the following to compile PHP: apache 1.3.26-dev (debian3/stable) curl 7.10.2 gd 2.0.9 (not the one shipped with php) libxml 2.4.30 mind 0.2a pdflib 4.0.3 sablot 0.96.1 xslt 1.0.23 freetds 0.53 libexpat 1.95.2 openssl 0.96c libjpeg62 6b libpng2 1.0.12 freetype6 2.0.9 libmcal 0.6 mhash 0.8.14 pcre3 3.4 recode 3.6 mcrypt 2.5.0 pgsql 7.2.1 I hope I didn't miss one out. 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/24043 -- Edit this bug report at http://bugs.php.net/?id=24043edit=1
#19617 [Opn-Ver]: Array_multisort don't work on GLOBAL array
ID: 19617
Updated by: [EMAIL PROTECTED]
Reported By: jpapin at free dot fr
-Status: Open
+Status: Verified
-Bug Type: Arrays related
+Bug Type: Scripting Engine problem
Operating System: Unix
-PHP Version: 4.2.0
+PHP Version: 4.3.3-dev
Previous Comments:
[2003-06-08 04:45:12] jpapin at free dot fr
A nice guy from Germany want me to turn the bug open again.
[2003-05-13 07:19:03] matschek at gmx dot de
Another hint:
if you pass the $data as a reference [for my example above:
'array_multisort($sort, $data);'], it works - but this is deprecated,
so this cant be the solution..
[2003-05-13 07:03:27] matschek at gmx dot de
Tested with PHP 4.3.1, same problem:
Globalized arrays cannot be sorted using array_multisort, although the
functions returns TRUE!
Another short piece of code to test:
?
function test() {
global $data;
$data= array(first, fifth, second, forth, third);
$sort= array(1,5,2,4,3);
array_multisort($sort, $data);
print_r($data);
}
test();
?
Without global $data; it works fine.
[2002-10-14 19:37:40] [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.
[2002-09-26 11:14:55] [EMAIL PROTECTED]
Works fine here with latest CVS head.
Please, try PHP 4.2.3. (4.2.0 is really too old..)
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/19617
--
Edit this bug report at http://bugs.php.net/?id=19617edit=1
#23942 [Opn]: php 4.3.x causes apache2+mod_ssl to sigsev on client authentication
ID: 23942 User updated by: alextxm at tin dot it Reported By: alextxm at tin dot it Status: Open Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.2 New Comment: I did some more tests but i'm still unable to obtain a backtrace. I tried : gdb /usr/sbin/apache2 gdb run -X -D SSL -D PHP output is: Starting program: /usr/sbin/apache2 -X -D PHP -D SSL (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[New Thread 1024 (LWP 24998)] (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... ---Type return to continue, or q return to quit--- is there something i forgot? can you please help me obtaining the bt? I think it would be really helpful having something to work on for this bug. I'm available for any kind of operation aimed to obtain the bt or anything else you would need for inevstigating this bug alessandro Previous Comments: [2003-06-02 14:33:28] alextxm at tin dot it i'm having problems trying to obtain the bt: i get a lot of (no debugging symbols found)...(no debugging symbols found)... messages and when it works (it usually gives me an Unable to contact site sitename error in the browser), i get no bt all (even if I ask for a bt) but a message like: LWP thread 26404 ended with error 1 any idea? btw please note that i'm now going to move the whole thing on a new server (where i can try to obtain bt and all what you could need) since the current one is a production one and so I can't shut down it for tests for a long time... [2003-06-02 13:21:38] [EMAIL PROTECTED] No, don't change the MPM. And yes, you will get a backtrace always, it's not really PHP related thing. # gdb httpd (gdb) run -X -DSSL ..then access the page causing the crash.. (gdb) bt [2003-06-02 13:00:59] alextxm at tin dot it I did some more tests: - enabling your suggested configure cleanups didn't help (=the problem is still there)...thanks anyway (i was using them since previous 4.2.x release) - tested the same setup with apache 1.3.27+mod_ssl : it works fine with php both enabled and disabled... so it seems to be only confined to apache2+ssl+php - MPM used for apache2 is prefork ... should I change it? - php 4.3.1 and 4.3.2 both show the issue i'm going to try to obtain a backtrace using httpd -X with php in debug mode. btw, will this work (=will it produce a backtrace) even if the site is not using any php script at all ? [2003-06-02 05:51:35] [EMAIL PROTECTED] Your configure line contains couple of options that are really unnecessary, for example these: -with-db (use --enable-dba) --enable-versioning (Only needed if you have php3 installed too and that doesn't support Apache2, so..) --enable-track-vars (doesn't exist), --enable-inline-optimization (might cause problems) --without-readline (not enabled by default anyway) --disable-posix-threads (why?) --enable-force-cgi-redirect (Only used for CGI build) --enable-discard-path (Only used for CGI builds) And what MPM is used for Apache2? Remove those options mentioned above + --enable-debug and try again. (rm -f config.cache first!) If it still crashes, provide the backtrace. [2003-06-02 03:51:19] alextxm at tin dot it yes i'm sure they use the same openssl library since i've complied both openssl, apache2 and
#24083 [Opn-Fbk]: Content-Encoding: gzip output includes the wrong Content-Length header
ID: 24083 Updated by: [EMAIL PROTECTED] Reported By: yngve at opera dot com -Status: Open +Status: Feedback -Bug Type:*Compression related +Bug Type:Zlib Related PHP Version: 4.3.1 New Comment: Does this happen with PHP 4.3.2 ? Previous Comments: [2003-06-08 15:24:24] yngve at opera dot com I am a developer with Opera Software, the developer of the Opera browser. We have received several reports about problems with forums using VBulletin, but based on what I've learned I suspect that the problem is a general PHP problem, not Vbulletin specific. The reason for the problem turns out to be the same, or of a similar nature, as my earlier bug report #12884. A while ago I was in contact with one of the boards affected by the problem Rage3D.com. They reported back that they were able to solve the problem by turning off global compression From the Rage3D people (with permission): The problem was caused because we were running the php output_handler = ob_gzhandler for global site compression. vB didn't know to use the right content length header. We've resolved the issue by turning off global compression and enabling gzip encoding through vBulletin. We will be seeing if an updated gzip library for our server will resolve the issue so we can run global php compression in the future. The following is a hexdump of the request and response headers from one of my tests (before Rage3D fixed the problem). --- : 47 45 54 20 2f 62 6f 61 72 64 2f 20 48 54 54 50 GET /board/ HTTP 0010 : 2f 31 2e 31 0d 0a 55 73 65 72 2d 41 67 65 6e 74 /1.1..User-Agent 0020 : 3a 20 4d 6f 7a 69 6c 6c 61 2f 34 2e 30 20 28 63 : Mozilla/4.0 (c 0030 : 6f 6d 70 61 74 69 62 6c 65 3b 20 4d 53 49 45 20 ompatible; MSIE 0040 : 36 2e 30 3b 20 57 69 6e 64 6f 77 73 20 4e 54 20 6.0; Windows NT 0050 : 35 2e 30 29 20 4f 70 65 72 61 20 37 2e 31 31 20 5.0) Opera 7.11 0060 : 20 5b 65 6e 5d 0d 0a 48 6f 73 74 3a 20 77 77 77 [en]..Host: www 0070 : 2e 72 61 67 65 33 64 2e 63 6f 6d 0d 0a 41 63 63 .rage3d.com..Acc 0080 : 65 70 74 3a 20 74 65 78 74 2f 68 74 6d 6c 2c 20 ept: text/html, 0090 : 69 6d 61 67 65 2f 70 6e 67 2c 20 69 6d 61 67 65 image/png, image 00a0 : 2f 6a 70 65 67 2c 20 69 6d 61 67 65 2f 67 69 66 /jpeg, image/gif 00b0 : 2c 20 69 6d 61 67 65 2f 78 2d 78 62 69 74 6d 61 , image/x-xbitma 00c0 : 70 2c 20 2a 2f 2a 3b 71 3d 30 2e 31 0d 0a 41 63 p, */*;q=0.1..Ac 00d0 : 63 65 70 74 2d 4c 61 6e 67 75 61 67 65 3a 20 65 cept-Language: e 00e0 : 6e 3b 71 3d 31 2e 30 2c 65 6e 3b 71 3d 30 2e 39 n;q=1.0,en;q=0.9 00f0 : 0d 0a 41 63 63 65 70 74 2d 43 68 61 72 73 65 74 ..Accept-Charset 0100 : 3a 20 77 69 6e 64 6f 77 73 2d 31 32 35 32 2c 20 : windows-1252, 0110 : 75 74 66 2d 38 2c 20 75 74 66 2d 31 36 2c 20 69 utf-8, utf-16, i 0120 : 73 6f 2d 38 38 35 39 2d 31 3b 71 3d 30 2e 36 2c so-8859-1;q=0.6, 0130 : 20 2a 3b 71 3d 30 2e 31 0d 0a 41 63 63 65 70 74 *;q=0.1..Accept 0140 : 2d 45 6e 63 6f 64 69 6e 67 3a 20 64 65 66 6c 61 -Encoding: defla 0150 : 74 65 2c 20 67 7a 69 70 2c 20 78 2d 67 7a 69 70 te, gzip, x-gzip 0160 : 2c 20 69 64 65 6e 74 69 74 79 2c 20 2a 3b 71 3d , identity, *;q= 0170 : 30 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 4b 0..Connection: K 0180 : 65 65 70 2d 41 6c 69 76 65 0d 0a 0d 0aeep-Alive : 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK. 0010 : 0a 53 65 72 76 65 72 3a 20 4d 69 63 72 6f 73 6f .Server: Microso 0020 : 66 74 2d 49 49 53 2f 35 2e 30 0d 0a 44 61 74 65 ft-IIS/5.0..Date 0030 : 3a 20 54 68 75 2c 20 30 38 20 4d 61 79 20 32 30 : Thu, 08 May 20 0040 : 30 33 20 30 32 3a 32 30 3a 30 33 20 47 4d 54 0d 03 02:20:03 GMT. 0050 : 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f .Connection: clo 0060 : 73 65 0d 0a 58 2d 50 6f 77 65 72 65 64 2d 42 79 se..X-Powered-By 0070 : 3a 20 50 48 50 2f 34 2e 33 2e 31 0d 0a 43 6f 6e : PHP/4.3.1..Con 0080 : 74 65 6e 74 2d 74 79 70 65 3a 20 74 65 78 74 2f tent-type: text/ 0090 : 68 74 6d 6c 0d 0a 53 65 74 2d 43 6f 6f 6b 69 65 html..Set-Cookie 00a0 : 3a 20 73 65 73 73 69 6f 6e 68 61 73 68 3d 38 65 : sessionhash=8e 00b0 : 33 32 32 36 63 30 33 32 34 31 31 32 32 66 33 30 3226c03241122f30 00c0 : 31 38 64 64 33 64 64 62 38 61 38 63 37 61 3b 20 18dd3ddb8a8c7a; 00d0 : 70 61 74 68 3d 2f 0d 0a 53 65 74 2d 43 6f 6f 6b path=/..Set-Cook 00e0 : 69 65 3a 20 62 62 6c 61 73 74 76 69 73 69 74 3d ie: bblastvisit= 00f0 : 31 30 35 32 33 36 30 34 30 33 3b 20 65 78 70 69 1052360403; expi 0100 : 72 65 73 3d 46 72 69 2c 20 30 37 2d 4d 61 79 2d res=Fri, 07-May- 0110 : 32 30 30 34 20 30 32 3a 32 30 3a 30 33 20 47 4d 2004 02:20:03 GM 0120 : 54 3b 20 70 61 74 68 3d 2f 0d 0a 43 6f 6e 74 65 T; path=/..Conte 0130 : 6e 74 2d 4c 65 6e 67 74 68 3a 20 36 39 31 37 33 nt-Length: 69173 0140 : 0d 0a 43 6f 6e 74 65 6e 74 2d 45 6e 63 6f 64 69 ..Content-Encodi 0150 : 6e 67 3a 20 67 7a 69
#24091 [Opn-Fbk]: CLI Segfault
ID: 24091 Updated by: [EMAIL PROTECTED] Reported By: devon at sitetronics dot com -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: RHL 7.3/kern 2.4.21-rc6 PHP Version: 4.3.2 New Comment: What might that script contain..? I can not reproduce this with PHP 4.3.3-dev. Previous Comments: [2003-06-09 04:46:47] devon at sitetronics dot com Same in 4.3.2 [2003-06-09 04:35:11] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. And disable any accelerator, caching and encoding products. [2003-06-09 04:33:23] devon at sitetronics dot com Goofing around with shell scripting in PHP, I bumped into this problem. I scanned the other segfault bugs, but I didn't find one like this. Additionally, I haven't tried with any nightlies, so sorry, but here we go. When running a script with the CLI binary as so: # php -q somescript.php I receive a segfault. This should work as PHP should parse stuff from stdin, and this is just a pipe. Copying the script to stdin when calling PHP as #php -q I'm able to run the script successfully. Additionally, I can run the script by doing # php -q somescript.php I'm positive that this is because I have PHP reading its pipe from stdin and then requesting user input from stdin as well. But PHP should die gracefully and not segfault. Oh yeah, here's the really strange backtrace #0 0x081299f8 in zend_parse_arg (arg_num=1, arg=0x402c039c, va=0xbf800834, spec=0xbf800824, quiet=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:436 #1 0x08129df8 in zend_parse_va_args (num_args=2, type_spec=0x81568b6 ss|br, va=0xbf800834, flags=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:527 #2 0x08129e5b in zend_parse_parameters (num_args=2, type_spec=0x81568b6 ss|br) at /root/build/php/php-4.3.1/Zend/zend_API.c:554 #3 0x080a9c8e in php_if_fopen (ht=2, return_value=0x81d5884, this_ptr=0x0, return_value_used=1) at /root/build/php/php-4.3.1/ext/standard/file.c:1086 #4 0x4027f922 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #5 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #6 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #7 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #8 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #9 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #10 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #11 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #12 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #13 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #14 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #15 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #16 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #17 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so ... #11382 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #11383 0x08102869 in php_execute_script (primary_file=0xbac0) at /root/build/php/php-4.3.1/main/main.c:1573 #11384 0x08143610 in main (argc=2, argv=0xbb64) at /root/build/php/php-4.3.1/sapi/cli/php_cli.c:746 #11385 0x401331c4 in __libc_start_main () from /lib/libc.so.6 Aha! But before you say idiot, go email Nick, here's the backtrace with the loader turned off :P. It just proves that Nick's gotta fix his stuff also. #0 0x081299f8 in zend_parse_arg (arg_num=1, arg=0x824be44, va=0xbf800754, spec=0xbf800744, quiet=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:436 #1 0x08129df8 in zend_parse_va_args (num_args=2, type_spec=0x81568b6 ss|br, va=0xbf800754, flags=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:527 #2 0x08129e5b in zend_parse_parameters (num_args=2, type_spec=0x81568b6 ss|br) at /root/build/php/php-4.3.1/Zend/zend_API.c:554 #3 0x080a9c8e in php_if_fopen (ht=2, return_value=0x81d47c4, this_ptr=0x0, return_value_used=1) at /root/build/php/php-4.3.1/ext/standard/file.c:1086 #4 0x0813b09c in execute (op_array=0x81cffd0) at
#24086 [Opn-Fbk]: file_exists generates false error
ID: 24086
Updated by: [EMAIL PROTECTED]
Reported By: danfratus at attbi dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows XP Professional
PHP Version: 4.3.2
New Comment:
Exactly what is the bug here? file_exists(...) ??
or what? (that returns FALSE..)
Previous Comments:
[2003-06-08 17:41:14] danfratus at attbi dot com
?
if (file_exists($file) $file != . $file != ..)
{
$file = join('',file($file));
echo $file;
}
?
Ok the glitch is this: if $file is . or .. the script is fine, no
errors are generated, but, when $file is ... or ... or
.., etc. then for some reason PHP reconizes this as a
directory, yet it can't be included therefore generating this error:
---
Warning: file(...) [function.file]: failed to create stream: No such
file or directory in F:\server\bug.php on line 4
Warning: join() [function.join]: Bad arguments. in F:\server\bug.php on
line 4
---
This bug isn't going to crash the entire internet or anything, but it
should be fixed.
--
Edit this bug report at http://bugs.php.net/?id=24086edit=1
#24094 [Opn-Fbk]: Strange segmentation fault
ID: 24094 Updated by: [EMAIL PROTECTED] Reported By: francesco dot laurita at fastweb dot it -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: Linux 2.4.20 PHP Version: 4.3.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2003-06-09 08:06:58] francesco dot laurita at fastweb dot it The php binary/CLI got segmentation fault at startup. I'm not shure it is a oci8 related but i hope to get it by gdb. This is my steps: [EMAIL PROTECTED] www]$ /usr/local/phpTEST/bin/php -v Segmentation fault (core dumped) [EMAIL PROTECTED] www]$ gdb /usr/local/phpTEST/bin/php GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run Starting program: /usr/local/phpTEST/bin/php [New Thread 1024 (LWP 9768)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 9768)] 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 (gdb) quit The program is running. Exit anyway? (y or n) y [EMAIL PROTECTED] www]$ gdb /usr/local/phpTEST/bin/php core.9766 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... Core was generated by `/usr/local/phpTEST/bin/php -v'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libsablot.so.0...done. Loaded symbols for /usr/lib/libsablot.so.0 Reading symbols from /usr/lib/libexpat.so.0...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /usr/local/freetds/lib/libct.so.1...done. Loaded symbols for /usr/local/freetds/lib/libct.so.1 Reading symbols from /usr/lib/libpng.so.2...done. Loaded symbols for /usr/lib/libpng.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0...done. Loaded symbols for /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /opt/oracle/product/9.0.1/lib/libwtc9.so...done. Loaded symbols for /opt/oracle/product/9.0.1/lib/libwtc9.so Reading symbols from /lib/i686/libpthread.so.0...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 (gdb) bt #0 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #1 0x407a4a67 in skgmidrealm () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #2 0x407a4571 in skgmlocate () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #3 0x407a3f6d in skgmcrone () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #4 0x407a7a2c in skgmcrmany () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #5 0x407a1e7b in skgmcreate () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #6 0x403c8e0d in kgupmcreate_sga () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #7 0x403c64e4 in kgup_startup () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #8 0x4033ec27 in kpushInit () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #9 0x407aee77 in kpummpin () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #10 0x4033ef69 in kpupin () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #11 0x40390f4c in OCIInitialize () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #12 0x0808bf74 in zm_startup_oci (type=1, module_number=10) at /root/php-4.3.2/ext/oci8/oci8.c:489 #13 0x0812cccb in zend_startup_module (module=0x81a3cc0) at /root/php-4.3.2/Zend/zend_API.c:1005
#24092 [Opn-Bgs]: ncurses panel
ID: 24092
Updated by: [EMAIL PROTECTED]
Reported By: garrote at dm dot com dot br
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: linux 2.4.20
PHP Version: 4CVS-2003-06-09 (stable)
New Comment:
Fatal error: Call to undefined function: ncurses_wbkgdset()
Try provide a script that has even remote possibility on
working..or at least a GDB backtrace.
Previous Comments:
[2003-06-09 07:33:07] garrote at dm dot com dot br
Good morning,
there is a problem with ncurses_panel_window. if you create more than
one panel it doesn´t sets the recurse correctly and return segment
fault. i have to use array to storage the information of window and
panel.
one think...we use function to retrieve the information...but i don´t
think that it´s the problem.
function nova_janela($nr_linhas, $nr_colunas, $linha, $coluna, $cor)
{
global $WINDOW;
$win = ncurses_newwin($nr_linhas, $nr_colunas, $linha,
$coluna);
if(!$win) // temos uma window
return false;
$janela = ncurses_new_panel($win);
if(!$janela) // temos uma janela
return false;
$WINDOW[$janela] = $win; // coloca na memoria o recurso
if(ncurses_has_colors() and $cor) { // temos cor no terminal
$fg = ($cor == NCURSES_COLOR_BLUE) ?
NCURSES_COLOR_WHITE : NCURSES_COLOR_BLACK;
$bg = $cor;
ncurses_init_pair($cor, $fg, $bg);
ncurses_wattron($win, (color_pair($cor) | ' '));
} else
ncurses_wbkgdsett($win, NCURSES_A_BOLD | ' ');
ncurses_wborder($win, 0,0,0,0,0,0,0,0);
$l = 1;
while($l $nr_linhas - 1) {
$c = 1;
ncurses_wmove($win, $l, 1);
while($c++ $nr_colunas - 1) {
ncurses_waddch($win, 32);
//ncurses_update_panels(); //oops
ncurses_wrefresh($win); //oops
}
$l++;
}
ncurses_update_panels();
ncurses_doupdate();
return $janela;
}
function remove_janela($janela)
{
global $WINDOW;
if(!$janela) // temos uma janela
return false;
//$win = ncurses_panel_window($janela); // error Segment fault
$win = $WINDOW[$janela]; // recupera recurso
if(!$win) // temos uma window
return false;
ncurses_del_panel($janela); // libera janela
ncurses_delwin($win); // libera window
ncurses_update_panels();
ncurses_doupdate();
return true;
}
$WINDOW=ARRAY();
ncurses_init();
if(ncurses_has_colors())
ncurses_start_color();
$i=0;
while($i 5) {
$a[$i] = nova_janela(10 + ($i * 2), 20 + ($i * 5), 10 + $i, 10
+ $i,$i + 1);
$i++;
}
$i=0;
while($i 5) {
remove_janela($a[$i]);
$i++;
}
ncurses_end();
exit;
PHP 4.3.3-dev (cgi) (built: Jun 6 2003 19:30:49)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
[PHP Modules]
ctype
mysql
ncurses
overload
pcre
posix
session
standard
tokenizer
xml
[Zend Modules]
--
Edit this bug report at http://bugs.php.net/?id=24092edit=1
#24006 [Fbk-NoF]: Segmentation fault - related possibly to error handling functions
ID: 24006
Updated by: [EMAIL PROTECTED]
Reported By: mikemc-phpbug at contactdesigns dot com
-Status: Feedback
+Status: No Feedback
Bug Type: Reproducible crash
Operating System: Linux 2.4.x
PHP Version: 4.3.2
New Comment:
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.
Previous Comments:
[2003-06-04 05:19:50] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
I can not reproduce this crash with latest stable CVS checkout..
[2003-06-04 01:47:08] mikemc-phpbug at contactdesigns dot com
Here are the config parameters you will need to set prior to running
the code (I only changed 4 from the original config where the crash was
happening):
// Set environment - either production or development
$CDS_CONFIG['ENV_MODE'] = 'production';
// Semicolon delimited list of developers responsible
$CDS_CONFIG['ADMINS'] = '[EMAIL PROTECTED]';
// Error log - be sure to specify full path
$CDS_CONFIG['ERROR_LOG'] = '/tmp/error.log';
// Template to be displayed to end users in production environment when
an error
// occurs. For example, The web server has fallen and can't get up
;-)
$CDS_CONFIG['ERROR_TEMPLATE'] = '/tmp/error_template.html';
// Error callback function that can alter the way the error handler
behaves.
// Read lib/Error/Handler.php for more information.
$CDS_CONFIG['ERROR_CALLBACK'] = NULL;
// Set the error reporting level based on the environment
$CDS_CONFIG['ERROR_REPORTING'] = ($CDS_CONFIG['ENV_MODE'] ==
'development')
? (E_ERROR | E_WARNING | E_PARSE |
E_NOTICE)
: (E_ALL ~E_NOTICE);
// Log that debug messages are sent to (tail -f this file during
debugging)
$CDS_CONFIG['DEBUG_LOG'] = '/tmp/debug.log';
// Specify where debug output goes (browser or log)
$CDS_CONFIG['DEBUG_MODE'] = 'browser';
// Regular expression specifying which variables are not sent to debug
output
$CDS_CONFIG['DEBUG_EXCLUSION'] = '/.*(?:HTTP|CDS)/s';
[2003-06-04 01:10:44] [EMAIL PROTECTED]
I can not reproduce this, I only get this:
Fatal error: CDS_Error_Handler_Init() - Missing parameters in
/home/jani/t.php on line 62
(I just took that handler.phps and pasted it to a file and added the
CDS_Error_Handler_Init(); line)
Could you please try creating a SHORT example script
which can be just copied and run..?
And/Or generate a GDB backtrace of this crash..
[2003-06-03 23:55:42] mikemc-phpbug at contactdesigns dot com
I have code that ran fine under 4.3.1 compiled with Apache like so:
'./configure' '--with-openssl' '--enable-memory-limit'
'--with-mysql=/usr/local/mysql' '--with-zlib'
'--with-apache=../apache_1.3.27' '--enable-inline-optimization'
'--with-curl=/usr/local' '--with-mcrypt=/usr/local'
It was compiled the same exact way with 4.3.2 except with a newer
version of curl.
This same code now causes a segmentation fault under 4.3.2:
[Tue Jun 3 21:25:51 2003] [notice] child pid 12107 exit signal
Segmentation fault (11)
The offending code is related to a user defined error handler. My
current workaround: remove the error handling code. I have isolated
the problem to a single file and a function within that file. When I
comment out the code that loads this file and calls that function, the
segfaults stop and the code runs as normal:
//include_once('lib/Error/Handler.php');
//CDS_Error_Handler_Init();
Furthermore, I have to call the function - loading the file alone does
not cause the problem. This error handler is a very old version of our
current one which has changed significantly and has no problems in
4.3.2. You can find the code here:
http://caffeine.contactdesigns.com/~jolt/Handler.phps
I hope this helps - I am in no way put in a bind because of this bug -
it is old code and does nothing for us now. Just hoping to help PHP
out in any way possible. I tried out RC1 on the developemntal
servers, but as it is sometimes, you don't catch the bug until you go
to production.
--
Edit this bug report at http://bugs.php.net/?id=24006edit=1
#23974 [Fbk-NoF]: Floating point data loss in serialize() (and sessions)
ID: 23974 Updated by: [EMAIL PROTECTED] Reported By: ejik at transfer dot kg -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: any PHP Version: 4.3.2 New Comment: 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. Previous Comments: [2003-06-03 04:31:19] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-06-03 03:27:45] ejik at transfer dot kg Bug #23298 Floating point data loss in serialize() (and sessions) This bug seems to be not fixed! Script: ?php ini_set(precision, 32); $var = 1.4285714285714286476; var_dump($var); $foo = serialize($var); echo '', $foo, \n; $x = unserialize($foo); var_dump($x); var_dump($x === $var); ini_set(precision, 12); $var = 1.4285714285714286476; var_dump($var); $foo = serialize($var); echo '', $foo, \n; $x = unserialize($foo); var_dump($x); var_dump($x === $var); ? output: float(000ý) d:000ý; bool(false) bool(false) float(000ý) d:000ý; n bool(false) bool(false) -- Edit this bug report at http://bugs.php.net/?id=23974edit=1
#23893 [Fbk-NoF]: setcookie fails if $_GET value is empty
ID: 23893
Updated by: [EMAIL PROTECTED]
Reported By: info at splendense dot nl
-Status: Feedback
+Status: No Feedback
Bug Type: CGI related
Operating System: sunOS
PHP Version: 4.3.2
New Comment:
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.
Previous Comments:
[2003-06-03 02:38:12] [EMAIL PROTECTED]
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.
unable to repro on apache/cgi/win32 with 4.2.3, 4.3.2 or CVS.
Perhaps you should consider (warnings were breaking setting the cookie
for me):
?php
if (isset($_GET[something]))
$something = $_GET[something];
$value = this is a value;
if (!setcookie (TestCookie, $value)) {
print (cookie NOT set!);
} else {
print (cookie set!);
}
?
Otherwise, you need to provide more details on configuration of your
system.
[2003-05-30 05:05:27] info at splendense dot nl
I'm running php as CGI API and register globals and i'm trying the
following script:
?php
$something = $_GET[something];
$value = this is a value;
if (!setcookie (TestCookie, $value)) {
print (cookie NOT set!);
} else {
print (cookie set!);
}
?
with the following outputs:
1. www.server.com/script.php?something=
outputs: 'cookie set!'
2. www.server.com/script.php
outputs: 'cookie NOT set!'
3. www.server.com/script.php?somehting=value
outputs: 'cookie set!'
4. www.server.com/script.php?something_else=
outputs: 'cookie NOT set!'
so if I try to read a variable (can be GET/COOKIE/POST/...) and it is
not explicitly specified, even if it's empty, cookies can't be set
anymore.
I think it has to do with being a CGI API, because on another server
where it's installed as apache API I don't have this problem.
can anyone verify this?
--
Edit this bug report at http://bugs.php.net/?id=23893edit=1
#23883 [Fbk-NoF]: PHP crashes if snmp module loaded
ID: 23883 Updated by: [EMAIL PROTECTED] Reported By: joey at joeysmith dot com -Status: Feedback +Status: No Feedback Bug Type: SNMP related Operating System: Debian sarge (testing) PHP Version: 4.3.2 New Comment: 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. Previous Comments: [2003-06-02 10:28:06] [EMAIL PROTECTED] Use the sources..not some debian package which is most likely broken anyway. (And no idea how it's configured either) [2003-06-02 08:09:27] joey at joeysmith dot com Using SNMP 5.0.7 (debian testing package libsnmp5-dev) still exhibits the crash. I'll build SNMP as static as well. [2003-06-02 06:38:19] [EMAIL PROTECTED] And/or compile it as static module, NOT shared. [2003-06-02 06:37:40] [EMAIL PROTECTED] It works just fine here with net-snmp-5.0.6 so you really should try it.. [2003-06-01 21:14:26] joey at joeysmith dot com ./configure --with-snmp is sufficent to reproduce this bug. I'd be surprised if this were an SNMP bug, as the only thing I have to do to duplicate this bug is to run the PHP cli with SNMP enabled. e.g., /usr/bin/php -v 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/23883 -- Edit this bug report at http://bugs.php.net/?id=23883edit=1
#22574 [Fbk-NoF]: unsatisfied symbols freeaddrinfo and getaddrinfo
ID: 22574 Updated by: [EMAIL PROTECTED] Reported By: john345 at earthlink dot net -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: SCO OpenServer 5.0.6 PHP Version: 4.3.2-dev New Comment: 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. Previous Comments: [2003-06-04 23:05:32] [EMAIL PROTECTED] Can not fix this as I do not have access to any machine with SCO. Try find out what lib contains these functions.. [2003-06-04 07:31:12] john345 at earthlink dot net Any new developments on this front? [2003-05-09 13:03:45] john345 at earthlink dot net Same error during make. Undefined first referenced symbol in file freeaddrinfomain/network.lo getaddrinfo main/network.lo sapi/cli/php: fatal error: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Yes, the system has freeaddrinfo and getaddrinfo. Here is part of the man page entry: getaddrinfo(SLIB) * getaddrinfo -- nodename-to-address translation in protocol-independent manner freeaddrinfo- nodename-to-address translation in protocol-independent manner gai_strerror- nodename-to-address translation in protocol-independent manner Syntax == cc ... -lsocket #include sys/socket.h #include netdb.h int getaddrinfo(const char *nodename, const char *servname, const struct addrinfo *hints, struct addrinfo **res); void freeaddrinfo(struct addrinfo *ai); char * gai_strerror(int ecode); Description === The getaddrinfo() function is defined for protocol-independent nodename- to-address translation. It performs functionality of gethostbyname(SLIB) and getservbyname(SLIB), in more sophisticated manner. The addrinfo structure is defined as a result of including the netdb.h header: ... [2003-05-01 19:43:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip You might have got the one with broken configure. Also, does your libsocket.* contain these missing functions? [2003-04-16 12:12:29] john345 at earthlink dot net Still get same two unsatisfied symbols, freeaddrinfo and getaddrinfo, but this time it is reported that they are first referenced in main/network.o. 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/22574 -- Edit this bug report at http://bugs.php.net/?id=22574edit=1
#20449 [Fbk-NoF]: sessions randomly fail
ID: 20449 Updated by: [EMAIL PROTECTED] Reported By: josh at zebotech dot com -Status: Feedback +Status: No Feedback Bug Type: Session related Operating System: redhat 7.3 -PHP Version: 4.4.0-dev +PHP Version: 4.3.0-dev New Comment: 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. Previous Comments: [2003-06-02 17:09:32] [EMAIL PROTECTED] This should be fixed in PHP 4.3.2, so please give it a try. [2003-06-02 14:44:35] radek at pinkbike dot com I also have seen behaviour of missing session data. I have detected this in the custom shopping cart I have written. Every 20 or 30 orders we get a blank order. This blank order is a result of the session cart is not picked up on the last stage of the purchase process. I went through my code a million times to try to figure out how I could of caused this but reading this bug report I starting to think it maybe a result of php session/serialization. Like the other person with the shopping cart stated, who knows how many users don't even make it to the last step and their cart disappears. I store associative arrays in the session I run on a dual CPU intel box The site is relatively high load - 3 million hits a day I have not been able to reproduce the problem myself It has been happening regularly since January when i put up the software - it happens on a few versions of php since Jan 2003 What are options here? Any documentation, warnings about what not to store in php sessions? Should I be writting my own handler/serializer? here are the box details Apache/1.3.26 PHP Version 4.3.1 System Linux superlight 2.4.20-xfs #2 SMP Mon Apr 7 21:06:32 CDT 2003 i686 Build Date May 1 2003 00:21:10 Configure Command './configure' '--with-apxs=/usr/bin/apxs' '--with-mysql=/usr/local/mysql' '--with-openssl' '--with-zlib' '--with-mcrypt' '--enable-shmop' '--enable-sysvshm' '--enable-sysvsem' '--enable-mbstring' '--with-gd' '--with-png-dir=/usr' '--with-jpeg-dir=/usr' '--enable-mbstring' '--with-curl=/usr/local' '--enable-exif' Server API Apache Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib/php.ini PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 Debug Build no Thread Safety disabled Registered PHP Streams php, http, ftp, https, ftps, compress.zlib [2003-05-24 01:15:44] brian dot diekelman at andrews dot af dot mil I just upgraded from snaps.php.net yesterday and am still experiencing this bug. I am running a very simple authentication script at the beginning of every page to check a generic $_SESSION['user'] to see if there is an active session. If there is not it prompts for login. The session only holds the user name and password. Now I have heard a lot of people in my organization complaining that they'll be browsing the site and it will randomly prompt for login. I have also experienced this myself. I have heard a couple people in this bug thread attribute losing the session to php's handing of arrays, which very well may be true but in my case I am losing sessions on a lot more basic level. System: -- Win2K SP2 Apache 2.0.45 PHP 4.3.x (downloaded from snaps yesterday) [2003-05-21 08:30:40] stefandekonink at xs4all dot nl Currently I have the same session problem. As the page in a frameset get a POST (login user/pass) the page gets the content. The next page presented in this frame is to fill in content, after posting, it goes again thru the login procedure. After the login the SessionID is lost even if a GET var is specified. This behavior occurs on IE6.0.2600 Win2K-SP2, Mozilla Firebird is working without this annoing behavior. [2003-05-18 11:14:43] dave at flitsservice dot nl I would like to report that I resolved my problem described earlier here. There is a bug in Windows 2000 and is resolved bij one of the available service packs (I thought service pack 3). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20449 -- Edit this bug report at http://bugs.php.net/?id=20449edit=1
#24094 [Fbk-Opn]: Strange segmentation fault
ID: 24094 User updated by: francesco dot laurita at fastweb dot it Reported By: francesco dot laurita at fastweb dot it -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: Linux 2.4.20 PHP Version: 4.3.2 New Comment: It seem work fine with last cvs. Same configuration lines Previous Comments: [2003-06-09 08:38:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-06-09 08:06:58] francesco dot laurita at fastweb dot it The php binary/CLI got segmentation fault at startup. I'm not shure it is a oci8 related but i hope to get it by gdb. This is my steps: [EMAIL PROTECTED] www]$ /usr/local/phpTEST/bin/php -v Segmentation fault (core dumped) [EMAIL PROTECTED] www]$ gdb /usr/local/phpTEST/bin/php GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run Starting program: /usr/local/phpTEST/bin/php [New Thread 1024 (LWP 9768)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 9768)] 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 (gdb) quit The program is running. Exit anyway? (y or n) y [EMAIL PROTECTED] www]$ gdb /usr/local/phpTEST/bin/php core.9766 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... Core was generated by `/usr/local/phpTEST/bin/php -v'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libsablot.so.0...done. Loaded symbols for /usr/lib/libsablot.so.0 Reading symbols from /usr/lib/libexpat.so.0...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /usr/local/freetds/lib/libct.so.1...done. Loaded symbols for /usr/local/freetds/lib/libct.so.1 Reading symbols from /usr/lib/libpng.so.2...done. Loaded symbols for /usr/lib/libpng.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0...done. Loaded symbols for /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /opt/oracle/product/9.0.1/lib/libwtc9.so...done. Loaded symbols for /opt/oracle/product/9.0.1/lib/libwtc9.so Reading symbols from /lib/i686/libpthread.so.0...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 (gdb) bt #0 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #1 0x407a4a67 in skgmidrealm () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #2 0x407a4571 in skgmlocate () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #3 0x407a3f6d in skgmcrone () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #4 0x407a7a2c in skgmcrmany () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #5 0x407a1e7b in skgmcreate () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #6 0x403c8e0d in kgupmcreate_sga () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #7 0x403c64e4 in kgup_startup () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #8 0x4033ec27 in kpushInit () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #9 0x407aee77 in kpummpin () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #10 0x4033ef69 in kpupin () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #11 0x40390f4c in OCIInitialize () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0
#23671 [Opn-Csd]: Function calls expose private (and undefined) functions in print_r output
ID: 23671
Updated by: [EMAIL PROTECTED]
Reported By: agoossens at olc dot sa dot edu dot au
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Windows XP, SP1
PHP Version: 5CVS-2003-05-17 (dev)
New Comment:
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.
Previous Comments:
[2003-05-17 09:27:41] agoossens at olc dot sa dot edu dot au
Update: I discovered that the reason the private functions are being
exposed is because functions do not need to be defined to be added to
the output. They simply need to be called at least once anywhere in a
class.
class foo
{
public function sayFoo()
{
$this-doSomeFoo();
}
}
$foo = new foo;
The print_r() output on this will still give
foo Object {
[doSomeFoo]=
}
Strangely, it seems that here sayFoo() will not appear in the output,
even though it's scope is public!
[2003-05-17 08:59:29] agoossens at olc dot sa dot edu dot au
Greetings all,
When a private function is called from within a class, it is exposed in
the print_r() (or var_dump()) output on it's object.
In order to explain this, consider this code:
class foo
{
private function sayFoo()
{
/* uncomment this line */
//$this-doSomeFoo();
}
private function doSomeFoo()
{
echo Doing some foo\n;
}
}
$foo = new foo;
// print the structure of $foo
print_r($foo);
// var_dump($foo);
Initially, this will return
foo Object
(
)
Which is correct.
However, if you then uncomment the line in sayFoo, the print_r will
return the name of the private function as one of the array indexes.
Changing the scope of sayFoo does the same thing no matter what scope
you use.
I'm pretty sure this isn't expected behaviour, as that would expose the
private function's existance (even though they still can't be
accessed).
Tested on:
PHP 5.0.0-dev, 200305061830 build, Win32 package.
Cheers
-Adam Goossens
--
Edit this bug report at http://bugs.php.net/?id=23671edit=1
#24095 [NEW]: phpinfo styles override page styles and damage appearance
From: generic at thetahat dot com Operating system: Windows XP SP1 PHP version: 4.3.2 PHP Bug Type: Feature/Change Request Bug description: phpinfo styles override page styles and damage appearance I'm all for using styles on the phpinfo output but since it's redefining basic page elements it's difficult to include phpinfo output on a page when debugging. The choice of style names are all that need to change. For instance, instead of redefining table, use a class name like #phpinfotable and instead of a basic names like .e use .phpinfocell, instead of h1 use h1.phpinfo, a:link#phpinfo, etc. -- Edit bug report at http://bugs.php.net/?id=24095edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24095r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24095r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24095r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24095r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24095r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24095r=support Expected behavior: http://bugs.php.net/fix.php?id=24095r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24095r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24095r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24095r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24095r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24095r=dst IIS Stability: http://bugs.php.net/fix.php?id=24095r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24095r=gnused
#24083 [Fbk-Opn]: Content-Encoding: gzip output includes the wrong Content-Length header
ID: 24083 User updated by: yngve at opera dot com Reported By: yngve at opera dot com -Status: Feedback +Status: Open Bug Type:Zlib Related PHP Version: 4.3.1 New Comment: I do not know if this is present in 4.3.2 as I am not using PHP myself, but I do know that the problem is present on servers using PHP 4.2.2 and 4.3.1, and your changelog does not indicate many changes related to compression, and none that I can see are related to this problem. Previous Comments: [2003-06-09 08:30:01] [EMAIL PROTECTED] Does this happen with PHP 4.3.2 ? [2003-06-08 15:24:24] yngve at opera dot com I am a developer with Opera Software, the developer of the Opera browser. We have received several reports about problems with forums using VBulletin, but based on what I've learned I suspect that the problem is a general PHP problem, not Vbulletin specific. The reason for the problem turns out to be the same, or of a similar nature, as my earlier bug report #12884. A while ago I was in contact with one of the boards affected by the problem Rage3D.com. They reported back that they were able to solve the problem by turning off global compression From the Rage3D people (with permission): The problem was caused because we were running the php output_handler = ob_gzhandler for global site compression. vB didn't know to use the right content length header. We've resolved the issue by turning off global compression and enabling gzip encoding through vBulletin. We will be seeing if an updated gzip library for our server will resolve the issue so we can run global php compression in the future. The following is a hexdump of the request and response headers from one of my tests (before Rage3D fixed the problem). --- : 47 45 54 20 2f 62 6f 61 72 64 2f 20 48 54 54 50 GET /board/ HTTP 0010 : 2f 31 2e 31 0d 0a 55 73 65 72 2d 41 67 65 6e 74 /1.1..User-Agent 0020 : 3a 20 4d 6f 7a 69 6c 6c 61 2f 34 2e 30 20 28 63 : Mozilla/4.0 (c 0030 : 6f 6d 70 61 74 69 62 6c 65 3b 20 4d 53 49 45 20 ompatible; MSIE 0040 : 36 2e 30 3b 20 57 69 6e 64 6f 77 73 20 4e 54 20 6.0; Windows NT 0050 : 35 2e 30 29 20 4f 70 65 72 61 20 37 2e 31 31 20 5.0) Opera 7.11 0060 : 20 5b 65 6e 5d 0d 0a 48 6f 73 74 3a 20 77 77 77 [en]..Host: www 0070 : 2e 72 61 67 65 33 64 2e 63 6f 6d 0d 0a 41 63 63 .rage3d.com..Acc 0080 : 65 70 74 3a 20 74 65 78 74 2f 68 74 6d 6c 2c 20 ept: text/html, 0090 : 69 6d 61 67 65 2f 70 6e 67 2c 20 69 6d 61 67 65 image/png, image 00a0 : 2f 6a 70 65 67 2c 20 69 6d 61 67 65 2f 67 69 66 /jpeg, image/gif 00b0 : 2c 20 69 6d 61 67 65 2f 78 2d 78 62 69 74 6d 61 , image/x-xbitma 00c0 : 70 2c 20 2a 2f 2a 3b 71 3d 30 2e 31 0d 0a 41 63 p, */*;q=0.1..Ac 00d0 : 63 65 70 74 2d 4c 61 6e 67 75 61 67 65 3a 20 65 cept-Language: e 00e0 : 6e 3b 71 3d 31 2e 30 2c 65 6e 3b 71 3d 30 2e 39 n;q=1.0,en;q=0.9 00f0 : 0d 0a 41 63 63 65 70 74 2d 43 68 61 72 73 65 74 ..Accept-Charset 0100 : 3a 20 77 69 6e 64 6f 77 73 2d 31 32 35 32 2c 20 : windows-1252, 0110 : 75 74 66 2d 38 2c 20 75 74 66 2d 31 36 2c 20 69 utf-8, utf-16, i 0120 : 73 6f 2d 38 38 35 39 2d 31 3b 71 3d 30 2e 36 2c so-8859-1;q=0.6, 0130 : 20 2a 3b 71 3d 30 2e 31 0d 0a 41 63 63 65 70 74 *;q=0.1..Accept 0140 : 2d 45 6e 63 6f 64 69 6e 67 3a 20 64 65 66 6c 61 -Encoding: defla 0150 : 74 65 2c 20 67 7a 69 70 2c 20 78 2d 67 7a 69 70 te, gzip, x-gzip 0160 : 2c 20 69 64 65 6e 74 69 74 79 2c 20 2a 3b 71 3d , identity, *;q= 0170 : 30 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 4b 0..Connection: K 0180 : 65 65 70 2d 41 6c 69 76 65 0d 0a 0d 0aeep-Alive : 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK. 0010 : 0a 53 65 72 76 65 72 3a 20 4d 69 63 72 6f 73 6f .Server: Microso 0020 : 66 74 2d 49 49 53 2f 35 2e 30 0d 0a 44 61 74 65 ft-IIS/5.0..Date 0030 : 3a 20 54 68 75 2c 20 30 38 20 4d 61 79 20 32 30 : Thu, 08 May 20 0040 : 30 33 20 30 32 3a 32 30 3a 30 33 20 47 4d 54 0d 03 02:20:03 GMT. 0050 : 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f .Connection: clo 0060 : 73 65 0d 0a 58 2d 50 6f 77 65 72 65 64 2d 42 79 se..X-Powered-By 0070 : 3a 20 50 48 50 2f 34 2e 33 2e 31 0d 0a 43 6f 6e : PHP/4.3.1..Con 0080 : 74 65 6e 74 2d 74 79 70 65 3a 20 74 65 78 74 2f tent-type: text/ 0090 : 68 74 6d 6c 0d 0a 53 65 74 2d 43 6f 6f 6b 69 65 html..Set-Cookie 00a0 : 3a 20 73 65 73 73 69 6f 6e 68 61 73 68 3d 38 65 : sessionhash=8e 00b0 : 33 32 32 36 63 30 33 32 34 31 31 32 32 66 33 30 3226c03241122f30 00c0 : 31 38 64 64 33 64 64 62 38 61 38 63 37 61 3b 20 18dd3ddb8a8c7a; 00d0 : 70 61 74 68 3d 2f 0d 0a 53 65 74 2d 43 6f 6f 6b path=/..Set-Cook 00e0 : 69 65 3a 20 62 62 6c 61 73 74 76 69 73 69 74 3d ie: bblastvisit= 00f0 : 31 30 35 32 33 36 30 34 30 33 3b 20 65 78 70 69 1052360403; expi 0100 :
#24092 [Bgs]: ncurses panel
ID: 24092
User updated by: garrote at dm dot com dot br
Reported By: garrote at dm dot com dot br
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: linux 2.4.20
PHP Version: 4CVS-2003-06-09 (stable)
New Comment:
i´m sory i don´t send this function in example...plese add the
coment in those line
// } else
//ncurses_wbkgdsett($win, NCURSES_A_BOLD | ' ');
but the problem persist whithout this function.
Previous Comments:
[2003-06-09 08:41:25] [EMAIL PROTECTED]
Fatal error: Call to undefined function: ncurses_wbkgdset()
Try provide a script that has even remote possibility on
working..or at least a GDB backtrace.
[2003-06-09 07:33:07] garrote at dm dot com dot br
Good morning,
there is a problem with ncurses_panel_window. if you create more than
one panel it doesn´t sets the recurse correctly and return segment
fault. i have to use array to storage the information of window and
panel.
one think...we use function to retrieve the information...but i don´t
think that it´s the problem.
function nova_janela($nr_linhas, $nr_colunas, $linha, $coluna, $cor)
{
global $WINDOW;
$win = ncurses_newwin($nr_linhas, $nr_colunas, $linha,
$coluna);
if(!$win) // temos uma window
return false;
$janela = ncurses_new_panel($win);
if(!$janela) // temos uma janela
return false;
$WINDOW[$janela] = $win; // coloca na memoria o recurso
if(ncurses_has_colors() and $cor) { // temos cor no terminal
$fg = ($cor == NCURSES_COLOR_BLUE) ?
NCURSES_COLOR_WHITE : NCURSES_COLOR_BLACK;
$bg = $cor;
ncurses_init_pair($cor, $fg, $bg);
ncurses_wattron($win, (color_pair($cor) | ' '));
} else
ncurses_wbkgdsett($win, NCURSES_A_BOLD | ' ');
ncurses_wborder($win, 0,0,0,0,0,0,0,0);
$l = 1;
while($l $nr_linhas - 1) {
$c = 1;
ncurses_wmove($win, $l, 1);
while($c++ $nr_colunas - 1) {
ncurses_waddch($win, 32);
//ncurses_update_panels(); //oops
ncurses_wrefresh($win); //oops
}
$l++;
}
ncurses_update_panels();
ncurses_doupdate();
return $janela;
}
function remove_janela($janela)
{
global $WINDOW;
if(!$janela) // temos uma janela
return false;
//$win = ncurses_panel_window($janela); // error Segment fault
$win = $WINDOW[$janela]; // recupera recurso
if(!$win) // temos uma window
return false;
ncurses_del_panel($janela); // libera janela
ncurses_delwin($win); // libera window
ncurses_update_panels();
ncurses_doupdate();
return true;
}
$WINDOW=ARRAY();
ncurses_init();
if(ncurses_has_colors())
ncurses_start_color();
$i=0;
while($i 5) {
$a[$i] = nova_janela(10 + ($i * 2), 20 + ($i * 5), 10 + $i, 10
+ $i,$i + 1);
$i++;
}
$i=0;
while($i 5) {
remove_janela($a[$i]);
$i++;
}
ncurses_end();
exit;
PHP 4.3.3-dev (cgi) (built: Jun 6 2003 19:30:49)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
[PHP Modules]
ctype
mysql
ncurses
overload
pcre
posix
session
standard
tokenizer
xml
[Zend Modules]
--
Edit this bug report at http://bugs.php.net/?id=24092edit=1
#22937 [Fbk-Opn]: Valid http:// URL does not open with fopen()
ID: 22937
User updated by: freddie at bingham dot net
Reported By: freddie at bingham dot net
-Status: Feedback
+Status: Open
Bug Type: Sockets related
Operating System: Redhat 7.3
PHP Version: 4.3.2
New Comment:
Can we please stick to the bug that I have reported. Thanks.
My script works in everything before 4.3.0. What had changed to break a
valid URL from being opened with fopen() and why was I told it was
fixed in the PRE released 4.3.2, to only find it is still broken in
4.3.2
Previous Comments:
[2003-06-09 03:17:27] [EMAIL PROTECTED]
dunkel at calamus dot net:
fopen will raise a warning if it could not open the file. That is how
it works. To hide the warning, use the @ operator.
freddie at bingham dot net:
please try this little script:
$p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
and paste the result here
[2003-06-09 01:29:22] dunkel at calamus dot net
In my problem case, the remote file does NOT exist. This is what I want
to find out with fopen(). The according code looks like this:
// don't check remote files with file_exists() !!!
if ($lan == cz)
{
$file = fopen($url_docu, rb);
if ($file)
{
echo blockquote\n;
echo a href=\$url_docu\ class=\h4\;
$this-echo_name($lan);
echo (HTML)/a\n;
echo /blockquote\n;
fclose($file);
}
else
[...]
}
In fact, $file is invalid here as it should. But in no case this
function call of fopen() should give a warning about this, shouldn't
it?
In http://www.calamus.net/cz/modules/aln.php, you see how it works with
existing remote files.
In http://www.calamus.net/us/modules/aln.php, you can see how the
result should be (refer to 'Manual' instead of the Czech 'Prirucka').
[2003-06-08 20:15:31] freddie at bingham dot net
It very well does exist. Perhaps you just clicked on the url as
presented on this page which adds a ', to the end.
[2003-06-08 19:33:23] [EMAIL PROTECTED]
Why shouldn't it give that error? The first url in your
script does not exist.
[2003-06-08 11:18:35] dunkel at calamus dot net
For me, a similar problem exists in PHP 4.1.2 (on Apache):
Take a look at http://www.calamus.net/cz/modules/wmf.php, please.
In the paragraph P#345;íru#269;ka: (Documentation:) I want to
fopen() a page on a Czech server. As this page does not exist, a
visible warning is been returned which should probably NOT occur here.
Instead, I expect the function call to ONLY give back an invalid $fp.
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/22937
--
Edit this bug report at http://bugs.php.net/?id=22937edit=1
#22937 [Opn-Fbk]: Valid http:// URL does not open with fopen()
ID: 22937
Updated by: [EMAIL PROTECTED]
Reported By: freddie at bingham dot net
-Status: Open
+Status: Feedback
Bug Type: Sockets related
Operating System: Redhat 7.3
PHP Version: 4.3.2
New Comment:
*sigh*
Please provide the information I requested.
?php
$p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
?
and paste the result here.
Previous Comments:
[2003-06-09 09:19:19] freddie at bingham dot net
Can we please stick to the bug that I have reported. Thanks.
My script works in everything before 4.3.0. What had changed to break a
valid URL from being opened with fopen() and why was I told it was
fixed in the PRE released 4.3.2, to only find it is still broken in
4.3.2
[2003-06-09 03:17:27] [EMAIL PROTECTED]
dunkel at calamus dot net:
fopen will raise a warning if it could not open the file. That is how
it works. To hide the warning, use the @ operator.
freddie at bingham dot net:
please try this little script:
$p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
and paste the result here
[2003-06-09 01:29:22] dunkel at calamus dot net
In my problem case, the remote file does NOT exist. This is what I want
to find out with fopen(). The according code looks like this:
// don't check remote files with file_exists() !!!
if ($lan == cz)
{
$file = fopen($url_docu, rb);
if ($file)
{
echo blockquote\n;
echo a href=\$url_docu\ class=\h4\;
$this-echo_name($lan);
echo (HTML)/a\n;
echo /blockquote\n;
fclose($file);
}
else
[...]
}
In fact, $file is invalid here as it should. But in no case this
function call of fopen() should give a warning about this, shouldn't
it?
In http://www.calamus.net/cz/modules/aln.php, you see how it works with
existing remote files.
In http://www.calamus.net/us/modules/aln.php, you can see how the
result should be (refer to 'Manual' instead of the Czech 'Prirucka').
[2003-06-08 20:15:31] freddie at bingham dot net
It very well does exist. Perhaps you just clicked on the url as
presented on this page which adds a ', to the end.
[2003-06-08 19:33:23] [EMAIL PROTECTED]
Why shouldn't it give that error? The first url in your
script does not exist.
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/22937
--
Edit this bug report at http://bugs.php.net/?id=22937edit=1
#24096 [NEW]: session_regenerate_id not delete the old session file
From: pablo_sole at myp dot net dot ar Operating system: linux rh8 apache 1.3.27 PHP version: 4.3.2 PHP Bug Type: Session related Bug description: session_regenerate_id not delete the old session file testing the new session_regenerate_id i see that after upgrade de SID, not unlink the old session file so, when you regenerate many times the session could be used to make a DoS, or at least is not what it's expected from the function. Checking the source code, the routine free the SID and assign the new, but not unlink the old file (just like in the php_session_destroy routine). A workaround could be unlink manualy on the fly, or patch the session.c file. Sorry my poor english, but is not my native language. Any question, mail me. pablo. PD: I not have any specific setup or extra modules compiled in, and for that reason i don't put it here. -- Edit bug report at http://bugs.php.net/?id=24096edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24096r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24096r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24096r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24096r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24096r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24096r=support Expected behavior: http://bugs.php.net/fix.php?id=24096r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24096r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24096r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24096r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24096r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24096r=dst IIS Stability: http://bugs.php.net/fix.php?id=24096r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24096r=gnused
#24094 [Opn-Csd]: Strange segmentation fault
ID: 24094 Updated by: [EMAIL PROTECTED] Reported By: francesco dot laurita at fastweb dot it -Status: Open +Status: Closed Bug Type: OCI8 related Operating System: Linux 2.4.20 PHP Version: 4.3.2 New Comment: Great, closing then. Previous Comments: [2003-06-09 08:51:04] francesco dot laurita at fastweb dot it It seem work fine with last cvs. Same configuration lines [2003-06-09 08:38:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-06-09 08:06:58] francesco dot laurita at fastweb dot it The php binary/CLI got segmentation fault at startup. I'm not shure it is a oci8 related but i hope to get it by gdb. This is my steps: [EMAIL PROTECTED] www]$ /usr/local/phpTEST/bin/php -v Segmentation fault (core dumped) [EMAIL PROTECTED] www]$ gdb /usr/local/phpTEST/bin/php GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run Starting program: /usr/local/phpTEST/bin/php [New Thread 1024 (LWP 9768)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 9768)] 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 (gdb) quit The program is running. Exit anyway? (y or n) y [EMAIL PROTECTED] www]$ gdb /usr/local/phpTEST/bin/php core.9766 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... Core was generated by `/usr/local/phpTEST/bin/php -v'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libsablot.so.0...done. Loaded symbols for /usr/lib/libsablot.so.0 Reading symbols from /usr/lib/libexpat.so.0...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /usr/local/freetds/lib/libct.so.1...done. Loaded symbols for /usr/local/freetds/lib/libct.so.1 Reading symbols from /usr/lib/libpng.so.2...done. Loaded symbols for /usr/lib/libpng.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0...done. Loaded symbols for /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /opt/oracle/product/9.0.1/lib/libwtc9.so...done. Loaded symbols for /opt/oracle/product/9.0.1/lib/libwtc9.so Reading symbols from /lib/i686/libpthread.so.0...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 (gdb) bt #0 0x407a92a2 in sskgmstat () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #1 0x407a4a67 in skgmidrealm () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #2 0x407a4571 in skgmlocate () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #3 0x407a3f6d in skgmcrone () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #4 0x407a7a2c in skgmcrmany () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #5 0x407a1e7b in skgmcreate () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #6 0x403c8e0d in kgupmcreate_sga () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #7 0x403c64e4 in kgup_startup () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #8 0x4033ec27 in kpushInit () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #9 0x407aee77 in kpummpin () from /opt/oracle/product/9.0.1/lib/libclntsh.so.9.0 #10 0x4033ef69 in kpupin () from
#22937 [Fbk-Opn]: Valid http:// URL does not open with fopen()
ID: 22937
User updated by: freddie at bingham dot net
Reported By: freddie at bingham dot net
-Status: Feedback
+Status: Open
Bug Type: Sockets related
Operating System: Redhat 7.3
PHP Version: 4.3.2
New Comment:
NULL
The fact that you are asking me this implies that it works for you on
4.3.2 or you are unable to test it on 4.3.2. Is that the case?
Previous Comments:
[2003-06-09 09:41:10] [EMAIL PROTECTED]
*sigh*
Please provide the information I requested.
?php
$p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
?
and paste the result here.
[2003-06-09 09:19:19] freddie at bingham dot net
Can we please stick to the bug that I have reported. Thanks.
My script works in everything before 4.3.0. What had changed to break a
valid URL from being opened with fopen() and why was I told it was
fixed in the PRE released 4.3.2, to only find it is still broken in
4.3.2
[2003-06-09 03:17:27] [EMAIL PROTECTED]
dunkel at calamus dot net:
fopen will raise a warning if it could not open the file. That is how
it works. To hide the warning, use the @ operator.
freddie at bingham dot net:
please try this little script:
$p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
and paste the result here
[2003-06-09 01:29:22] dunkel at calamus dot net
In my problem case, the remote file does NOT exist. This is what I want
to find out with fopen(). The according code looks like this:
// don't check remote files with file_exists() !!!
if ($lan == cz)
{
$file = fopen($url_docu, rb);
if ($file)
{
echo blockquote\n;
echo a href=\$url_docu\ class=\h4\;
$this-echo_name($lan);
echo (HTML)/a\n;
echo /blockquote\n;
fclose($file);
}
else
[...]
}
In fact, $file is invalid here as it should. But in no case this
function call of fopen() should give a warning about this, shouldn't
it?
In http://www.calamus.net/cz/modules/aln.php, you see how it works with
existing remote files.
In http://www.calamus.net/us/modules/aln.php, you can see how the
result should be (refer to 'Manual' instead of the Czech 'Prirucka').
[2003-06-08 20:15:31] freddie at bingham dot net
It very well does exist. Perhaps you just clicked on the url as
presented on this page which adds a ', to the end.
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/22937
--
Edit this bug report at http://bugs.php.net/?id=22937edit=1
#24097 [NEW]: ibase_rollback warning message
From: benji at autec dot es Operating system: Windows XP Professional PHP version: 4.3.2 PHP Bug Type: InterBase related Bug description: ibase_rollback warning message When you do a: ibase_rollback( $connection, $trans); both parameters being correct. This function returns a warning message claiming wrong parameter count. but works fine anyway. Also if you call: ibase_rollback( $trans); Function does not give any error message. The documentation says: int ibase_rollback ( [int link_identifier, int trans_number] ) May be it is an error of the documetation... Thank you php team, Ben -- Edit bug report at http://bugs.php.net/?id=24097edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24097r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24097r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24097r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24097r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24097r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24097r=support Expected behavior: http://bugs.php.net/fix.php?id=24097r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24097r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24097r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24097r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24097r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24097r=dst IIS Stability: http://bugs.php.net/fix.php?id=24097r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24097r=gnused
#24098 [NEW]: pathinfo crashes
From: spotter at mail dot ee Operating system: Suse 8.2 PHP version: 5CVS-2003-06-09 (dev) PHP Bug Type: Reproducible crash Bug description: pathinfo crashes Function pathinfo() crashes on simple call. For example ? pathinfo(/dsds.asa) ? gives segfault. Following little fix wont crash anymore: # diff ext/standard/string.c.old ext/standard/string.c 1271d1270 int ret_len; And a backtrace: Starting program: /root/php5/sapi/cli/php /data/docroot/test.php Program received signal SIGSEGV, Segmentation fault. 0x4016fb74 in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x4016fb74 in memcpy () from /lib/libc.so.6 #1 0x40014020 in __libc_missing_32bit_uids () from /lib/ld-linux.so.2 #2 0x081594ce in add_assoc_stringl_ex (arg=0x8228a24, key=0x818672e extension, key_len=10, str=0x8228a81 asa, length=136541059, duplicate=1) at /root/php5old/Zend/zend_API.c:763 #3 0x080f09c4 in zif_pathinfo (ht=1, return_value=0x8228a04, this_ptr=0x0, return_value_used=1) at /root/php5old/ext/standard/string.c:1283 #4 0x0816c2f0 in zend_do_fcall_common_helper (execute_data=0xbfffc580, op_array=0x82331fc) at /root/php5old/Zend/zend_execute.c:2596 #5 0x0816c83f in zend_do_fcall_handler (execute_data=0xbfffc580, op_array=0x82331fc) at /root/php5old/Zend/zend_execute.c:2724 #6 0x08168594 in execute (op_array=0x82331fc) at /root/php5old/Zend/zend_execute.c:1244 #7 0x08157c2a in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php5old/Zend/zend.c:1017 #8 0x08124ad9 in php_execute_script (primary_file=0xbfffe980) at /root/php5old/main/main.c:1678 #9 0x08172caa in main (argc=2, argv=0xbfffea14) at /root/php5old/sapi/cli/php_cli.c:909 #10 0x401078ae in __libc_start_main () from /lib/libc.so.6 test.php is: ? print_r(pathinfo(/dsds.asa)); ? -- Edit bug report at http://bugs.php.net/?id=24098edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24098r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24098r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24098r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24098r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24098r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24098r=support Expected behavior: http://bugs.php.net/fix.php?id=24098r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24098r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24098r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24098r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24098r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24098r=dst IIS Stability: http://bugs.php.net/fix.php?id=24098r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24098r=gnused
#24099 [NEW]: large objects broken
From: gurov at f3h dot com Operating system: linux 2.2.16-22 PHP version: 4.3.2 PHP Bug Type: PostgreSQL related Bug description: large objects broken it seems that after upgrading to 4.3.2stable from 4.3.2RC1 large objects refuse to work, tried with both 7.3.2 and 7.3.3 postgres downgrading to 4.3.2RC1 seemed to fix it for now -- Edit bug report at http://bugs.php.net/?id=24099edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24099r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24099r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24099r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24099r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24099r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24099r=support Expected behavior: http://bugs.php.net/fix.php?id=24099r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24099r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24099r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24099r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24099r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24099r=dst IIS Stability: http://bugs.php.net/fix.php?id=24099r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24099r=gnused
#24099 [Opn-Fbk]: large objects broken
ID: 24099 Updated by: [EMAIL PROTECTED] Reported By: gurov at f3h dot com -Status: Open +Status: Feedback Bug Type: PostgreSQL related Operating System: linux 2.2.16-22 PHP Version: 4.3.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2003-06-09 11:15:46] gurov at f3h dot com it seems that after upgrading to 4.3.2stable from 4.3.2RC1 large objects refuse to work, tried with both 7.3.2 and 7.3.3 postgres downgrading to 4.3.2RC1 seemed to fix it for now -- Edit this bug report at http://bugs.php.net/?id=24099edit=1
#24043 [Bgs]: include()/require() not working properly with absolute URL
ID: 24043 User updated by: delmatto at genotec dot ch Reported By: delmatto at genotec dot ch Status: Bogus Bug Type: Scripting Engine problem Operating System: Debian GNU/Linux 3.0 / stable PHP Version: 4.3.2 New Comment: Well, actually not the answer I expected ;-) Since I really *need* to fix this, I'd appreciate some thoughts on how to find the source of this problem. If you say, it ain't a bug in PHP, then it's propably a local configuration issue (php.ini/apache.conf/etc) or a compiling issue (compiler version/libc/dev headers). what do you think about that? any ideas? Previous Comments: [2003-06-09 08:15:58] [EMAIL PROTECTED] Both scripts work just fine. No bug. [2003-06-07 05:03:32] delmatto at genotec dot ch I am Sorry, I understood you wantet a working link to see the scripts in action... This is the code of the two test files I use: ---begin test.php--- ?PHP include(http://gic-web-lin-01.genotec.ch/php/gd/index.php;); ? ---end--- ---begin test2.php--- ?PHP include(http://support.genotec.ch/main.asp;); ? ---end--- [2003-06-07 04:52:43] [EMAIL PROTECTED] I asked for a SOURCE of a script that I can run myself. [2003-06-07 02:54:51] delmatto at genotec dot ch use the following for a server running php 4.3.1 (original config) http://212.80.185.102/test.php (- http://212.80.185.102/php/gd/index.php) http://212.80.185.102/test2.php (- http://support.genotec.ch/main.asp) here the error happens, no matter wether I include from the same server or from an external one as in the later case. now these for the server running 4.3.3-dev snapshot http://212.80.185.101/test.php (- http://212.80.185.101/php/gd/index.php) http://212.80.185.101/test2.php (- http://support.genotec.ch/main.asp) here comes a very strange behaviour as it sometimes works without this 'headers' and sometimes the page even stays blank, then I find the following in the error log: [Sat Jun 7 09:34:29 2003] [error] PHP Warning: main(http://gic-web-lin-01.genotec.ch/php/gd/index.php): failed to open stream: HTTP request failed! [EMAIL PROTECTED]@P_P #9227;[EMAIL PROTECTED]@T #9227;#9532; /#9524;#9618;#9148;/#9252;#9228;#9228;/#9252;#9500;#9229;#9146;#9228;#9149;/#9229;#9226;°#9618;#9508;#9484;#9500;/#9500;#9226;#9149;#9500;.#9147;#9252;#9147; #9146;#9532; #9484;#9227;#9532;#9226; 4 to reproduce just try to reload the page a few times. I'm not sure wether this header problem is gone now, though the error shown in the log was only introduced when using the new snapshot. It seems like it would only happen when including from the same server, not from an external one, as I couldn't reproduce it on the second url. PHP4 ist running as mod_php in Apache. There is no mod_php3. CGI is not specifically configured in apache, however I didn't use the '--disable-cgi' switch when building PHP, if anyone happens to rename a .php file to .cgi and adds a #!/usr/bin/php to the top of the file, it would run over cgi/suexec. Normal .php/php3/phtml files run through mod_php. [2003-06-06 18:40:38] [EMAIL PROTECTED] Can you give some example script which definately fails for you everytime? (using some url anybody can access) Do you happen to have also CGI version of PHP configured in your Apache? Or PHP 3 as module? 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/24043 -- Edit this bug report at http://bugs.php.net/?id=24043edit=1
#23951 [Ver-Csd]: Defines not working in inherited classes
ID: 23951
Updated by: [EMAIL PROTECTED]
Reported By: sbecker at justseven dot de
-Status: Verified
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Linux 2.4
PHP Version: 4CVS-2003-06-02 (stable)
New Comment:
Fixed in CVS.
You can apply this patch to make it work for you, or try the next
stable snapshot.
http://www.php.net/~wez/define_inherit.diff
Previous Comments:
[2003-06-04 17:37:54] [EMAIL PROTECTED]
You can't use define()'s as constant scalar initializers; this
behaviour is documented in the manual somewhere.
To initialize the array that way, do it in your object constructor.
[2003-06-02 06:05:39] [EMAIL PROTECTED]
Interesting behavior... I could replicate this and it's definitely a
bug.
[2003-06-02 06:01:29] sbecker at justseven dot de
This bug is in some way the same as reported in #14064.
I got the following code:
?php
define('FOO1', 1);
define('FOO2', 2);
class A {
var $a_var = array(FOO1='foo1_value', FOO2='foo2_value');
}
class B extends A {
var $b_var = 'foo';
}
$a = new A;
$b = new B;
print_r($a);
print_r($b);
?
Class A is doing fine but in Class B the Zend-Engine converts my
constants to strings, is that what you want?
-
Stefan
--
Edit this bug report at http://bugs.php.net/?id=23951edit=1
#24089 [Opn]: Problem creating objects with names from class' fields
ID: 24089
User updated by: bartosz at webcity dot pl
Reported By: bartosz at webcity dot pl
Status: Open
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5CVS-2003-06-09 (dev)
New Comment:
So, why it works with php4, but with php5 doesn't?
Previous Comments:
[2003-06-09 05:12:33] neon at neon-line dot net
It's not a bug.
[2003-06-09 04:28:43] bartosz at webcity dot pl
Look at 'foobar' method in 'foobar' class.
It makes parse error:
$this - obj = new $this - classname;
but it works:
$classname = $this - classname;
$this - obj = new $classname;
in php4
$this - obj = new $this - classname;
works correctly.
It isn't a bug?
[2003-06-09 04:18:28] [EMAIL PROTECTED]
Where is the bug?
[2003-06-09 04:09:37] bartosz at webcity dot pl
Analyse code below, it makes parse error:
?php
class foobar2
{
function foobar2()
{
echo phpversion();
}
}
class foobar
{
var $classname = 'foobar2';
var $obj;
function foobar()
{
// it works:
//
// $classname = $this - classname;
// $this - obj = new $classname;
//
// but it doesn't work:
$this - obj = new $this - classname;
}
}
$obj = new foobar;
?
My configure command:
'./configure' '--with-mysql=/usr' '--with-gd2' '--disable-xml'
'--with-apxs=/usr/sbin/apxs'
--
Edit this bug report at http://bugs.php.net/?id=24089edit=1
#24089 [Com]: Problem creating objects with names from class' fields
ID: 24089
Comment by: neon at neon-line dot net
Reported By: bartosz at webcity dot pl
Status: Open
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5CVS-2003-06-09 (dev)
New Comment:
Oh... I propably wasn't thinking while writing my previous comment.
For me it works with php5-200306091730 and PHP4. Are you sure that you
don't have some kind of typing error etc. in you code...
Previous Comments:
[2003-06-09 12:15:14] bartosz at webcity dot pl
So, why it works with php4, but with php5 doesn't?
[2003-06-09 05:12:33] neon at neon-line dot net
It's not a bug.
[2003-06-09 04:28:43] bartosz at webcity dot pl
Look at 'foobar' method in 'foobar' class.
It makes parse error:
$this - obj = new $this - classname;
but it works:
$classname = $this - classname;
$this - obj = new $classname;
in php4
$this - obj = new $this - classname;
works correctly.
It isn't a bug?
[2003-06-09 04:18:28] [EMAIL PROTECTED]
Where is the bug?
[2003-06-09 04:09:37] bartosz at webcity dot pl
Analyse code below, it makes parse error:
?php
class foobar2
{
function foobar2()
{
echo phpversion();
}
}
class foobar
{
var $classname = 'foobar2';
var $obj;
function foobar()
{
// it works:
//
// $classname = $this - classname;
// $this - obj = new $classname;
//
// but it doesn't work:
$this - obj = new $this - classname;
}
}
$obj = new foobar;
?
My configure command:
'./configure' '--with-mysql=/usr' '--with-gd2' '--disable-xml'
'--with-apxs=/usr/sbin/apxs'
--
Edit this bug report at http://bugs.php.net/?id=24089edit=1
#24098 [Opn-Csd]: pathinfo crashes
ID: 24098 Updated by: [EMAIL PROTECTED] Reported By: spotter at mail dot ee -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: Suse 8.2 PHP Version: 5CVS-2003-06-09 (dev) New Comment: 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. Previous Comments: [2003-06-09 10:57:37] spotter at mail dot ee Function pathinfo() crashes on simple call. For example ? pathinfo(/dsds.asa) ? gives segfault. Following little fix wont crash anymore: # diff ext/standard/string.c.old ext/standard/string.c 1271d1270 int ret_len; And a backtrace: Starting program: /root/php5/sapi/cli/php /data/docroot/test.php Program received signal SIGSEGV, Segmentation fault. 0x4016fb74 in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x4016fb74 in memcpy () from /lib/libc.so.6 #1 0x40014020 in __libc_missing_32bit_uids () from /lib/ld-linux.so.2 #2 0x081594ce in add_assoc_stringl_ex (arg=0x8228a24, key=0x818672e extension, key_len=10, str=0x8228a81 asa, length=136541059, duplicate=1) at /root/php5old/Zend/zend_API.c:763 #3 0x080f09c4 in zif_pathinfo (ht=1, return_value=0x8228a04, this_ptr=0x0, return_value_used=1) at /root/php5old/ext/standard/string.c:1283 #4 0x0816c2f0 in zend_do_fcall_common_helper (execute_data=0xbfffc580, op_array=0x82331fc) at /root/php5old/Zend/zend_execute.c:2596 #5 0x0816c83f in zend_do_fcall_handler (execute_data=0xbfffc580, op_array=0x82331fc) at /root/php5old/Zend/zend_execute.c:2724 #6 0x08168594 in execute (op_array=0x82331fc) at /root/php5old/Zend/zend_execute.c:1244 #7 0x08157c2a in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php5old/Zend/zend.c:1017 #8 0x08124ad9 in php_execute_script (primary_file=0xbfffe980) at /root/php5old/main/main.c:1678 #9 0x08172caa in main (argc=2, argv=0xbfffea14) at /root/php5old/sapi/cli/php_cli.c:909 #10 0x401078ae in __libc_start_main () from /lib/libc.so.6 test.php is: ? print_r(pathinfo(/dsds.asa)); ? -- Edit this bug report at http://bugs.php.net/?id=24098edit=1
#24089 [Opn]: Problem creating objects with names from class' fields
ID: 24089 User updated by: bartosz at webcity dot pl Reported By: bartosz at webcity dot pl Status: Open Bug Type: *General Issues Operating System: Linux PHP Version: 5CVS-2003-06-09 (dev) New Comment: Only notice about parse error, nothing else: Parse error: parse error in /home/bartosz/www/foo.php on line 25 Previous Comments: [2003-06-09 12:47:59] neon at neon-line dot net Oh... I propably wasn't thinking while writing my previous comment. For me it works with php5-200306091730 and PHP4. Are you sure that you don't have some kind of typing error etc. in you code... [2003-06-09 12:15:14] bartosz at webcity dot pl So, why it works with php4, but with php5 doesn't? [2003-06-09 05:12:33] neon at neon-line dot net It's not a bug. [2003-06-09 04:28:43] bartosz at webcity dot pl Look at 'foobar' method in 'foobar' class. It makes parse error: $this - obj = new $this - classname; but it works: $classname = $this - classname; $this - obj = new $classname; in php4 $this - obj = new $this - classname; works correctly. It isn't a bug? [2003-06-09 04:18:28] [EMAIL PROTECTED] Where is the bug? 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/24089 -- Edit this bug report at http://bugs.php.net/?id=24089edit=1
#24100 [Opn-WFx]: Please add endclass, endfunction keywords
ID: 24100
Updated by: [EMAIL PROTECTED]
Reported By: waxmop at sarcastic-horse dot com
-Status: Open
+Status: Wont fix
Bug Type: Feature/Change Request
Operating System: linux
PHP Version: 4.3.2
New Comment:
The endif; stuff is old legacy syntax and is definitely not the
recommended way of doing things. For my part if can be removed for PHP
5... anyway, definitely not something we will add.
Previous Comments:
[2003-06-09 13:21:18] waxmop at sarcastic-horse dot com
I really like this alternative syntax:
?php if($a): ?
h1A is true./h1
?php endif; ?
I thought I was free from using curly brackets {}, until I realized
that I'd still have to define classes and functions in the old style:
?php
class Old
{
var $val;
function Old($num=0)
{
print pCreated an object;
if ($num 0):
print this is mismatched syntax!;
endif;
}
}
?
It seems a little jarring to have to switch back and forth between the
{} and the alternative style in a class definition.
It would be nice to be able to create an object with the alternative
style syntax rather than with curly brackets. It could look a little
like this:
?php
class Noo:
var $val;
function Noo():
print pCreated a noo object;
endfunction;
endclass;
?
Wouldn't that be great? My apologies if this is a redundant
submission. I searched for endclass and endfunction, but couldn't find
them.
--
Edit this bug report at http://bugs.php.net/?id=24100edit=1
#24101 [NEW]: socket_select call is blocking and never returning
From: wzaccone at telcordia dot com
Operating system: Solaris 5.8 / Sparc
PHP version: 4.3.2
PHP Bug Type: Sockets related
Bug description: socket_select call is blocking and never returning
we upgraded our application from php 4.1.2 to 4.3.2 and are testing. and
found the following code no longer works:
if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL) !==
FALSE){
foreach($socketsCopy as $sock){
The socket_select call appears to be never returning with php 4.3.2.. code
worked correctly with 4.1.2.
--
Edit bug report at http://bugs.php.net/?id=24101edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24101r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24101r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24101r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24101r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24101r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24101r=support
Expected behavior: http://bugs.php.net/fix.php?id=24101r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24101r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24101r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24101r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24101r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24101r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24101r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24101r=gnused
#18600 [Com]: Unable to create Java Virtual Machine
ID: 18600
Comment by: jlondon at mcg dot edu
Reported By: nalves at equifax dot com dot br
Status: Open
Bug Type: Java related
Operating System: Windows 2000
PHP Version: 4.2.3
New Comment:
Getting the same bug. Running Win2k Server, IIS 5, php4.2.3,
jsdk1.4.1. I read a while back that running as a CGI would eliminate
the error so I tried that but the performance hit was too much to bear
since I only used java on one page. Did a little more searching and
came up with a little work around. Still not perfect but takes much
longer to crash.
$descriptorspec = array(
0 = array(pipe, r), // stdin is a pipe that the child will
read from
1 = array(pipe, w), // stdout is a pipe that the child will
write to
2 = array(file, /temp/error-output.txt, a), // stderr is a
file to write to
);
$process = proc_open(c:\\php\\cli\\php.exe, $descriptorspec,
$pipes);
if (is_resource($process))
{
// $pipes now looks like this:
// 0 = writeable handle connected to child stdin
// 1 = readable handle connected to child stdout
// Any error output will be appended to /tmp/error-output.txt
$size = fwrite($pipes[0], ? \$Login = new Java('CheckLogin'); echo
\$Login-CheckLogin(' . $username . ', ' . $password . '); ?);
if(!fclose($pipes[0]))
echo There was an error closing the pipe;
$result = fgets($pipes[1], $size + 1);
fclose($pipes[1]);
// It is important that you close any pipes before calling
// proc_close in order to avoid a deadlock
$return_value = proc_close($process);
}
Basically what I do is create a process and send it the lines of code I
would use to create and manipulate the java classes. The process gives
me the output and I close the process. It works pretty well and will
extend the restart interval from everytime the script runs to every
couple of days.
For those out there chasing this bug, my method fails on the
$return_value = proc_close($process); line. Once it fails it will not
work again until IIS is restarted. Until IIS is restarted the process
fails on $result = fgets($pipes[1], $size + 1); line. Hope you get
this one fixed. This could be a really powerful plugin.
-Jake
Previous Comments:
[2003-06-04 21:37:36] jason at ipedo dot com
I meet this problem too.
Why should it recreate JVM?
Since it's module, I think it need only create JVM once.
In linux environment, althoug i don't meet the error, the preformence
is bad when system recreate JVM.
How can i disable recreating the JVM or decrease the frequence of
creating JVM?
[2003-05-27 17:36:44] dave at unicon dot net
Has anything been resolved for this usiong the non-cgi approach?
I have found something I did not see in other comments. It seems that
I get the fatal error after a set amount of seconds. Maybe due to some
time out?
Thanks
[2003-05-24 07:40:55] asifrrana at hotmail dot com
Has anyone found a good (not using cgi-bin) resolution to this problem
yet? I just downloaded the latest release 4.3.2 with JDK1.4.0 on
Windows 2000 and I am still getting the same error Fatal error: Unable
to create Java Virtual Machine
[2003-05-22 04:11:11] Mike at 123456 dot net
Hi everybody,
I experience the problem of the Unable to create Java Virtual
Machine, on a Windows 2000, with easyphp, after some search, my
conclusion is that you couldn't use (for the moment) php as a module in
Apache, you must for that use it in cgi mode (I tried it and it work
fine, and change from module to cgi mode doesn't affect usage of PHP).
My configuration is :
Windows 2000
Apache 2.0.45
J2SDK 1.4.1_02
PHP 4.3.2 RC3
You must install J2SK, Apache, and then php (the tutorial indicate how
to install in cgi mode), you can go to the following adress for
installation (a very good tutorial) :
http://hotwired.lycos.com/webmonkey/00/44/index4a_page8.html?tw=programming
after that just configure you php.ini with the following values :
[Java]
extension=php_java.dll
java.home = C:\j2sdk1.4.1_02\jre\bin
java.library = C:\j2sdk1.4.1_02\jre\bin\server\jvm.dll
java.library.path = C:\php4\extensions
java.class.path = C:\php4\extensions\php_java.jar;C:\MyClasses;
Don't forget to affect the extension_dir value like :
extension_dir=C:\php4\extensions
And now it's work.
[2003-05-16 10:37:30] fj at hilab dot it
I personally have experienced the same problem with the 1.4.0_02 SDK
externally connected to php4.3.1 under Win2K.
I had very frequently the aforementioned 'Unable to create Java Virtual
Machine' error and after a number of tests I
#14254 [Com]: SQLERROR -439
ID: 14254 Comment by: klightse at water dot ca dot gov Reported By: cedric dot boudin at iconmedialab dot com Status: Closed Bug Type: Informix related Operating System: Solaris 8 PHP Version: 4.0.6 New Comment: We are seeing the same bug. We just discovered it, two days before we go into production. Talk about a timing issue Solaris 8 Apache 1.3.26 PHP 4.3.0 Informix 9.3uc3 If anyone knows the solution, please post it. We are going to have to reprogram this site in JSP if we can't fix it. Previous Comments: [2003-04-25 12:44:15] jswinborne at nwc dot edu I am also experiencing this error. It seems to come and go randomly. We are using PHP 4.2.1 with Redhat 9. [2003-02-23 20:32:39] neil dot wilkinson at transport dot nsw dot gov dot au This problem still exists and does indeed occur most often when the database is busy. However, there will always be situations where the database is busy, so increasing performance will only help in some situations. The problem appears to be to do with how PHP responds to the callback functions. I believe that the apache and native ESQL libraries are bug free in this respect because embedded perl, etc (hitting the same database from the same machine using the same ESQL libraries) never has this problem. Is there anyone out there that understands the PHP IFX source code and could fix the callback functionality. Failing that I could have a go if given some assistance. FYI, the server specifics are: Solaris 2.6 Apache 1.3.27 PHP 4.2.3 ESQL 7.24.UC6 Informix 7.30.UC8 Please do not close this bug unless the problem has been solved. Several instances around this bug have been closed by the solution upgrade hardware where there is clearly still an error to be fixed. Regards, Neil Wilkinson -- [2002-07-06 17:35:16] pschmidt at naxs dot net Well, I see this problem every time I run my scripts. We are running: PHP 4.2.1 Apache 1.3.24 ESQL/C Version 9.51 Some of the Informix tables are large. Since I am seeing this consistently, I would really like to see a fix to this problem. My scripts are somewhat complicated. But I can reproduce the problem with a simple script. It contains: --- ?php // create connection $connection = ifx_connect(deleted, deleted, deleted) or die(Couldn't create connection.); // create SQL statement $sql = SELECT f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13, f14 FROM T1 where f1 500; // execute SQL query and get result $sql_result = ifx_query($sql,$connection) or die(Couldn't execute query); // format result in HTML table ifx_htmltbl_result($sql_result,border=1); // free resources and close connection ifx_free_result($sql_result); ifx_close($connection); ? --- To reproduce this, I hit the refresh button on the browser before the page had downloaded. I tried switching it to pconnect and still got SQLCODE=-439 failures. Although the table is big, I think the load was light (I tried this on a Saturday afternoon.) Anyone that has questions, feel free to send them to me at [EMAIL PROTECTED] Best Regards, Paul Schmidt Action Web Creations [2002-05-25 13:15:11] [EMAIL PROTECTED] Your problem seems to be a pure performance issue. Unfortunately these kinds of problems present themselves in a non-deterministic fashion, which makes the symptoms hard or impossible to debug. The cure, however, seems clear: upgrade to PHP 4.2, upgrade the hardware, install Zend Optimizer, buy Zend Cache -- anything to match your server resources with the increased load on your system. Based on your description of the scripts used, PHP 4 alone should bring a huge performance increase. Your client's possible unwillingness to pay for upgrades is quite simply *their problem*. Hang in there, iconites ;-) [2002-05-25 09:13:10] alan dot frostick at iconmedialab dot com Referring to Bug #14254. I can give some background clues which might help in resolving the intermittent SQLCODE=-439 error faster. I support the php scripts for the same server which Cedric supports. We have noted that our client has increased their volume of data and traffic to the site dramatically since their intranet's inception over a year ago. They're still using php3 (we're trying to convince them to pay us to convert their scripts to php4, but presently can't guarantee this would resolve the problem since it's still being reported by others using php4). The effect seen is a refusal to connect to
#23883 [NoF-Opn]: PHP crashes if snmp module loaded
ID: 23883 User updated by: joey at joeysmith dot com Reported By: joey at joeysmith dot com -Status: No Feedback +Status: Open Bug Type: SNMP related Operating System: Debian sarge (testing) PHP Version: 4.3.2 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. That's a faulty assumption. No feedback was provided because I don't see the need to reply to the last comment. 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. Which information was requested? I don't see a request for information, only the implication that if PHP (and PHP alone) is causing crash bugs on a particular distro, that we don't want to try and resolve that. Previous Comments: [2003-06-09 08:43:33] [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-06-02 10:28:06] [EMAIL PROTECTED] Use the sources..not some debian package which is most likely broken anyway. (And no idea how it's configured either) [2003-06-02 08:09:27] joey at joeysmith dot com Using SNMP 5.0.7 (debian testing package libsnmp5-dev) still exhibits the crash. I'll build SNMP as static as well. [2003-06-02 06:38:19] [EMAIL PROTECTED] And/or compile it as static module, NOT shared. [2003-06-02 06:37:40] [EMAIL PROTECTED] It works just fine here with net-snmp-5.0.6 so you really should try it.. 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/23883 -- Edit this bug report at http://bugs.php.net/?id=23883edit=1
#24080 [Fbk-Opn]: fputs uses 100% cpu on broken pipe
ID: 24080
User updated by: info at virtualhost dot nl
Reported By: info at virtualhost dot nl
-Status: Feedback
+Status: Open
Bug Type: URL related
Operating System: Freebsd 4.8
PHP Version: 4.3.2
New Comment:
ok, took some time, but here it is:
Program received signal SIGPIPE, Broken pipe.
0x280ff604 in sendto () from /usr/lib/libc.so.4
#0 0x280ff604 in sendto () from /usr/lib/libc.so.4
#1 0x2812798b in send () from /usr/lib/libc.so.4
#2 0x282b00cb in php_sockop_write (stream=0x809070c, buf=0x815f48c
GET /blalbla HTTP/1.0\n\n, count=23)
at /usr/src/php/php-4.3.2/main/network.c:913
#3 0x282ace63 in _php_stream_write (stream=0x809070c, buf=0x815f48c
GET /blalbla HTTP/1.0\n\n, count=23)
at /usr/src/php/php-4.3.2/main/streams.c:909
#4 0x2824741f in zif_fwrite (ht=2, return_value=0x815d62c,
this_ptr=0x0, return_value_used=0)
at /usr/src/php/php-4.3.2/ext/standard/file.c:1559
#5 0x282dd368 in execute (op_array=0x815e90c) at
/usr/src/php/php-4.3.2/Zend/zend_execute.c:1608
#6 0x282cbada in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php/php-4.3.2/Zend/zend.c:869
#7 0x282a4129 in php_execute_script (primary_file=0xbfbff9c4) at
/usr/src/php/php-4.3.2/main/main.c:1671
#8 0x282e3da2 in apache_php_module_main (r=0x815a034,
display_source_mode=0)
at /usr/src/php/php-4.3.2/sapi/apache/sapi_apache.c:54
#9 0x282e4966 in send_php (r=0x815a034, display_source_mode=0,
filename=0x0)
at /usr/src/php/php-4.3.2/sapi/apache/mod_php4.c:617
#10 0x282e49c6 in send_parsed_php (r=0x815a034) at
/usr/src/php/php-4.3.2/sapi/apache/mod_php4.c:632
#11 0x8051a0c in ap_invoke_handler ()
#12 0x80610e1 in process_request_internal ()
#13 0x8061140 in ap_process_request ()
#14 0x805a62e in child_main ()
#15 0x805a7a0 in make_child ()
#16 0x805a8bd in startup_children ()
#17 0x805adac in standalone_main ()
#18 0x805b493 in main ()
#19 0x804e289 in _start ()
regards,
Jeroen Hofstee
Previous Comments:
[2003-06-08 08:18:19] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
Please interrupt it once it has started eating the CPU and provide a
backtrace.
[2003-06-08 08:06:42] info at virtualhost dot nl
Same problem with version 4.3.2. But cpu usage is divided differenty.
4.3.1 used about 50% users / 50% system now it is 90% user / 10% sytem.
[2003-06-08 07:09:00] [EMAIL PROTECTED]
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to Open.
Again, thank you for your continued support of PHP.
.
[2003-06-08 07:04:17] info at virtualhost dot nl
hello,
When executing the following code, the httpd deamon consumes all cpu
available, which should not happen of course. It's stops when the
timeout of the script is reached and the process is deleted.
?
$sk = fsockopen ('211.6.149.130', 80);
if ($sk) {
fputs ($sk, GET /blalbla HTTP/1.0\n\n);
}
?
btw. When requested with curl it says directly 'broken pipe'.
btw2. Same for fwrite.
regards,
Jeroen
--
Edit this bug report at http://bugs.php.net/?id=24080edit=1
#22937 [Opn-Ver]: Valid http:// URL does not open with fopen()
ID: 22937
Updated by: [EMAIL PROTECTED]
Reported By: freddie at bingham dot net
-Status: Open
+Status: Verified
Bug Type: Sockets related
Operating System: Redhat 7.3
PHP Version: 4.3.2
New Comment:
I'm afraid I can verify this one, both with 4.3.2 and 4.3.3-dev as of
today:
# sapi/cli/php -c php.ini-recommended -r '
$p = fopen(http://pub133.ezboard.com/bonesixthwarriors;, rb);
var_dump($http_response_headers);
'
PHP Warning: fopen(http://pub133.ezboard.com/bonesixthwarriors):
failed to open stream: HTTP request failed! à|ïc in Command
line code on line 2
PHP Notice: Undefined variable: http_response_headers in Command line
code on line 3
NULL
#
Configured only with --enable-debug --disable-mbstring, it's the same
problem, but slightly different junk characters in the error message.
Otherwise these junk characters are always the same (for the same
build).
Previous Comments:
[2003-06-09 10:33:14] freddie at bingham dot net
NULL
The fact that you are asking me this implies that it works for you on
4.3.2 or you are unable to test it on 4.3.2. Is that the case?
[2003-06-09 09:41:10] [EMAIL PROTECTED]
*sigh*
Please provide the information I requested.
?php
$p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
?
and paste the result here.
[2003-06-09 09:19:19] freddie at bingham dot net
Can we please stick to the bug that I have reported. Thanks.
My script works in everything before 4.3.0. What had changed to break a
valid URL from being opened with fopen() and why was I told it was
fixed in the PRE released 4.3.2, to only find it is still broken in
4.3.2
[2003-06-09 03:17:27] [EMAIL PROTECTED]
dunkel at calamus dot net:
fopen will raise a warning if it could not open the file. That is how
it works. To hide the warning, use the @ operator.
freddie at bingham dot net:
please try this little script:
$p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
and paste the result here
[2003-06-09 01:29:22] dunkel at calamus dot net
In my problem case, the remote file does NOT exist. This is what I want
to find out with fopen(). The according code looks like this:
// don't check remote files with file_exists() !!!
if ($lan == cz)
{
$file = fopen($url_docu, rb);
if ($file)
{
echo blockquote\n;
echo a href=\$url_docu\ class=\h4\;
$this-echo_name($lan);
echo (HTML)/a\n;
echo /blockquote\n;
fclose($file);
}
else
[...]
}
In fact, $file is invalid here as it should. But in no case this
function call of fopen() should give a warning about this, shouldn't
it?
In http://www.calamus.net/cz/modules/aln.php, you see how it works with
existing remote files.
In http://www.calamus.net/us/modules/aln.php, you can see how the
result should be (refer to 'Manual' instead of the Czech 'Prirucka').
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/22937
--
Edit this bug report at http://bugs.php.net/?id=22937edit=1
#22937 [Ver-Asn]: Valid http:// URL does not open with fopen()
ID: 22937
Updated by: [EMAIL PROTECTED]
Reported By: freddie at bingham dot net
-Status: Verified
+Status: Assigned
-Bug Type: Sockets related
+Bug Type: HTTP related
Operating System: Redhat 7.3
PHP Version: 4.3.2
-Assigned To:
+Assigned To: wez
New Comment:
It looks like the web server at that address doesn't like the request
headers coming in multiple packets.
Performing a strace on php shows that it is conforming to the HTTP
protocol, but the remote host does not send a response (recv call
returns 0).
To me, this sounds like a bug in the web server (I've never heard of
SmallWebServer; anyone have any info on it?).
I'm working on a write buffer for streams that will act as a workaround
for this problem, but my time is limited, so please be patient.
Previous Comments:
[2003-06-09 16:01:07] [EMAIL PROTECTED]
I'm afraid I can verify this one, both with 4.3.2 and 4.3.3-dev as of
today:
# sapi/cli/php -c php.ini-recommended -r '
$p = fopen(http://pub133.ezboard.com/bonesixthwarriors;, rb);
var_dump($http_response_headers);
'
PHP Warning: fopen(http://pub133.ezboard.com/bonesixthwarriors):
failed to open stream: HTTP request failed! à|ïc in Command
line code on line 2
PHP Notice: Undefined variable: http_response_headers in Command line
code on line 3
NULL
#
Configured only with --enable-debug --disable-mbstring, it's the same
problem, but slightly different junk characters in the error message.
Otherwise these junk characters are always the same (for the same
build).
[2003-06-09 10:33:14] freddie at bingham dot net
NULL
The fact that you are asking me this implies that it works for you on
4.3.2 or you are unable to test it on 4.3.2. Is that the case?
[2003-06-09 09:41:10] [EMAIL PROTECTED]
*sigh*
Please provide the information I requested.
?php
$p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
?
and paste the result here.
[2003-06-09 09:19:19] freddie at bingham dot net
Can we please stick to the bug that I have reported. Thanks.
My script works in everything before 4.3.0. What had changed to break a
valid URL from being opened with fopen() and why was I told it was
fixed in the PRE released 4.3.2, to only find it is still broken in
4.3.2
[2003-06-09 03:17:27] [EMAIL PROTECTED]
dunkel at calamus dot net:
fopen will raise a warning if it could not open the file. That is how
it works. To hide the warning, use the @ operator.
freddie at bingham dot net:
please try this little script:
$p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
and paste the result here
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/22937
--
Edit this bug report at http://bugs.php.net/?id=22937edit=1
#22722 [Com]: make failed with --with-gd
ID: 22722 Comment by: alasdair at alivewww dot com Reported By: libser at manas dot kg Status: Closed Bug Type: GD related Operating System: FreeBSD 4.8-RC PHP Version: 4.3.2RC1 New Comment: I'm having exactly the same problem - except I only have one version of GD installed: psa1# cd /usr/local/lib psa1# ls -al | grep libgd -r--r--r-- 1 root wheel 235664 Feb 26 03:24 libgd.a lrwxr-xr-x 1 root wheel 10 Apr 8 11:12 libgd.so - libgd.so.4 -r--r--r-- 1 root wheel 211044 Feb 26 03:24 libgd.so.4 This is not a bogus or closed bug - a perfectly valid installation of GDLib 2.0.1 is present, and PHP 4.3.1 compiled without problem. GD was installed from the FreeBSD ports collection, and the system is FreeBSD 4.7-RELEASE. If there is any other information that may help find the cause of this bug, please let me know so I can post that information. Previous Comments: [2003-03-17 04:34:17] libser at manas dot kg Hi, Thank you for your response. Yes, both are installed under /usr/local: #cd /usr/local/lib #ls -al | grep libgd -r--r--r-- 1 root wheel 235654 Feb 12 10:03 libgd.a lrwxr-xr-x 1 root wheel 10 Feb 12 10:03 libgd.so - libgd.so.4 -r--r--r-- 1 root wheel 194112 Dec 17 09:54 libgd.so.2 -r--r--r-- 1 root wheel 210980 Feb 12 10:03 libgd.so.4 I just tried using the bundled GD library you mentioned before and it compiles fine. Thank you. [2003-03-15 23:18:37] [EMAIL PROTECTED] You mention 2 different GD versions, where are they installed? Both under /usr/local ? Or other one under /usr/ perhaps? Try using the bundled GD library. (use just '--with-gd') [2003-03-15 01:55:50] libser at manas dot kg Good day, FreeBSD 4.8-RC, Apache 2.0.44, PHP 4.3.2RC1 #pkg_info | grep gd gd-1.8.4_6 A graphics library for fast image creation gd-2.0.1_3 A graphics library for fast creation of images ./configure \ --prefix=/usr/local/php4 \ --with-apxs2=/usr/local/sbin/apxs \ --with-zlib=/usr \ --with-mysql=/usr/local \ --with-gettext=/usr/local \ --with-mm=/usr/local \ --with-imap=../imap \ --with-imap-ssl \ --enable-ftp \ --with-expat=/usr/local \ --with-mcrypt=/usr/local \ --with-mcal=/usr/local \ --with-openssl \ --with-dom=/usr/local \ --with-iconv=/usr/local \ --enable-mime-magic \ --with-xml=/usr/local \ --enable-mbstring \ --with-tsrm-pth \ --with-gd=/usr/local Here is the error message after running `make`: ext/gd/gd.lo: In function `zm_deactivate_gd': /usr/tmp/complete_new/php-4.3.2RC1/ext/gd/gd.c:380: undefined reference to `gdFreeFontCache' *** Error code 1 Stop in /usr/tmp/complete_new/php-4.3.2RC1. PHP 4.3.0 with the same configure options compiles just fine. Thank you. Roman -- Edit this bug report at http://bugs.php.net/?id=22722edit=1
#22722 [Com]: make failed with --with-gd
ID: 22722 Comment by: alasdair at alivewww dot com Reported By: libser at manas dot kg Status: Closed Bug Type: GD related Operating System: FreeBSD 4.8-RC PHP Version: 4.3.2RC1 New Comment: I also forgot to mention that I'm installing PHP with Apache 1.3.27, not version 2.0.44 as the original submitter. Previous Comments: [2003-06-09 16:30:18] alasdair at alivewww dot com I'm having exactly the same problem - except I only have one version of GD installed: psa1# cd /usr/local/lib psa1# ls -al | grep libgd -r--r--r-- 1 root wheel 235664 Feb 26 03:24 libgd.a lrwxr-xr-x 1 root wheel 10 Apr 8 11:12 libgd.so - libgd.so.4 -r--r--r-- 1 root wheel 211044 Feb 26 03:24 libgd.so.4 This is not a bogus or closed bug - a perfectly valid installation of GDLib 2.0.1 is present, and PHP 4.3.1 compiled without problem. GD was installed from the FreeBSD ports collection, and the system is FreeBSD 4.7-RELEASE. If there is any other information that may help find the cause of this bug, please let me know so I can post that information. [2003-03-17 04:34:17] libser at manas dot kg Hi, Thank you for your response. Yes, both are installed under /usr/local: #cd /usr/local/lib #ls -al | grep libgd -r--r--r-- 1 root wheel 235654 Feb 12 10:03 libgd.a lrwxr-xr-x 1 root wheel 10 Feb 12 10:03 libgd.so - libgd.so.4 -r--r--r-- 1 root wheel 194112 Dec 17 09:54 libgd.so.2 -r--r--r-- 1 root wheel 210980 Feb 12 10:03 libgd.so.4 I just tried using the bundled GD library you mentioned before and it compiles fine. Thank you. [2003-03-15 23:18:37] [EMAIL PROTECTED] You mention 2 different GD versions, where are they installed? Both under /usr/local ? Or other one under /usr/ perhaps? Try using the bundled GD library. (use just '--with-gd') [2003-03-15 01:55:50] libser at manas dot kg Good day, FreeBSD 4.8-RC, Apache 2.0.44, PHP 4.3.2RC1 #pkg_info | grep gd gd-1.8.4_6 A graphics library for fast image creation gd-2.0.1_3 A graphics library for fast creation of images ./configure \ --prefix=/usr/local/php4 \ --with-apxs2=/usr/local/sbin/apxs \ --with-zlib=/usr \ --with-mysql=/usr/local \ --with-gettext=/usr/local \ --with-mm=/usr/local \ --with-imap=../imap \ --with-imap-ssl \ --enable-ftp \ --with-expat=/usr/local \ --with-mcrypt=/usr/local \ --with-mcal=/usr/local \ --with-openssl \ --with-dom=/usr/local \ --with-iconv=/usr/local \ --enable-mime-magic \ --with-xml=/usr/local \ --enable-mbstring \ --with-tsrm-pth \ --with-gd=/usr/local Here is the error message after running `make`: ext/gd/gd.lo: In function `zm_deactivate_gd': /usr/tmp/complete_new/php-4.3.2RC1/ext/gd/gd.c:380: undefined reference to `gdFreeFontCache' *** Error code 1 Stop in /usr/tmp/complete_new/php-4.3.2RC1. PHP 4.3.0 with the same configure options compiles just fine. Thank you. Roman -- Edit this bug report at http://bugs.php.net/?id=22722edit=1
#22825 [Com]: undefined reference to `gdFreeFontCache'
ID: 22825 Comment by: alasdair at alivewww dot com Reported By: php-bugs at liwing dot de Status: Bogus Bug Type: GD related Operating System: FreeBSD 5.0 PHP Version: 4.3.2RC1 New Comment: I'm having exactly the same problem. PHP 4.3.2 (the final version not the RC) fails to compile when you ask it to use the installed system version of GDLib. This is not a bogus or closed bug - a perfectly valid installation of GDLib 2.0.1 is present, and PHP 4.3.1 compiles without problem. The system I'm using is FreeBSD 4.7-RELEASE, with Apache 1.3.27. If there is any other information that may help find the cause of this bug, please let me know so I can post it. Previous Comments: [2003-03-22 20:01:56] php-bugs at liwing dot de The error came up when php is build from ports. By the way, php-4.3.1 didn't fail, so there must be changed sth.. Is it real difficult for developers to check what's wrang and correct it? Maybe there is a small error in autoconf which make php to use it's own headers but link against libgd2.so in /usr/local/lib/? I think it's worth to prove to make a fine release :-) I can easily live without gd-support, I just tested it... [2003-03-22 18:32:30] [EMAIL PROTECTED] The common user error of mixing different GD headers with different libs. Not PHP bug. [2003-03-22 14:07:51] [EMAIL PROTECTED] From Boutell's homepage (GD page): If you wish to use gd with PHP, it is probably best to get php 4.3.0 and use the included gd library. [2003-03-22 09:04:35] php-bugs at liwing dot de It's quite easy - having a common gd-library installed (using port) which is used by all dependend applications and having a second one which comes with php. Counting 1 + 1 becomes 2 (decimal system). Clear so long? Jens [2003-03-22 08:21:05] [EMAIL PROTECTED] How can you get two installed version of GD by using the bundled one ? You don't need gd installed to use the bundled gd, that is the point of bundling libs. 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/22825 -- Edit this bug report at http://bugs.php.net/?id=22825edit=1
#24010 [Opn]: Make failure
ID: 24010 User updated by: ronald_zeelenberg at hotmail dot com Reported By: ronald_zeelenberg at hotmail dot com Status: Open Bug Type: Compile Failure Operating System: Red Hat 8 PHP Version: 5CVS-2003-06-04 (dev) New Comment: I can now link again (been able since 4 days ago) saw this in my system log. But pages with PEAR are still crashing. I do not have these problems in version 43x. What is this thing? Previous Comments: [2003-06-09 04:17:13] ronald_zeelenberg at hotmail dot com After setting LogLevel to debug in httpd.conf i found this extra info. [Mon Jun 09 06:12:27 2003] [notice] Apache/2.0.46 (Unix) DAV/2 PHP/5.0.0-dev configured -- resuming normal operations [Mon Jun 09 10:55:58 2003] [notice] child pid 21213 exit signal Segmentation fault (11) [Mon Jun 09 10:55:58 2003] [notice] child pid 21168 exit signal Segmentation fault (11) [Mon Jun 09 10:55:58 2003] [notice] child pid 21167 exit signal Segmentation fault (11) [Mon Jun 09 11:11:25 2003] [notice] caught SIGTERM, shutting down [Mon Jun 09 11:11:25 2003] [notice] Apache/2.0.46 (Unix) DAV/2 PHP/5.0.0-dev configured -- resuming normal oper ations [Mon Jun 09 11:11:25 2003] [info] Server built: Jun 1 2003 13:15:30 [Mon Jun 09 11:11:25 2003] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem) [Mon Jun 09 11:12:13 2003] [notice] child pid 21487 exit signal Segmentation fault (11) [Mon Jun 09 11:12:13 2003] [notice] child pid 21486 exit signal Segmentation fault (11) [Mon Jun 09 11:12:13 2003] [notice] child pid 21485 exit signal Segmentation fault (11) [2003-06-09 03:55:03] ronald_zeelenberg at hotmail dot com Okay since two day i can make a correct version of the daily based PHP5 version. Accept some php-pages with DB-actions and PEAR based are crashing... Apache2 says killed the child etc. Daily based 4.3x does not have this problem. Is something changed in PHP5 which ic causing this? I did not change my code... [2003-06-08 22:13:36] chrisgio at virtualscape dot net This is what I'm seeing: $ make install-pear-installer [PEAR] Archive_Tar- already installed: 0.9 [PEAR] Console_Getopt - already installed: 1.0 [PEAR] PEAR - already installed: 1.1 make: *** [install-pear-installer] Segmentation fault (core dumped) $gdb sapi/cli/php core -snip- Core was generated by `/usr/local/testbed/build/php5/sapi/cli/php -n -dsafe_mode 0 /usr/local/testbed/'. Program terminated with signal 11, Segmentation fault. -snip- #0 0x081b85b6 in _efree (ptr=0x8319990) at /usr/local/testbed/build/php5/Zend/zend_alloc.c:276 276 REMOVE_POINTER_FROM_LIST(p); (gdb) bt #0 0x081b85b6 in _efree (ptr=0x8319990) at /usr/local/testbed/build/php5/Zend/zend_alloc.c:276 #1 0x0818c72b in php_xml_free_wrapper (ptr=0x8319990) at /usr/local/testbed/build/php5/ext/xml/xml.c:185 #2 0x4033257c in xmlHashFree () from /usr/lib/libxml2.so.2 #3 0x4028c140 in xsltUnregisterExtModule () from /usr/lib/libxslt.so.1 #4 0x4028cbeb in xsltCleanupGlobals () from /usr/lib/libxslt.so.1 #5 0x0809fada in zm_shutdown_domxml (type=1, module_number=20, tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/ext/domxml/php_domxml.c:1569 #6 0x081cdb3c in module_destructor (module=0x831dd48) at /usr/local/testbed/build/php5/Zend/zend_API.c:1276 #7 0x081cfa78 in zend_hash_apply_deleter (ht=0x8294c00, p=0x831dd18) at /usr/local/testbed/build/php5/Zend/zend_hash.c:565 #8 0x081cfb06 in zend_hash_graceful_reverse_destroy (ht=0x8294c00) at /usr/local/testbed/build/php5/Zend/zend_hash.c:631 #9 0x081ca573 in zend_shutdown (tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/Zend/zend.c:684 #10 0x08199f81 in php_module_shutdown (tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/main/main.c:1457 #11 0x081e69c7 in main (argc=7, argv=0xbaf4) at /usr/local/testbed/build/php5/sapi/cli/php_cli.c:1020 Machine: Debain based 2.4.20 kernel on x86 GCC 3.2.3 bison 1.875a flex 2.5.4 apache 2.0.46 libxslt 1.0.30 libxml2 2.5.6 php 5.0.0-dev 20030608 with options: './configure' '--prefix=/usr/local/testbed/php5' '--with-openssl' '--with-apxs2=/usr/local/testbed/apache2/bin/apxs' '--with-config-file-path=/usr/local/testbed/php5/lib' '--enable-bcmath' '--enable-calendar' '--with-curl=/usr/local/testbed' '--with-curl-wrappers' '--enable-dba' '--with-gdbm' '--with-flatfile' '--enable-dio' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--with-dom5' '--enable-exif' '--enable-ftp' '--with-gd' '--with-imap-ssl' '--with-ldap' '--enable-mbstring' '--with-pgsql=/usr/local/testbed/pgsql' '--with-libedit' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-pic' '--with-zlib' [2003-06-04 04:12:24]
#24103 [NEW]: After I upgraded from PHP-4.3.1 to 4.3.2 my Apache module mod_rewrite crashes
From: hlj at viamidia dot com Operating system: FreeBSD 4.6 PHP version: 4.3.2 PHP Bug Type: Reproducible crash Bug description: After I upgraded from PHP-4.3.1 to 4.3.2 my Apache module mod_rewrite crashes - To reproduce the problem, you can install apache-1.3.27(default modules including mod_rewrite)+php-4.3.1(linked with the imap-uw imap access library) and configure some rewrite rules in httpd.conf, this will work (it works for me for years). After you upgrade php to 4.3.2 version (and don't change anything else) the mod_rewrite rules simply stop working and crashes the httpd process that was serving the request (Jun 8 00:01:58 www /kernel: pid 59615 (httpd), uid 80: exited on signal 11) -my configure line was: ./configure --with-apxs=/usr/local/sbin/apxs --disable-debug --enable-track-vars --disable-pear --without-gd --with-imap=/usr/local --with-mysql - Nothing else was changed. The problem started right after the PHP upgrade (from 4.3.1 to 4.3.2) that I did exactly as I am doing for years (since php 3.x). -- Edit bug report at http://bugs.php.net/?id=24103edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24103r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24103r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24103r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24103r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24103r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24103r=support Expected behavior: http://bugs.php.net/fix.php?id=24103r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24103r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24103r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24103r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24103r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24103r=dst IIS Stability: http://bugs.php.net/fix.php?id=24103r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24103r=gnused
#24104 [NEW]: make failure
From: wax at y12 dot doe dot gov Operating system: OSF1 V4.0 878 alpha PHP version: 4.3.2 PHP Bug Type: Compile Failure Bug description: make failure I do this as a configure string: ./configure --prefix=/opt/local/stow/php-4.3.2 --with-mysql --with-apache=/usr/local/apache --with-zlib=/opt/local --with-zlib-dir=~wax/zlib --with-gd=/opt/local --with-jpeg-dir=/opt/local --with-png=/opt/local My GCC version is 2.7.2.2 . It works fine it seems... I then run make and I get this: gcc -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC -I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main -I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include -I/u00/wax/php-4.3.3/ext/xml/expat -I/u00/wax/php-4.3.3/TSRM -g -O2 -c /u00/wax/php-4.3.3/Zend/zend_stack.c -o Zend/zend_stack.o echo Zend/zend_stack.lo gcc -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC -I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main -I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include -I/u00/wax/php-4.3.3/ext/xml/expat -I/u00/wax/php-4.3.3/TSRM -g -O2 -c /u00/wax/php-4.3.3/Zend/zend_variables.c -o Zend/zend_variables.o echo Zend/zend_variables.lo gcc -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC -I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main -I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include -I/u00/wax/php-4.3.3/ext/xml/expat -I/u00/wax/php-4.3.3/TSRM -g -O2 -c /u00/wax/php-4.3.3/Zend/zend.c -o Zend/zend.o echo Zend/zend.lo /u00/wax/php-4.3.3/Zend/zend.c: In function `zend_error': /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in something not a structure or union /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__base' in something not a structure or union /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in something not a structure or union /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in something not a structure or union *** Exit 1 Stop. Any suggestions on what is wrong? I will see about upgrading my GCC to 3.3 tomorrow... but if I don't have to upgrade that... the better... -- Edit bug report at http://bugs.php.net/?id=24104edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24104r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24104r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24104r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24104r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24104r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24104r=support Expected behavior: http://bugs.php.net/fix.php?id=24104r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24104r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24104r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24104r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24104r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24104r=dst IIS Stability: http://bugs.php.net/fix.php?id=24104r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24104r=gnused
#24084 [Csd-Opn]: Patch: allow PHP to bind to an LDAP server using SASL
ID: 24084 User updated by: peter_c60 at hotmail dot com Reported By: peter_c60 at hotmail dot com -Status: Closed +Status: Open Bug Type: LDAP related Operating System: Linux PHP Version: 4.3.2 New Comment: I have managed to compile and test the new patch and it works AFAICT. Previous Comments: [2003-06-09 13:22:04] peter_c60 at hotmail dot com It looks like the patch checked into CVS is wrong, at least from an autoconf point of view. The problem is that the function ldap_sasl_interactive_bind_s is always defined whether SASL was enabled at time of compilation or not. Also the sasl.h header is required because the interactive function requires some of its defines. I've made some new patches that check that the LDAP library was linked against libsasl(2) (using ldd, I'm not sure if this is the correct method on all platforms) and also checks for the headers. I haven't tested it myself because I keep on getting a libtool error at time of compile (but that's a story for another bug report) but it seems to work correctly up to the configure stage. Anyway here are the patches (to be applied to the current CVS version): http://www.geocities.com/ldappatch/config2.txt (apply to config.m4) http://www.geocities.com/ldappatch/ldap2.txt (apply to ldap.c) http://www.geocities.com/ldappatch/php_ldap2.txt (apply to php_ldap.h) [2003-06-08 18:44:26] [EMAIL PROTECTED] Patch committed to CVS. (in php5/) [2003-06-08 16:19:32] [EMAIL PROTECTED] The problem with this patch is that it never checks if SASL support is enabled in your LDAP library. I think you will need to check for this with config.m4 and add some ifdef's to the code accordingly, unless *every* LDAP library comes with SASL support of course. [2003-06-08 16:15:51] peter_c60 at hotmail dot com OK then: http://www.geocities.com/ldappatch/ldap.txt http://www.geocities.com/ldappatch/php_ldap.txt [2003-06-08 15:46:19] [EMAIL PROTECTED] Please post this as a text file (unified diff) on a website. 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/24084 -- Edit this bug report at http://bugs.php.net/?id=24084edit=1
#24104 [Opn-Fbk]: make failure
ID: 24104 Updated by: [EMAIL PROTECTED] Reported By: wax at y12 dot doe dot gov -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: OSF1 V4.0 878 alpha PHP Version: 4.3.2 New Comment: Please try with a stable compiler such as gcc 2.96 or 3.2.3. You could also try with Tru64's compiler (CC=cc ./configure). I personally haven't seen anything like this with 4.3.2 on Tru64. Previous Comments: [2003-06-09 17:45:18] wax at y12 dot doe dot gov I do this as a configure string: ./configure --prefix=/opt/local/stow/php-4.3.2 --with-mysql --with-apache=/usr/local/apache --with-zlib=/opt/local --with-zlib-dir=~wax/zlib --with-gd=/opt/local --with-jpeg-dir=/opt/local --with-png=/opt/local My GCC version is 2.7.2.2 . It works fine it seems... I then run make and I get this: gcc -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC -I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main -I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include -I/u00/wax/php-4.3.3/ext/xml/expat -I/u00/wax/php-4.3.3/TSRM -g -O2 -c /u00/wax/php-4.3.3/Zend/zend_stack.c -o Zend/zend_stack.o echo Zend/zend_stack.lo gcc -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC -I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main -I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include -I/u00/wax/php-4.3.3/ext/xml/expat -I/u00/wax/php-4.3.3/TSRM -g -O2 -c /u00/wax/php-4.3.3/Zend/zend_variables.c -o Zend/zend_variables.o echo Zend/zend_variables.lo gcc -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC -I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main -I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include -I/u00/wax/php-4.3.3/ext/xml/expat -I/u00/wax/php-4.3.3/TSRM -g -O2 -c /u00/wax/php-4.3.3/Zend/zend.c -o Zend/zend.o echo Zend/zend.lo /u00/wax/php-4.3.3/Zend/zend.c: In function `zend_error': /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in something not a structure or union /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__base' in something not a structure or union /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in something not a structure or union /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in something not a structure or union *** Exit 1 Stop. Any suggestions on what is wrong? I will see about upgrading my GCC to 3.3 tomorrow... but if I don't have to upgrade that... the better... -- Edit this bug report at http://bugs.php.net/?id=24104edit=1
#24053 [Com]: include issues spurious stream warning that clutters up the page ...
ID: 24053 Comment by: kriek at jonkriek dot com Reported By: jphey at netdoor dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux 2.4.20 PHP Version: 4.3.2 New Comment: I had to form absolute paths out of my relative ones. Previous Comments: [2003-06-06 15:43:01] admin at 1000rpm dot net I don't think this should have a bogus status. Have a search for the error message on google, tons of sites are getting this error. It's pretty urgent, I'm already getting customers complaining. [2003-06-06 15:37:51] admin at 1000rpm dot net What about non-local files? The error still comes up for those... [2003-06-06 01:48:56] [EMAIL PROTECTED] Don't include local files via http://..., use the correct path. [2003-06-06 01:41:34] jphey at netdoor dot com My web hosting provider says the problem is merely that error logging was set to all and by changing that, the warning messages disappear. So perhaps this is not a bug, but an intended behavior. Still, I don't know why such a warning would be issued when no call to fseek had been made. [2003-06-06 00:25:22] jphey at netdoor dot com I have used the include http://; directive with great success. However, my web hosting company (hostforweb.com) must have just upgraded their PHP software within the last week, because now ALL my pages that use the include command include Warning: main(): stream does not support seeking /home/americaf/public_html/agenda/index.php on line 1 The funny thing is, the actual include appears to work properly ... the file IS included in the stream! However, the warning message appears anyway. Here is a URL that demonstrates the problem: http://americafirstparty.org/agenda/index.php the first several lines of which are: === begin index.php source == ?php include http://americafirstparty.org/includes/plainpageheader.shtml;; ? blockquote h1National Committee Meeting Agenda/h1 h3Tuesday, May 20, 2003brContinued on May 27, 2003/h3 === end of source snippet I know this bug was fixed earlier, but perhaps it has resurfaced? -- Edit this bug report at http://bugs.php.net/?id=24053edit=1
#24105 [NEW]: class member functions aren't first class data objects
From: knotwell at ix dot netcom dot com
Operating system:
PHP version: 4.3.1
PHP Bug Type: Class/Object related
Bug description: class member functions aren't first class data objects
I've checked the documentation, but it doesn't address this
issue. As a result, I'm unsure if this is a bug or by design.
Anyhow, it appears class functions aren't first class data objects. I've
included a short example leading to a
Call to undefined function message as a example:
?php
function generic_data_handler($specializedFn,$specializedFnData) {
return $specializedFn($specializedFnData);
}
class z {
var $x = 10;
var $y = 4;
function _mult($me) {
return($me-x * $me-y);
}
function aStupidlyContrivedExample() {
return generic_data_handler($this-_mult,$this);
}
}
$a = new z;
print $a-_mult($a);
// an error from the runtime system
print $a-aStupidlyContrivedExample();
?
Apologies in advance if this is common knowledge or not a bug.
--
Edit bug report at http://bugs.php.net/?id=24105edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24105r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24105r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24105r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24105r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24105r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24105r=support
Expected behavior: http://bugs.php.net/fix.php?id=24105r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24105r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24105r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24105r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24105r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24105r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24105r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24105r=gnused
#23760 [Fbk-Opn]: bizarre session variable behavior only in RC4
ID: 23760 User updated by: php-general at pennysaverusa dot net -Summary: using virtual() causes segmentation faults Reported By: php-general at pennysaverusa dot net -Status: Feedback +Status: Open Bug Type: Apache related Operating System: RedHat 7.3 PHP Version: 4.3.2RC4 New Comment: Someone changed the online docs VERY recently, however I'm sure there is a problem here. I did ulimit -c unlimited, and then ran apache manually (with all the -DHAVEs) but no core file was produced. Thanks, Barry Previous Comments: [2003-06-07 09:21:59] [EMAIL PROTECTED] virtual() works fine on PHP files, as documented (although I can't test old versions), so I believe sniper was just mistaken and don't see anything here to document. Barry, are you sure you set the ulimit before the backtrace? That's extremely important. I'm unable to reproduce and changing back to Apache related. [2003-06-07 05:04:30] [EMAIL PROTECTED] What sniper says is not in line with the current manual. The current manual says that as of PHP 4.0.6 virtual() can be used on PHP files. So the manual is not correct I assume. Changing this to be a doc problem. [2003-05-27 13:43:18] php-general at pennysaverusa dot net I am aware of that. However, this was not a PHP file. It is merely an html file with a .php extension. There is no good reason for it to segfault. If the policy is that .php files will not be loaded with virtual, then DON'T LOAD IT. GIVE AN ERROR. DON'T RANDOMLY CRASH. Random crashes are inexcusable. At least try to make the software idiot-proof. Give the idiot an error or warning message. At least, the documentation for virtual should mention this problem if it's not going to be fixed. Thank you, Barry Gould [2003-05-23 20:53:22] [EMAIL PROTECTED] FYI: Using virtual() for this is absolutely useless, you really should be using include(). And as manual says: virtual() cannot be used to include a document which is itself a PHP file. As otherwise the results are unpredictable.. (I didn't get any crash anyway) [2003-05-23 20:38:23] php-general at pennysaverusa dot net OK. To reproduce this, please download: http://www2.pennysaverusa.com/barry/virtual_php_crash.tgz Tested on RC3 and RC4 and php4-STABLE-200305222330 all segfault. Notes: 1 unset session variable is _not_ enough to trigger the crash. 2 variables seems to be sufficient on my server. The head and footer files are plain html. I named them with .php out of habit. With .txt, it does not crash. I know php won't (or at least shouldn't) parse them as php when using virtual, so I see no reasonable excuse for it to crash. As I mentioned before, with DBG enabled or disabled, it still segfaults. Thanks, Barry Gould 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/23760 -- Edit this bug report at http://bugs.php.net/?id=23760edit=1
#23760 [Com]: bizarre session variable behavior only in RC4
ID: 23760 Comment by: barrygould at pennysaverusa dot net Reported By: php-general at pennysaverusa dot net Status: Open Bug Type: Apache related Operating System: RedHat 7.3 PHP Version: 4.3.2RC4 New Comment: Philip, did you try the test files I linked? Thanks, Barry Previous Comments: [2003-06-09 19:57:36] php-general at pennysaverusa dot net Someone changed the online docs VERY recently, however I'm sure there is a problem here. I did ulimit -c unlimited, and then ran apache manually (with all the -DHAVEs) but no core file was produced. Thanks, Barry [2003-06-07 09:21:59] [EMAIL PROTECTED] virtual() works fine on PHP files, as documented (although I can't test old versions), so I believe sniper was just mistaken and don't see anything here to document. Barry, are you sure you set the ulimit before the backtrace? That's extremely important. I'm unable to reproduce and changing back to Apache related. [2003-06-07 05:04:30] [EMAIL PROTECTED] What sniper says is not in line with the current manual. The current manual says that as of PHP 4.0.6 virtual() can be used on PHP files. So the manual is not correct I assume. Changing this to be a doc problem. [2003-05-27 13:43:18] php-general at pennysaverusa dot net I am aware of that. However, this was not a PHP file. It is merely an html file with a .php extension. There is no good reason for it to segfault. If the policy is that .php files will not be loaded with virtual, then DON'T LOAD IT. GIVE AN ERROR. DON'T RANDOMLY CRASH. Random crashes are inexcusable. At least try to make the software idiot-proof. Give the idiot an error or warning message. At least, the documentation for virtual should mention this problem if it's not going to be fixed. Thank you, Barry Gould [2003-05-23 20:53:22] [EMAIL PROTECTED] FYI: Using virtual() for this is absolutely useless, you really should be using include(). And as manual says: virtual() cannot be used to include a document which is itself a PHP file. As otherwise the results are unpredictable.. (I didn't get any crash anyway) 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/23760 -- Edit this bug report at http://bugs.php.net/?id=23760edit=1
#24092 [Bgs]: ncurses panel
ID: 24092
Updated by: [EMAIL PROTECTED]
Reported By: garrote at dm dot com dot br
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: linux 2.4.20
PHP Version: 4CVS-2003-06-09 (stable)
New Comment:
Does not crash here.
Previous Comments:
[2003-06-09 09:15:31] garrote at dm dot com dot br
i´m sory i don´t send this function in example...plese add the
coment in those line
// } else
//ncurses_wbkgdsett($win, NCURSES_A_BOLD | ' ');
but the problem persist whithout this function.
[2003-06-09 08:41:25] [EMAIL PROTECTED]
Fatal error: Call to undefined function: ncurses_wbkgdset()
Try provide a script that has even remote possibility on
working..or at least a GDB backtrace.
[2003-06-09 07:33:07] garrote at dm dot com dot br
Good morning,
there is a problem with ncurses_panel_window. if you create more than
one panel it doesn´t sets the recurse correctly and return segment
fault. i have to use array to storage the information of window and
panel.
one think...we use function to retrieve the information...but i don´t
think that it´s the problem.
function nova_janela($nr_linhas, $nr_colunas, $linha, $coluna, $cor)
{
global $WINDOW;
$win = ncurses_newwin($nr_linhas, $nr_colunas, $linha,
$coluna);
if(!$win) // temos uma window
return false;
$janela = ncurses_new_panel($win);
if(!$janela) // temos uma janela
return false;
$WINDOW[$janela] = $win; // coloca na memoria o recurso
if(ncurses_has_colors() and $cor) { // temos cor no terminal
$fg = ($cor == NCURSES_COLOR_BLUE) ?
NCURSES_COLOR_WHITE : NCURSES_COLOR_BLACK;
$bg = $cor;
ncurses_init_pair($cor, $fg, $bg);
ncurses_wattron($win, (color_pair($cor) | ' '));
} else
ncurses_wbkgdsett($win, NCURSES_A_BOLD | ' ');
ncurses_wborder($win, 0,0,0,0,0,0,0,0);
$l = 1;
while($l $nr_linhas - 1) {
$c = 1;
ncurses_wmove($win, $l, 1);
while($c++ $nr_colunas - 1) {
ncurses_waddch($win, 32);
//ncurses_update_panels(); //oops
ncurses_wrefresh($win); //oops
}
$l++;
}
ncurses_update_panels();
ncurses_doupdate();
return $janela;
}
function remove_janela($janela)
{
global $WINDOW;
if(!$janela) // temos uma janela
return false;
//$win = ncurses_panel_window($janela); // error Segment fault
$win = $WINDOW[$janela]; // recupera recurso
if(!$win) // temos uma window
return false;
ncurses_del_panel($janela); // libera janela
ncurses_delwin($win); // libera window
ncurses_update_panels();
ncurses_doupdate();
return true;
}
$WINDOW=ARRAY();
ncurses_init();
if(ncurses_has_colors())
ncurses_start_color();
$i=0;
while($i 5) {
$a[$i] = nova_janela(10 + ($i * 2), 20 + ($i * 5), 10 + $i, 10
+ $i,$i + 1);
$i++;
}
$i=0;
while($i 5) {
remove_janela($a[$i]);
$i++;
}
ncurses_end();
exit;
PHP 4.3.3-dev (cgi) (built: Jun 6 2003 19:30:49)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
[PHP Modules]
ctype
mysql
ncurses
overload
pcre
posix
session
standard
tokenizer
xml
[Zend Modules]
--
Edit this bug report at http://bugs.php.net/?id=24092edit=1
#24083 [Opn-Fbk]: Content-Encoding: gzip output includes the wrong Content-Length header
ID: 24083 Updated by: [EMAIL PROTECTED] Reported By: yngve at opera dot com -Status: Open +Status: Feedback Bug Type:Zlib Related PHP Version: 4.3.1 New Comment: We still need a short script to reproduce this, anything I've tried works just fine.. Previous Comments: [2003-06-09 09:01:37] yngve at opera dot com I do not know if this is present in 4.3.2 as I am not using PHP myself, but I do know that the problem is present on servers using PHP 4.2.2 and 4.3.1, and your changelog does not indicate many changes related to compression, and none that I can see are related to this problem. [2003-06-09 08:30:01] [EMAIL PROTECTED] Does this happen with PHP 4.3.2 ? [2003-06-08 15:24:24] yngve at opera dot com I am a developer with Opera Software, the developer of the Opera browser. We have received several reports about problems with forums using VBulletin, but based on what I've learned I suspect that the problem is a general PHP problem, not Vbulletin specific. The reason for the problem turns out to be the same, or of a similar nature, as my earlier bug report #12884. A while ago I was in contact with one of the boards affected by the problem Rage3D.com. They reported back that they were able to solve the problem by turning off global compression From the Rage3D people (with permission): The problem was caused because we were running the php output_handler = ob_gzhandler for global site compression. vB didn't know to use the right content length header. We've resolved the issue by turning off global compression and enabling gzip encoding through vBulletin. We will be seeing if an updated gzip library for our server will resolve the issue so we can run global php compression in the future. The following is a hexdump of the request and response headers from one of my tests (before Rage3D fixed the problem). --- : 47 45 54 20 2f 62 6f 61 72 64 2f 20 48 54 54 50 GET /board/ HTTP 0010 : 2f 31 2e 31 0d 0a 55 73 65 72 2d 41 67 65 6e 74 /1.1..User-Agent 0020 : 3a 20 4d 6f 7a 69 6c 6c 61 2f 34 2e 30 20 28 63 : Mozilla/4.0 (c 0030 : 6f 6d 70 61 74 69 62 6c 65 3b 20 4d 53 49 45 20 ompatible; MSIE 0040 : 36 2e 30 3b 20 57 69 6e 64 6f 77 73 20 4e 54 20 6.0; Windows NT 0050 : 35 2e 30 29 20 4f 70 65 72 61 20 37 2e 31 31 20 5.0) Opera 7.11 0060 : 20 5b 65 6e 5d 0d 0a 48 6f 73 74 3a 20 77 77 77 [en]..Host: www 0070 : 2e 72 61 67 65 33 64 2e 63 6f 6d 0d 0a 41 63 63 .rage3d.com..Acc 0080 : 65 70 74 3a 20 74 65 78 74 2f 68 74 6d 6c 2c 20 ept: text/html, 0090 : 69 6d 61 67 65 2f 70 6e 67 2c 20 69 6d 61 67 65 image/png, image 00a0 : 2f 6a 70 65 67 2c 20 69 6d 61 67 65 2f 67 69 66 /jpeg, image/gif 00b0 : 2c 20 69 6d 61 67 65 2f 78 2d 78 62 69 74 6d 61 , image/x-xbitma 00c0 : 70 2c 20 2a 2f 2a 3b 71 3d 30 2e 31 0d 0a 41 63 p, */*;q=0.1..Ac 00d0 : 63 65 70 74 2d 4c 61 6e 67 75 61 67 65 3a 20 65 cept-Language: e 00e0 : 6e 3b 71 3d 31 2e 30 2c 65 6e 3b 71 3d 30 2e 39 n;q=1.0,en;q=0.9 00f0 : 0d 0a 41 63 63 65 70 74 2d 43 68 61 72 73 65 74 ..Accept-Charset 0100 : 3a 20 77 69 6e 64 6f 77 73 2d 31 32 35 32 2c 20 : windows-1252, 0110 : 75 74 66 2d 38 2c 20 75 74 66 2d 31 36 2c 20 69 utf-8, utf-16, i 0120 : 73 6f 2d 38 38 35 39 2d 31 3b 71 3d 30 2e 36 2c so-8859-1;q=0.6, 0130 : 20 2a 3b 71 3d 30 2e 31 0d 0a 41 63 63 65 70 74 *;q=0.1..Accept 0140 : 2d 45 6e 63 6f 64 69 6e 67 3a 20 64 65 66 6c 61 -Encoding: defla 0150 : 74 65 2c 20 67 7a 69 70 2c 20 78 2d 67 7a 69 70 te, gzip, x-gzip 0160 : 2c 20 69 64 65 6e 74 69 74 79 2c 20 2a 3b 71 3d , identity, *;q= 0170 : 30 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 4b 0..Connection: K 0180 : 65 65 70 2d 41 6c 69 76 65 0d 0a 0d 0aeep-Alive : 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK. 0010 : 0a 53 65 72 76 65 72 3a 20 4d 69 63 72 6f 73 6f .Server: Microso 0020 : 66 74 2d 49 49 53 2f 35 2e 30 0d 0a 44 61 74 65 ft-IIS/5.0..Date 0030 : 3a 20 54 68 75 2c 20 30 38 20 4d 61 79 20 32 30 : Thu, 08 May 20 0040 : 30 33 20 30 32 3a 32 30 3a 30 33 20 47 4d 54 0d 03 02:20:03 GMT. 0050 : 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f .Connection: clo 0060 : 73 65 0d 0a 58 2d 50 6f 77 65 72 65 64 2d 42 79 se..X-Powered-By 0070 : 3a 20 50 48 50 2f 34 2e 33 2e 31 0d 0a 43 6f 6e : PHP/4.3.1..Con 0080 : 74 65 6e 74 2d 74 79 70 65 3a 20 74 65 78 74 2f tent-type: text/ 0090 : 68 74 6d 6c 0d 0a 53 65 74 2d 43 6f 6f 6b 69 65 html..Set-Cookie 00a0 : 3a 20 73 65 73 73 69 6f 6e 68 61 73 68 3d 38 65 : sessionhash=8e 00b0 : 33 32 32 36 63 30 33 32 34 31 31 32 32 66 33 30 3226c03241122f30 00c0 : 31 38 64 64 33 64 64 62 38 61 38 63 37 61 3b 20 18dd3ddb8a8c7a; 00d0 : 70 61 74 68 3d 2f 0d 0a 53 65 74 2d 43 6f 6f
#24097 [Opn-Asn]: ibase_rollback warning message
ID: 24097 Updated by: [EMAIL PROTECTED] Reported By: benji at autec dot es -Status: Open +Status: Assigned Bug Type: InterBase related Operating System: Windows XP Professional PHP Version: 4.3.2 -Assigned To: +Assigned To: daniela New Comment: Both ibase_commit() and ibase_rollback() are affected. The protos for them say the link parameter is optional, but you should still be able to give it both parameters. (to be able to handle multiple db connections in same script) _php_ibase_trans_end() has missing 'case 2:' in the switch(), so you can not give it both the connection link and transaction as parameters, just either or. Daniela, can you take a look? Previous Comments: [2003-06-09 10:44:43] benji at autec dot es When you do a: ibase_rollback( $connection, $trans); both parameters being correct. This function returns a warning message claiming wrong parameter count. but works fine anyway. Also if you call: ibase_rollback( $trans); Function does not give any error message. The documentation says: int ibase_rollback ( [int link_identifier, int trans_number] ) May be it is an error of the documetation... Thank you php team, Ben -- Edit this bug report at http://bugs.php.net/?id=24097edit=1
#24089 [Opn-Ver]: Problem creating objects with names from class' fields
ID: 24089 Updated by: [EMAIL PROTECTED] Reported By: bartosz at webcity dot pl -Status: Open +Status: Verified -Bug Type: *General Issues +Bug Type: Zend Engine 2 problem Operating System: Linux PHP Version: 5CVS-2003-06-09 (dev) New Comment: Latest CVS gives: Parse error: parse error in /home/jani/t.php on line 25 (for the script provided in the first comment in this report) Previous Comments: [2003-06-09 13:39:34] bartosz at webcity dot pl Only notice about parse error, nothing else: Parse error: parse error in /home/bartosz/www/foo.php on line 25 [2003-06-09 12:47:59] neon at neon-line dot net Oh... I propably wasn't thinking while writing my previous comment. For me it works with php5-200306091730 and PHP4. Are you sure that you don't have some kind of typing error etc. in you code... [2003-06-09 12:15:14] bartosz at webcity dot pl So, why it works with php4, but with php5 doesn't? [2003-06-09 05:12:33] neon at neon-line dot net It's not a bug. [2003-06-09 04:28:43] bartosz at webcity dot pl Look at 'foobar' method in 'foobar' class. It makes parse error: $this - obj = new $this - classname; but it works: $classname = $this - classname; $this - obj = new $classname; in php4 $this - obj = new $this - classname; works correctly. It isn't a bug? 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/24089 -- Edit this bug report at http://bugs.php.net/?id=24089edit=1
#24010 [Opn]: Make failure
ID: 24010 Updated by: [EMAIL PROTECTED] Reported By: ronald_zeelenberg at hotmail dot com Status: Open -Bug Type: Compile Failure +Bug Type: Zend Engine 2 problem Operating System: Red Hat 8 PHP Version: 5CVS-2003-06-04 (dev) New Comment: It's PHP5. And PEAR is not ready for it.. :) Previous Comments: [2003-06-09 16:37:52] ronald_zeelenberg at hotmail dot com I can now link again (been able since 4 days ago) saw this in my system log. But pages with PEAR are still crashing. I do not have these problems in version 43x. What is this thing? [2003-06-09 04:17:13] ronald_zeelenberg at hotmail dot com After setting LogLevel to debug in httpd.conf i found this extra info. [Mon Jun 09 06:12:27 2003] [notice] Apache/2.0.46 (Unix) DAV/2 PHP/5.0.0-dev configured -- resuming normal operations [Mon Jun 09 10:55:58 2003] [notice] child pid 21213 exit signal Segmentation fault (11) [Mon Jun 09 10:55:58 2003] [notice] child pid 21168 exit signal Segmentation fault (11) [Mon Jun 09 10:55:58 2003] [notice] child pid 21167 exit signal Segmentation fault (11) [Mon Jun 09 11:11:25 2003] [notice] caught SIGTERM, shutting down [Mon Jun 09 11:11:25 2003] [notice] Apache/2.0.46 (Unix) DAV/2 PHP/5.0.0-dev configured -- resuming normal oper ations [Mon Jun 09 11:11:25 2003] [info] Server built: Jun 1 2003 13:15:30 [Mon Jun 09 11:11:25 2003] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem) [Mon Jun 09 11:12:13 2003] [notice] child pid 21487 exit signal Segmentation fault (11) [Mon Jun 09 11:12:13 2003] [notice] child pid 21486 exit signal Segmentation fault (11) [Mon Jun 09 11:12:13 2003] [notice] child pid 21485 exit signal Segmentation fault (11) [2003-06-09 03:55:03] ronald_zeelenberg at hotmail dot com Okay since two day i can make a correct version of the daily based PHP5 version. Accept some php-pages with DB-actions and PEAR based are crashing... Apache2 says killed the child etc. Daily based 4.3x does not have this problem. Is something changed in PHP5 which ic causing this? I did not change my code... [2003-06-08 22:13:36] chrisgio at virtualscape dot net This is what I'm seeing: $ make install-pear-installer [PEAR] Archive_Tar- already installed: 0.9 [PEAR] Console_Getopt - already installed: 1.0 [PEAR] PEAR - already installed: 1.1 make: *** [install-pear-installer] Segmentation fault (core dumped) $gdb sapi/cli/php core -snip- Core was generated by `/usr/local/testbed/build/php5/sapi/cli/php -n -dsafe_mode 0 /usr/local/testbed/'. Program terminated with signal 11, Segmentation fault. -snip- #0 0x081b85b6 in _efree (ptr=0x8319990) at /usr/local/testbed/build/php5/Zend/zend_alloc.c:276 276 REMOVE_POINTER_FROM_LIST(p); (gdb) bt #0 0x081b85b6 in _efree (ptr=0x8319990) at /usr/local/testbed/build/php5/Zend/zend_alloc.c:276 #1 0x0818c72b in php_xml_free_wrapper (ptr=0x8319990) at /usr/local/testbed/build/php5/ext/xml/xml.c:185 #2 0x4033257c in xmlHashFree () from /usr/lib/libxml2.so.2 #3 0x4028c140 in xsltUnregisterExtModule () from /usr/lib/libxslt.so.1 #4 0x4028cbeb in xsltCleanupGlobals () from /usr/lib/libxslt.so.1 #5 0x0809fada in zm_shutdown_domxml (type=1, module_number=20, tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/ext/domxml/php_domxml.c:1569 #6 0x081cdb3c in module_destructor (module=0x831dd48) at /usr/local/testbed/build/php5/Zend/zend_API.c:1276 #7 0x081cfa78 in zend_hash_apply_deleter (ht=0x8294c00, p=0x831dd18) at /usr/local/testbed/build/php5/Zend/zend_hash.c:565 #8 0x081cfb06 in zend_hash_graceful_reverse_destroy (ht=0x8294c00) at /usr/local/testbed/build/php5/Zend/zend_hash.c:631 #9 0x081ca573 in zend_shutdown (tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/Zend/zend.c:684 #10 0x08199f81 in php_module_shutdown (tsrm_ls=0x8295538) at /usr/local/testbed/build/php5/main/main.c:1457 #11 0x081e69c7 in main (argc=7, argv=0xbaf4) at /usr/local/testbed/build/php5/sapi/cli/php_cli.c:1020 Machine: Debain based 2.4.20 kernel on x86 GCC 3.2.3 bison 1.875a flex 2.5.4 apache 2.0.46 libxslt 1.0.30 libxml2 2.5.6 php 5.0.0-dev 20030608 with options: './configure' '--prefix=/usr/local/testbed/php5' '--with-openssl' '--with-apxs2=/usr/local/testbed/apache2/bin/apxs' '--with-config-file-path=/usr/local/testbed/php5/lib' '--enable-bcmath' '--enable-calendar' '--with-curl=/usr/local/testbed' '--with-curl-wrappers' '--enable-dba' '--with-gdbm' '--with-flatfile' '--enable-dio' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--with-dom5' '--enable-exif' '--enable-ftp' '--with-gd' '--with-imap-ssl' '--with-ldap' '--enable-mbstring' '--with-pgsql=/usr/local/testbed/pgsql'
#24104 [Fbk]: make failure
ID: 24104 Updated by: [EMAIL PROTECTED] Reported By: wax at y12 dot doe dot gov Status: Feedback Bug Type: Compile Failure Operating System: OSF1 V4.0 878 alpha PHP Version: 4.3.2 New Comment: Please ignore the previous comment, neither of those compilers are 'stable' in the way 2.95.3 is for example. Previous Comments: [2003-06-09 18:52:48] [EMAIL PROTECTED] Please try with a stable compiler such as gcc 2.96 or 3.2.3. You could also try with Tru64's compiler (CC=cc ./configure). I personally haven't seen anything like this with 4.3.2 on Tru64. [2003-06-09 17:45:18] wax at y12 dot doe dot gov I do this as a configure string: ./configure --prefix=/opt/local/stow/php-4.3.2 --with-mysql --with-apache=/usr/local/apache --with-zlib=/opt/local --with-zlib-dir=~wax/zlib --with-gd=/opt/local --with-jpeg-dir=/opt/local --with-png=/opt/local My GCC version is 2.7.2.2 . It works fine it seems... I then run make and I get this: gcc -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC -I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main -I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include -I/u00/wax/php-4.3.3/ext/xml/expat -I/u00/wax/php-4.3.3/TSRM -g -O2 -c /u00/wax/php-4.3.3/Zend/zend_stack.c -o Zend/zend_stack.o echo Zend/zend_stack.lo gcc -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC -I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main -I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include -I/u00/wax/php-4.3.3/ext/xml/expat -I/u00/wax/php-4.3.3/TSRM -g -O2 -c /u00/wax/php-4.3.3/Zend/zend_variables.c -o Zend/zend_variables.o echo Zend/zend_variables.lo gcc -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC -I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main -I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include -I/u00/wax/php-4.3.3/ext/xml/expat -I/u00/wax/php-4.3.3/TSRM -g -O2 -c /u00/wax/php-4.3.3/Zend/zend.c -o Zend/zend.o echo Zend/zend.lo /u00/wax/php-4.3.3/Zend/zend.c: In function `zend_error': /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in something not a structure or union /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__base' in something not a structure or union /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in something not a structure or union /u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in something not a structure or union *** Exit 1 Stop. Any suggestions on what is wrong? I will see about upgrading my GCC to 3.3 tomorrow... but if I don't have to upgrade that... the better... -- Edit this bug report at http://bugs.php.net/?id=24104edit=1
#24096 [Opn-Bgs]: session_regenerate_id not delete the old session file
ID: 24096 Updated by: [EMAIL PROTECTED] Reported By: pablo_sole at myp dot net dot ar -Status: Open +Status: Bogus -Bug Type: Session related +Bug Type: Feature/Change Request Operating System: linux rh8 apache 1.3.27 PHP Version: 4.3.2 New Comment: It is debatable whether the function should destroy the old session. The current behaviour is useful under a number of circumstances. Auto-destruction could be added as a new feature though. - Feature/Change request. Previous Comments: [2003-06-09 09:42:08] pablo_sole at myp dot net dot ar testing the new session_regenerate_id i see that after upgrade de SID, not unlink the old session file so, when you regenerate many times the session could be used to make a DoS, or at least is not what it's expected from the function. Checking the source code, the routine free the SID and assign the new, but not unlink the old file (just like in the php_session_destroy routine). A workaround could be unlink manualy on the fly, or patch the session.c file. Sorry my poor english, but is not my native language. Any question, mail me. pablo. PD: I not have any specific setup or extra modules compiled in, and for that reason i don't put it here. -- Edit this bug report at http://bugs.php.net/?id=24096edit=1
#24096 [Bgs-Opn]: session_regenerate_id not delete the old session file
ID: 24096 Updated by: [EMAIL PROTECTED] Reported By: pablo_sole at myp dot net dot ar -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: linux rh8 apache 1.3.27 PHP Version: 4.3.2 New Comment: - Open Previous Comments: [2003-06-09 23:10:25] [EMAIL PROTECTED] It is debatable whether the function should destroy the old session. The current behaviour is useful under a number of circumstances. Auto-destruction could be added as a new feature though. - Feature/Change request. [2003-06-09 09:42:08] pablo_sole at myp dot net dot ar testing the new session_regenerate_id i see that after upgrade de SID, not unlink the old session file so, when you regenerate many times the session could be used to make a DoS, or at least is not what it's expected from the function. Checking the source code, the routine free the SID and assign the new, but not unlink the old file (just like in the php_session_destroy routine). A workaround could be unlink manualy on the fly, or patch the session.c file. Sorry my poor english, but is not my native language. Any question, mail me. pablo. PD: I not have any specific setup or extra modules compiled in, and for that reason i don't put it here. -- Edit this bug report at http://bugs.php.net/?id=24096edit=1
#23760 [Opn-Bgs]: bizarre session variable behavior only in RC4
ID: 23760 Updated by: [EMAIL PROTECTED] Reported By: php-general at pennysaverusa dot net -Status: Open +Status: Bogus Bug Type: Apache related Operating System: RedHat 7.3 PHP Version: 4.3.2RC4 New Comment: First of all, your example stuff is totally bogus. . There is no session_start() anywhere . You include pure html as php using virtual when you should be using include() Second, it never crashes, of course you don't get any core files. Third, there are easier ways to shoot yourself in leg too, but we still don't suggest you should do it. Fourth, as long as you can't provide us any example that actually has any far possibility on working and uses some sane ways on doing things, this is bogus. Phillip: virtual() might work for including php files, but the result is still unpredictable.. Previous Comments: [2003-06-09 20:00:24] barrygould at pennysaverusa dot net Philip, did you try the test files I linked? Thanks, Barry [2003-06-09 19:57:36] php-general at pennysaverusa dot net Someone changed the online docs VERY recently, however I'm sure there is a problem here. I did ulimit -c unlimited, and then ran apache manually (with all the -DHAVEs) but no core file was produced. Thanks, Barry [2003-06-07 09:21:59] [EMAIL PROTECTED] virtual() works fine on PHP files, as documented (although I can't test old versions), so I believe sniper was just mistaken and don't see anything here to document. Barry, are you sure you set the ulimit before the backtrace? That's extremely important. I'm unable to reproduce and changing back to Apache related. [2003-06-07 05:04:30] [EMAIL PROTECTED] What sniper says is not in line with the current manual. The current manual says that as of PHP 4.0.6 virtual() can be used on PHP files. So the manual is not correct I assume. Changing this to be a doc problem. [2003-05-27 13:43:18] php-general at pennysaverusa dot net I am aware of that. However, this was not a PHP file. It is merely an html file with a .php extension. There is no good reason for it to segfault. If the policy is that .php files will not be loaded with virtual, then DON'T LOAD IT. GIVE AN ERROR. DON'T RANDOMLY CRASH. Random crashes are inexcusable. At least try to make the software idiot-proof. Give the idiot an error or warning message. At least, the documentation for virtual should mention this problem if it's not going to be fixed. Thank you, Barry Gould 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/23760 -- Edit this bug report at http://bugs.php.net/?id=23760edit=1
#24101 [Opn-Fbk]: socket_select call is blocking and never returning
ID: 24101
Updated by: [EMAIL PROTECTED]
Reported By: wzaccone at telcordia dot com
-Status: Open
+Status: Feedback
Bug Type: Sockets related
Operating System: Solaris 5.8 / Sparc
PHP Version: 4.3.2
New Comment:
Could you give a complete (but short, please) script
that shows this problem clearly..? (can't reproduce, but I'm propably
missing some part here..)
Previous Comments:
[2003-06-09 14:02:38] wzaccone at telcordia dot com
we upgraded our application from php 4.1.2 to 4.3.2 and are testing.
and found the following code no longer works:
if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL) !==
FALSE){
foreach($socketsCopy as $sock){
The socket_select call appears to be never returning with php 4.3.2..
code worked correctly with 4.1.2.
--
Edit this bug report at http://bugs.php.net/?id=24101edit=1
#23883 [Opn-Bgs]: PHP crashes if snmp module loaded
ID: 23883 Updated by: [EMAIL PROTECTED] Reported By: joey at joeysmith dot com -Status: Open +Status: Bogus Bug Type: SNMP related Operating System: Debian sarge (testing) PHP Version: 4.3.2 New Comment: Joey, discussion about semantics belongs elsewhere, this is a bug database. And there is no bug as long as I can't reproduce it. :) I asked you to try compiling the latest net-snmp version from sources and link PHP with that as it works fine for me here..(and you're the only one reporting this problem so far anyway..) Previous Comments: [2003-06-09 15:36:31] joey at joeysmith dot com No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. That's a faulty assumption. No feedback was provided because I don't see the need to reply to the last comment. 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. Which information was requested? I don't see a request for information, only the implication that if PHP (and PHP alone) is causing crash bugs on a particular distro, that we don't want to try and resolve that. [2003-06-09 08:43:33] [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-06-02 10:28:06] [EMAIL PROTECTED] Use the sources..not some debian package which is most likely broken anyway. (And no idea how it's configured either) [2003-06-02 08:09:27] joey at joeysmith dot com Using SNMP 5.0.7 (debian testing package libsnmp5-dev) still exhibits the crash. I'll build SNMP as static as well. [2003-06-02 06:38:19] [EMAIL PROTECTED] And/or compile it as static module, NOT shared. 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/23883 -- Edit this bug report at http://bugs.php.net/?id=23883edit=1
#24080 [Opn-Asn]: fputs uses 100% cpu on broken pipe
ID: 24080
Updated by: [EMAIL PROTECTED]
Reported By: info at virtualhost dot nl
-Status: Open
+Status: Assigned
Bug Type: URL related
Operating System: Freebsd 4.8
PHP Version: 4.3.2
-Assigned To:
+Assigned To: wez
New Comment:
When run from CLI:
#0 0x406fd0de in __select () from /lib/libc.so.6
#1 0x8563834 in __DTOR_END__ () at md4.c:255
#2 0x829bae2 in php_hostconnect (host=0x8893f74 211.6.149.130,
port=80, socktype=1, timeout=0xbfffd368)
at /usr/src/web/php/php4/main/network.c:468
Using the timeout parameter in fsockopen() 'cures' this. :)
Previous Comments:
[2003-06-09 15:37:39] info at virtualhost dot nl
ok, took some time, but here it is:
Program received signal SIGPIPE, Broken pipe.
0x280ff604 in sendto () from /usr/lib/libc.so.4
#0 0x280ff604 in sendto () from /usr/lib/libc.so.4
#1 0x2812798b in send () from /usr/lib/libc.so.4
#2 0x282b00cb in php_sockop_write (stream=0x809070c, buf=0x815f48c
GET /blalbla HTTP/1.0\n\n, count=23)
at /usr/src/php/php-4.3.2/main/network.c:913
#3 0x282ace63 in _php_stream_write (stream=0x809070c, buf=0x815f48c
GET /blalbla HTTP/1.0\n\n, count=23)
at /usr/src/php/php-4.3.2/main/streams.c:909
#4 0x2824741f in zif_fwrite (ht=2, return_value=0x815d62c,
this_ptr=0x0, return_value_used=0)
at /usr/src/php/php-4.3.2/ext/standard/file.c:1559
#5 0x282dd368 in execute (op_array=0x815e90c) at
/usr/src/php/php-4.3.2/Zend/zend_execute.c:1608
#6 0x282cbada in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php/php-4.3.2/Zend/zend.c:869
#7 0x282a4129 in php_execute_script (primary_file=0xbfbff9c4) at
/usr/src/php/php-4.3.2/main/main.c:1671
#8 0x282e3da2 in apache_php_module_main (r=0x815a034,
display_source_mode=0)
at /usr/src/php/php-4.3.2/sapi/apache/sapi_apache.c:54
#9 0x282e4966 in send_php (r=0x815a034, display_source_mode=0,
filename=0x0)
at /usr/src/php/php-4.3.2/sapi/apache/mod_php4.c:617
#10 0x282e49c6 in send_parsed_php (r=0x815a034) at
/usr/src/php/php-4.3.2/sapi/apache/mod_php4.c:632
#11 0x8051a0c in ap_invoke_handler ()
#12 0x80610e1 in process_request_internal ()
#13 0x8061140 in ap_process_request ()
#14 0x805a62e in child_main ()
#15 0x805a7a0 in make_child ()
#16 0x805a8bd in startup_children ()
#17 0x805adac in standalone_main ()
#18 0x805b493 in main ()
#19 0x804e289 in _start ()
regards,
Jeroen Hofstee
[2003-06-08 08:18:19] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
Please interrupt it once it has started eating the CPU and provide a
backtrace.
[2003-06-08 08:06:42] info at virtualhost dot nl
Same problem with version 4.3.2. But cpu usage is divided differenty.
4.3.1 used about 50% users / 50% system now it is 90% user / 10% sytem.
[2003-06-08 07:09:00] [EMAIL PROTECTED]
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to Open.
Again, thank you for your continued support of PHP.
.
[2003-06-08 07:04:17] info at virtualhost dot nl
hello,
When executing the following code, the httpd deamon consumes all cpu
available, which should not happen of course. It's stops when the
timeout of the script is reached and the process is deleted.
?
$sk = fsockopen ('211.6.149.130', 80);
if ($sk) {
fputs ($sk, GET /blalbla HTTP/1.0\n\n);
}
?
btw. When requested with curl it says directly 'broken pipe'.
btw2. Same for fwrite.
regards,
Jeroen
--
Edit this bug report at http://bugs.php.net/?id=24080edit=1
#23195 [Opn]: copying an array resets its pointer
ID: 23195
Updated by: [EMAIL PROTECTED]
-Summary: Use of $_POST/$_SESSION causes a endless loop
Reported By: jc at mega-bucks dot co dot jp
Status: Open
-Bug Type: Documentation problem
+Bug Type: Arrays related
Operating System: Red Hat Linux 8.0
PHP Version: 4.3.2RC1
New Comment:
This makes no sense to me, why would assigning an array to another
variable affect the original arrays pointer? Even the array it's
assigned to keeps the original pointer:
?php
$array = array('a','b','c');
print 1: . current($array) . \n; // a
print 2: . next($array). \n; // b
$array2 = $array;
print 3: . current($array) . \n; // a
print 4: . current($array2). \n; // b
?
Either $array should also keep its pointer or $array2 should also have
a reset pointer. I'd assume both would keep the current pointer, or
maybe just $array2 would have a reset pointer :). Current behavior is
certainly not documented, and are you guys sure this isn't a bug?
Previous Comments:
[2003-04-25 00:10:48] jc at mega-bucks dot co dot jp
Thanks for looking into this, but I cannot find anywhere in the
documenation that states that assigning an array to a variable resets
the array's pointer to the first element. Can you point me to such
documentation?
Furthermore if you are right, and I'm sure you are, then some of the
documentation is wrong or confusing at best. Consider the following
from the docs:
http://www.php.net/manual/en/control-structures.foreach.php
The following are also functionally identical:
reset ($arr);
while (list($key, $value) = each ($arr)) {
echo Key: $key; Value: $valuebr\n;
}
foreach ($arr as $key = $value) {
echo Key: $key; Value: $valuebr\n;
}
But has you said, those are *not* functionally identical.
Or from http://www.php.net/manual/en/function.each.php
each() is typically used in conjunction with list() to traverse an
array; for instance, $_POST:
Example 2. Traversing $_POST with each()
echo Values submitted via POST method:br /\n;
reset ($_POST);
while (list ($key, $val) = each ($_POST)) {
echo $key = $valbr /\n;
}
Reading the documentation on each() and on arrays the above two
examples teach that using a while(list() = each()) is a correct way of
traversing an array. Which it obviously is *not* if you plan on
assigning the array you are traversing to a variable ...
Either the each() function should be removed to force the use of the
assignment-safe 'foreach()' or the documentation should mention that
when assigning an array to a variable the current element-pointer is
reset.
[2003-04-24 19:49:05] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When you assign the array to another variable the internal array
position pointer gets reset. Which causes you loop which depends on the
array position to loop indefinately.
Use foreach() or a for() loop.
[2003-04-18 21:19:43] [EMAIL PROTECTED]
Here is a shorter example that demonstrates the problem:
?php
$arr = array('a', 'b');
while (each($arr)) $arr2 = $arr;
?
[2003-04-14 01:15:09] jc at mega-bucks dot co dot jp
The following piece of code never terminates:
?php
while (list($k, $v) = each( $_POST )) {
if(strstr($k, CHANGE_DEL_DATES)) {
session_set_post_vars( $_POST );
}
}
function session_set_post_vars($post) {
$_SESSION[S_POST_VALUES] = $post;
}
?
The contents of the $_POST superglobal were:
Array
(
[CURRENT_DEL_METHOD] = YAMATO
[DEL_YEAR1] = 2003
[DEL_MONTH1] = 04
[DEL_DAY1] = 12
[ptime1] = 1
[DEL_YEAR2] = 2003
[DEL_MONTH2] = 04
[DEL_DAY2] = 12
[DEL_YEAR3] = 2003
[DEL_MONTH3] = 04
[DEL_DAY3] = 12
[DELIVER_ANYDAY] = on
[CHANGE_DEL_DATES_x] = 14
[CHANGE_DEL_DATES_y] = 7
)
--
Edit this bug report at http://bugs.php.net/?id=23195edit=1
