#27555 [Bgs->Opn]: Unable to modify $_SESSION from __destruct()
ID: 27555 User updated by: jaanus at heeringson dot com Reported By: jaanus at heeringson dot com -Status: Bogus +Status: Open Bug Type: Session related Operating System: Linux 2.4.24 PHP Version: 5CVS-2004-03-10 (dev) New Comment: Yes, but that is not the issue here, is it? What this bug is about is the unability to add session variables from __destruct(). Obviously you have to reload the page to se the effect on the real session. The [destructor] => Yes will NEVER appear in $_SESSION. Previous Comments: [2004-03-10 19:50:59] [EMAIL PROTECTED] If you put something like "echo 'this happens now';" line in the __destruct() call you will see that it's executed AFTER your print_r() line. This is correct behaviour. [2004-03-10 18:42:06] jaanus at heeringson dot com Description: Unable to add session variables from the __destruct() handler in a class. The $_SESSION variable can be accessed and viewed in the __destruct() handler though. Reproduce code: --- Expected result: Array ( [destructor] => Yes [working] => Yes ) Actual result: -- Array ( [working] => Yes ) -- Edit this bug report at http://bugs.php.net/?id=27555&edit=1
#27561 [Opn->Bgs]: header("Location:.....");
ID: 27561
Updated by: [EMAIL PROTECTED]
Reported By: ignatius at act28 dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: WinXP
PHP Version: 4.3.4
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Blame microsoft! - they have disabled this by default in the latest
update to IE.
Previous Comments:
[2004-03-11 00:27:32] ignatius at act28 dot com
Description:
Why can't I do this:
header("Location: http://user:[EMAIL PROTECTED]");
NS7 will redirect happily, but displays the user:pass in clear in the
address bar and changes all the in-page links to match the address bar
url.
IE will not play the game at all.
Reproduce code:
---
header("Location: http://user:[EMAIL PROTECTED]");
Expected result:
Browser redirects to http://myserver.com and authentication is passed
across to the basic auth relam.
Actual result:
--
As described above
--
Edit this bug report at http://bugs.php.net/?id=27561&edit=1
#27562 [NEW]: Freetds 0.62.1
From: fielker at informatik dot fh-augsburg dot de
Operating system: Linux x86
PHP version: 4.3.4
PHP Bug Type: MSSQL related
Bug description: Freetds 0.62.1
Description:
When using Freetds 0.62.1 i can't call stored procedures.
At last - there is no result
Freetds 0.62.1 gives me always an empty result. Using the
comandline of freetds (tsql) works:
1> sp_help
2> go
I use M$ SQL 2000 with M$ Win 2000 Server.
Reproduce code:
---
This works with Freetds 0.61.0 but not with 0.62.1:
$db = sybase_connect("host", "user", "passwort" );
$q = sybase_query("sp_help", $db);
while($row = sybase_fetch_row($q)) {
while(list($k, $v) = each($row)) {
echo "\$row[$k] => $v\n";
}
}
--
Edit bug report at http://bugs.php.net/?id=27562&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27562&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27562&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27562&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27562&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27562&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27562&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27562&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27562&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27562&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27562&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27562&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27562&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27562&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27562&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27562&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27562&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27562&r=float
#19022 [Com]: PHP Warning: Failed to write session data (files)
ID: 19022 Comment by: haccel at email dot com Reported By: phpbugs at mx4k dot com Status: No Feedback Bug Type: Session related Operating System: linux (rh7.3), apache 1.3.26 PHP Version: 4.2.2 New Comment: After weeks of testing, I have fixed the problem at least for me. The problem is the Zend Optimizer was corrupting/wiping (presumably) the session data. Turning Zend Optimizer off completely fixed the problem. When I turned Zend Optimizer back on and rebooted the session problem was back again, this is the first reproducible action for me so far. Would be interesting to know how many others with this problem have Zend Optimizer running. Previous Comments: [2004-03-01 20:15:09] stewart dot james at vu dot edu dot au Just started to expience this after a shift to a new server. php 4.3.3 on Debian Sarge I get the error when I return to the site after logging out. Looking at the cookie data the cookie data PHPSESSID is being set to null, which my browser is recording in it's cookie database. Then on return the site attempts to access informaiotn for PHPSESSID=(NULL) which is what I think is causing the problem with this error. Does anyone else see the same problem on their respective sites? Stewart [2004-01-21 08:45:26] august24_70 at yahoo dot com I was having the problem on OpenBSD 3.2, Apache 1.3.26, PHP 3.2.3 when running phpBB. I deleted all my cookies and logged back in again and the problem went. I don't use cookies for handling sessions, I pass it in the URL. ie session.use_trans_sid = 1 [2004-01-19 21:02:22] haccel at email dot com I also have been receiving this error since Jan 1st, 2004. Running on Linux operating system, Apache version 1.3.29 (Unix), PHP version 4.3.3 My error log is full of these errors: PHP Warning: Unknown(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/usr/home/asdwq1/sessions) in Unknown on line 0 PHP Warning: session_start(): The session id contains invalid characters, valid characters are only a-z, A-Z and 0-9 in /usr/home/asdwq1/public_html/index.php on line 2 Line 2 of index.php = session_start(); Strange thing is it only happens some of the time. I use SID throughout so how can php create a session id and then say on the next page it is an invalid session id? I don't quite understand how it can be invalid when php creates this upon the call of the first session_start(). $_SESSION vars are only used and it occurs where-ever I move the session temp directory to. [2004-01-19 17:01:48] oliver at realnet dot org I was having the same problem, failed to write session data files, check your save path error. Worked fine in Netscape 7.1, but not in IE 6. I deleted my cookies, cleared history, deleted internet files, and rebooted. It worked like a charm after that. I don't know how that would affect it, but that's all I did... and like I say, it always worked, everytime in Netscape 7.1. [2004-01-11 20:19:52] lennaert dot goris at ellips dot ws I am working on a PII 350 dev machine. php 4.3.4/apache 2.0.48 same problem used PEAR::Auth module and discoverd this bug. I can't seem to get rid of it. Tried all of the solutions presented on this site save from installing windows on my machine. I'm gonna try to recreate this bug on my laptop at work (winxp). See what happens there. 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/19022 -- Edit this bug report at http://bugs.php.net/?id=19022&edit=1
#27561 [NEW]: header("Location:.....");
From: ignatius at act28 dot com
Operating system: WinXP
PHP version: 4.3.4
PHP Bug Type: *General Issues
Bug description: header("Location:.");
Description:
Why can't I do this:
header("Location: http://user:[EMAIL PROTECTED]");
NS7 will redirect happily, but displays the user:pass in clear in the
address bar and changes all the in-page links to match the address bar
url.
IE will not play the game at all.
Reproduce code:
---
header("Location: http://user:[EMAIL PROTECTED]");
Expected result:
Browser redirects to http://myserver.com and authentication is passed
across to the basic auth relam.
Actual result:
--
As described above
--
Edit bug report at http://bugs.php.net/?id=27561&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27561&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27561&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27561&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27561&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27561&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27561&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27561&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27561&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27561&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27561&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27561&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27561&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27561&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27561&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27561&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27561&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27561&r=float
#27554 [Opn->Bgs]: GTK installation failed
ID: 27554 Updated by: [EMAIL PROTECTED] Reported By: timon at digitalforce dot ch -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Suse Linux 9.0 PHP Version: Irrelevant New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. hint: try installing php-devel packages. Previous Comments: [2004-03-10 18:17:30] timon at digitalforce dot ch Description: Hello my dearest i am trying to install PHP-GTK (Version 0.5 and/or 1.0) on my machine (SUSE-Linux 9.0) in both cases when i call the #./buildconf shellscript i get the following error. make: phpize: Kommando nicht gefunden make: *** [buildmk.stamp] Fehler 127 the above is in german an will mean make: phpize: command not found make: *** [buildmk.stamp] error 127 so whats the problem? -- Edit this bug report at http://bugs.php.net/?id=27554&edit=1
#17234 [Com]: setting short_open_tag in .htaccess does nothing
ID: 17234
Comment by: darren at dzr-web dot com
Reported By: php at rawhide dot cjb dot net
Status: No Feedback
Bug Type: Apache2 related
Operating System: Windows XP
PHP Version: 4.2.1
New Comment:
On Red Hat Linux 9, with Apache 2.0.40 and PHP 4.2.2, attempting to
change short_open_tag from .htaccess also fails. I've tried both:
php_value short_open_tag Off
and
php_flag short_open_tag Off
and neither has any effect. Changing the value in /etc/php.ini does.
I'm not sure which version number PHP was at when comment #8 below was
posted, suggesting that a recent CVS version be tested, but I am
guessing that 4.2.2 postdates that. This is precisely what I have
installed:
httpd-2.0.40-21.9
httpd-devel-2.0.40-21.9
httpd-manual-2.0.40-21.9
php-4.2.2-17.2
php-devel-4.2.2-17.2
php-imap-4.2.2-17.2
php-ldap-4.2.2-17.2
php-manual-4.2.2-17.2
php-mysql-4.2.2-17.2
php-odbc-4.2.2-17.2
php-pgsql-4.2.2-17.2
php-snmp-4.2.2-17.2
Previous Comments:
[2002-10-08 21:39:45] [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-16 10:34:36] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-09-05 11:35:08] gbenson at redhat dot com
I'm seeing this problem too, and it only seems to effect
short_open_tag. In my setup, /etc/php.ini says:
register_globals = Off
short_open_tag = Off
and I have the following in a file which is included by httpd.conf:
php_value register_globals 1
php_value short_open_tag 1
A phpinfo() in /foo/bar/baz/phpinfo.php says:
Directive Local value Global value
register_globals OnOff
short_open_tag Off Off
ie, php_value worked for register_globals but not for short_open_tag.
[2002-05-17 03:45:39] [EMAIL PROTECTED]
That last problem you mentioned ("Invalid command 'php_flag'") is fixed
in CVS, just so you know.
[2002-05-15 19:28:19] php at rawhide dot cjb dot net
Error message:
/.htaccess: Invalid command 'php_flag', perhaps mis-spelled
or defined by a module not included in the server configuration.
This isn't bogus yet.
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/17234
--
Edit this bug report at http://bugs.php.net/?id=17234&edit=1
#27559 [NEW]: open_basedir + tempnam, move_uploaded_file and copy problems
From: viktors at rotanovs dot com Operating system: Linux PHP version: 4.3.5RC3 PHP Bug Type: Filesystem function related Bug description: open_basedir + tempnam, move_uploaded_file and copy problems Description: I get the following message when using tempnam() function: tempnam(): open_basedir restriction in effect. File(/opt/tmp/php) is not within the allowed path(s): (/www:/opt/php/lib/php:/opt/tmp/uploads:/etc/usermap:/opt/tmp/php) in /www/foto.inbox.lv/util.php on line 1492 Note that /opt/tmp/php _is_ within a list of allowed paths. Similar errors with copy() and move_uploaded_file(). -- Edit bug report at http://bugs.php.net/?id=27559&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27559&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27559&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27559&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27559&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27559&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27559&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27559&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27559&r=support Expected behavior: http://bugs.php.net/fix.php?id=27559&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27559&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27559&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27559&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27559&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27559&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27559&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27559&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27559&r=float
#27486 [Fbk->NoF]: PHP Warning: system(): Unable to fork
ID: 27486
Updated by: [EMAIL PROTECTED]
Reported By: donny at intercosmos dot com
-Status: Feedback
+Status: No Feedback
Bug Type: CGI related
Operating System: Linux 2.6.2 /Fedora Core 1,
PHP Version: 4.3.4
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:
[2004-03-05 18:57:15] [EMAIL PROTECTED]
The only thing I can think of is that you're running out of filehandles
on your system. Can you try raising the limit and see if this fixed it?
(or makes it run longer correctly) Please make also sure that you
always close sockets when running in a deamon mode like this.
Perhaps you can put up a short reproducing script as well? (Without any
use of external resources then)
regards,
Derick
[2004-03-04 09:56:03] donny at intercosmos dot com
Quick explanation.
1. Parent Program, grabs a list of 25 domains, and then spawns off 25
children to process the domain. The parent does a mysql get lock on
the domain, and once the child process is done, it tells mysql to
release the lock which tells the parent the child is finished. Once
all 25 domains are finished the parent spawns a new instance of itself
and the original parent exits.
2. The child programs in certain cases can spawn children of their
own, but never more than 1 or 2 children. This keeps the code small
and effecient.
Hope this makes sense.
[2004-03-04 03:29:16] [EMAIL PROTECTED]
What does that new program that spawns these children do? Is it a long
living process?
[2004-03-03 18:35:31] donny at intercosmos dot com
Description:
We started using a new program that spawns additional CLI php scripts
recently. And today, we started getting stuff like this:
PHP Warning: system(): Unable to fork [/usr/bin/php
/www/htdocs/onetime/spawn_domain.php 'businesslicensing.com' >
/dev/null &] in /www/htdocs/onetime/spawn_domain_parent.php on line 39
Now if I wait a few minutes, and restart the parent it will normally go
on about it's business. But then after a while it will all of a sudden
no longer be able to spawn new children.
All of the other bugs mentioned like this are based on Windows, but
this is a Linux box.
Reproduce code:
---
system("/usr/bin/php /www/htdocs/onetime/spawn_domain.php
'$db[domain]' > /dev/null &");
Expected result:
It should spawn a child CLI program and run.
Actual result:
--
It runs the code mentioned above.
--
Edit this bug report at http://bugs.php.net/?id=27486&edit=1
#27490 [Fbk->Csd]: system function produces garbage with zlib.output_copmression
ID: 27490
Updated by: [EMAIL PROTECTED]
Reported By: mortoray at ecircle-ag dot com
-Status: Feedback
+Status: Closed
Bug Type: Zlib Related
Operating System: Windows NT 5.0 build 219
PHP Version: 4.3.4
Previous Comments:
[2004-03-07 22:24:33] scottmacvicar at ntlworld dot com
http://bugs.php.net/bug.php?id=27424 has been fixed and i tested the
reproduce code which is now working as expected.
[2004-03-05 20:37:01] scottmacvicar at ntlworld dot com
Duplicate of http://bugs.php.net/bug.php?id=27424
In the case of apache2 sapi_flush sends any pending headers and
prevents any further headers being sent unlike Apache 1.
Call to sapi_flush is within php_Exec on line 247 in
ext/standard/exec.c
[2004-03-05 18:52:01] [EMAIL PROTECTED]
Does it work if you set the header yourself with:
header('Content-Encoding: gzip');
?
regards,
Derick
[2004-03-04 04:11:45] mortoray at ecircle-ag dot com
Description:
Using the zlib.output_compression=On and the function system() produces
garbage output to the browser. Specifically, it does a gzip encoding
but omits the "Content-Encoding: gzip" header.
Using "passthru" instead of "system" works as intended.
Turning off compression and using "system" works as intended.
Reproduce code:
---
Expected result:
Either system() should somehow turn off the zlib compression or its
output should be compressed properly and the proper headers should be
set.
--TCP Flow with passthru()--
GET /dir.php HTTP/1.0
Host: qatest.ecircle.de:8080
Accept: text/*, image/jpeg, image/png, image/*, */*
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux; en_US, en)
HTTP/1.1 200 OK
Date: Thu, 04 Mar 2004 09:12:41 GMT
Server: Apache/2.0.45 (Win32) PHP/4.3.4
X-Powered-By: PHP/4.3.4
Content-Encoding: gzip
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=ISO-8859-1
...S=O.0..+.?...X.J.-..dAbb`...kk5q...e..sm.
m"q.{.C.5c...1,!..b
}.MYb.p{..Ks.x_x.25..!..5..I.5..._..?.."a\.B|..ji...Iw..*i.[yE..
.-.~N.W.'.Xmy).7V.n.,sE.yer.I||...c..4...?f...Y.gWh!..h.);?.v...O.:H.A1...U6.^..6..z...d..g...5..nz.M.XWaM..o%...>..7
..5.cy6.K.aB..f..p.
..`...
...
Actual result:
--
--TCP Flow with system()--
GET /dir.php HTTP/1.0
Host: qatest.ecircle.de:8080
Accept: text/*, image/jpeg, image/png, image/*, */*
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Language: en
Cache-control: no-cache
Pragma: no-cache
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux; en_US, en)
HTTP/1.1 200 OK
Date: Thu, 04 Mar 2004 09:13:45 GMT
Server: Apache/2.0.45 (Win32) PHP/4.3.4
X-Powered-By: PHP/4.3.4
Connection: close
Content-Type: text/html; charset=ISO-8859-1
...S.n.0..#..{..X.J.\*..CO\...E..B"un.c...Ma..hA.x.+.r.nUO..2.!..U..F...".'.o...h.$...:.9.L..u`q...$.
@.Pxp.sW..3.*|...*B...t.)H..,S.vK..*.J..A.gYn..T.$L.=...8..Q.I{..7X.]A..)M,..g3<.=^_0.uZZ..^.#..M..L.wPL).N.V.!;..Al!o.(Q)k3.O.u.5..
..i.OM.$N.q.K4 >[EMAIL PROTECTED]|{...P.0...>..6...
%.78n.~..C
...
--
Edit this bug report at http://bugs.php.net/?id=27490&edit=1
#27500 [Fbk->NoF]: get_browser
ID: 27500 Updated by: [EMAIL PROTECTED] Reported By: cvachon at bluenodes-technologies dot com -Status: Feedback +Status: No Feedback Bug Type: Output Control Operating System: XP PHP Version: 4.3.5RC3 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: [2004-03-05 11:51:10] [EMAIL PROTECTED] Could you check to make sure you're not experiencing the same problem as has been reported in bug #27372? http://bugs.php.net/bug.php?id=27372 J [2004-03-04 18:23:54] cvachon at bluenodes-technologies dot com Description: Hi! I downloaded the latest "browsecap.ini" (2004-02-29 23:03:10 GMT ) file yesterday and it generates a bug within PHP function "get_browser". This function is supposed to return an Object but with this file version, it returns nothing. I have PHP 4.3.5RC3 under XP. And I even tried downgrading to my last PHP version (4.3.4RC3) and the result is the same... My conclusion is based on the fact that I downgraded to an ancient version of the file "browsecap.ini" (2003-09-21 22:04:18 GMT) and it's working with this one... Thanks! Reproduce code: --- $browser = get_browser($_SERVER["HTTP_USER_AGENT"]); Expected result: Object Actual result: -- //* $browser is null and does not have any properties set. -- Edit this bug report at http://bugs.php.net/?id=27500&edit=1
#27555 [Opn->Bgs]: Unable to modify $_SESSION from __destruct()
ID: 27555 Updated by: [EMAIL PROTECTED] Reported By: jaanus at heeringson dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Linux 2.4.24 PHP Version: 5CVS-2004-03-10 (dev) New Comment: If you put something like "echo 'this happens now';" line in the __destruct() call you will see that it's executed AFTER your print_r() line. This is correct behaviour. Previous Comments: [2004-03-10 18:42:06] jaanus at heeringson dot com Description: Unable to add session variables from the __destruct() handler in a class. The $_SESSION variable can be accessed and viewed in the __destruct() handler though. Reproduce code: --- Expected result: Array ( [destructor] => Yes [working] => Yes ) Actual result: -- Array ( [working] => Yes ) -- Edit this bug report at http://bugs.php.net/?id=27555&edit=1
#27558 [Opn->Fbk]: Location HTTP header failure
ID: 27558
Updated by: [EMAIL PROTECTED]
Reported By: jeff at qoolio dot org
-Status: Open
+Status: Feedback
Bug Type: Output Control
Operating System: Linux
PHP Version: 5.0.0b4 (beta4)
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
And does this happen with PHP 4.3.4 ?
Previous Comments:
[2004-03-10 19:46:16] jeff at qoolio dot org
Description:
I am using PHP5 beta 4 and am experiencing a failure to redirect when
using the header() function with the Location HTTP header. I have found
that adding a print(" ") line after the header() call results in a
successful redirect.
My configuration is:
#!/bin/sh
./configure \
--prefix=/opt \
--enable-inline-optimization \
--disable-short-tags \
--with-apache-hooks=/opt/httpd/bin/apxs \
--disable-cgi \
--with-sqlite \
--enable-sysvshm \
--enable-sysvsem \
--enable-sysvmsg \
--with-zlib=/usr \
--with-libxml-dir \
--with-gd \
--with-jpeg-dir \
--with-png-dir \
--with-zlib-dir \
--with-ttf \
--with-freetype-dir \
--with-mysql=/usr \
--with-pgsql \
--with-expat-dir=/usr \
--with-xsl \
--enable-exif \
--enable-soap \
--with-xmlrpc
This problem happens whether the .ini setting for output_buffering is
On or Off. I have no special settings in my php.ini.
Reproduce code:
---
http://www.php.net/";);
?>
This code fails to redirect.
http://www.php.net/";);
print(" ");
?>
This code succesfully redirects
For now, this can be tested at:
http://blog.qoolio.org:82/header_test.php (w/o print)
http://blog.qoolio.org:82/header_test2.php (w/print)
Expected result:
Successful HTTP redirect via Location header.
Actual result:
--
Failure to redirect.
--
Edit this bug report at http://bugs.php.net/?id=27558&edit=1
#27558 [NEW]: Location HTTP header failure
From: jeff at qoolio dot org
Operating system: Linux
PHP version: 5.0.0b4 (beta4)
PHP Bug Type: Output Control
Bug description: Location HTTP header failure
Description:
I am using PHP5 beta 4 and am experiencing a failure to redirect when
using the header() function with the Location HTTP header. I have found
that adding a print(" ") line after the header() call results in a
successful redirect.
My configuration is:
#!/bin/sh
./configure \
--prefix=/opt \
--enable-inline-optimization \
--disable-short-tags \
--with-apache-hooks=/opt/httpd/bin/apxs \
--disable-cgi \
--with-sqlite \
--enable-sysvshm \
--enable-sysvsem \
--enable-sysvmsg \
--with-zlib=/usr \
--with-libxml-dir \
--with-gd \
--with-jpeg-dir \
--with-png-dir \
--with-zlib-dir \
--with-ttf \
--with-freetype-dir \
--with-mysql=/usr \
--with-pgsql \
--with-expat-dir=/usr \
--with-xsl \
--enable-exif \
--enable-soap \
--with-xmlrpc
This problem happens whether the .ini setting for output_buffering is On
or Off. I have no special settings in my php.ini.
Reproduce code:
---
http://www.php.net/";);
?>
This code fails to redirect.
http://www.php.net/";);
print(" ");
?>
This code succesfully redirects
For now, this can be tested at:
http://blog.qoolio.org:82/header_test.php (w/o print)
http://blog.qoolio.org:82/header_test2.php (w/print)
Expected result:
Successful HTTP redirect via Location header.
Actual result:
--
Failure to redirect.
--
Edit bug report at http://bugs.php.net/?id=27558&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27558&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27558&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27558&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27558&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27558&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27558&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27558&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27558&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27558&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27558&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27558&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27558&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27558&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27558&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27558&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27558&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27558&r=float
#27553 [Opn->Fbk]: odbc.ini file descriptors left open
ID: 27553
Updated by: [EMAIL PROTECTED]
Reported By: bradleyb at trans-soft dot net
-Status: Open
+Status: Feedback
-Bug Type: Apache related
+Bug Type: ODBC related
Operating System: redhat 9
PHP Version: 4.3.4
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
Also give us your full configure line used to configure PHP.
Previous Comments:
[2004-03-10 18:00:49] bradleyb at trans-soft dot net
Description:
When i make a connection to my sybase db using odbc_connect, apache
leaves the odbc.ini file open even thought i call odbc_close().
I am unable to figure out how to get these files closed. I have done
quite a bit of research but am unable to locate any one who has
experienced this issue.
Apache is the User assigned to the file which is located ->
etc/odbc.ini
At the top of each page that i load is an include statement that
creates a connection to the db. When i have finished running my query
(odbc_do()), i call odbc_close().
For each page that is loaded, a new instance of odbc.ini is opened for
each call to odbc_connect().
I verify this by using -> lsof odbc.ini in the etc/ directory.
Reproduce code:
---
$db = odbc_connect($DSN, $dbUserName, $dbPassWord);
if(!$db)
{
die("Failure to connect to DB");
}
if(@ $dbResource = odbc_do($db, $query))
{
if(@ odbc_fetch_row($dbResource))
{
$myData = odbc_result $dbResource, "ColumnName");
}
odbc_close($db);
}
Expected result:
The odbc.ini file descriptor located in the etc/ directory to be
closed.
Actual result:
--
file is left open?
lsof odbc.ini
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
httpd 20268 apache8r REG3,6 1105 244685 odbc.ini
--
Edit this bug report at http://bugs.php.net/?id=27553&edit=1
#27556 [Opn->Fbk]: argc not working correctly
ID: 27556 Updated by: [EMAIL PROTECTED] Reported By: stan at workflowinc dot com -Status: Open +Status: Feedback -Bug Type: *General Issues +Bug Type: CGI related Operating System: Windows XP PHP Version: 4CVS-2004-03-11 (dev) New Comment: Works fine for me. How exactly are you running the script? And are you using CLI or CGI? Previous Comments: [2004-03-10 19:02:36] stan at workflowinc dot com Description: $_SERVER['argv'] is not detecting any arguments (register_argc_argv in php.ini is turned on). I'm actually working with 4.3.5RC4-dev, it wasn't on the list. Reproduce code: --- Expected result: Array ( [0] => test.php [1] => arg1 ) Actual result: -- Array ( [0] => test.php ) -- Edit this bug report at http://bugs.php.net/?id=27556&edit=1
#27557 [NEW]: DB2 odbc_fetch_row with single row returns invalid result
From: admin at db-hq dot net
Operating system: Linux - Fedora Core 1
PHP version: 4.3.4
PHP Bug Type: ODBC related
Bug description: DB2 odbc_fetch_row with single row returns invalid result
Description:
I am working on porting phpbb over to DB2, and ran into an error with
odbc_fetch_row. When the following SQL is executed:
SELECT * FROM phpbb_fourms WHERE forum_id = 1
odbc_fetch_row($result_id, $i) returns false. Where i = 1.
Sending the query to the database returns one row. When I remove the $i
from odbc_fetch_row it works perfectly. Also if more than one result is
returned there is no problem. Also it seems to only occur when there is a
select * or when there is a large number of columns returning a single
row.
I am pretty sure I have experienced this bug since the early 4.0.* days.
Reproduce code:
---
$i = 1;
$k = 0;
while(odbc_fetch_row($result_id, $i) && $k <
$this->result_numrows[$result_id]){
for($j = 1; $j < count($this->result_field_names[$result_id])+1; $j++){
$this->result_rowset[$result_id][$k][$this->result_field_names[$result_id][$j-1]]
= odbc_result($result_id, $j);
}
$i++;
$k++;
}
Expected result:
Expected odbc_fetch_row($result_id, $i) to return true.
Actual result:
--
odbc_fetch_row($result_id, $i) returned false if just one row was selected
from the database. If more than one row was selected it returned true and
worked fine.
Removing the $i from odbc_fetch_row() fixed the problem. None the less it
is still appears a bug. I also verified that the database query does
return one result.
--
Edit bug report at http://bugs.php.net/?id=27557&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27557&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27557&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27557&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27557&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27557&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27557&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27557&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27557&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27557&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27557&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27557&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27557&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27557&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27557&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27557&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27557&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27557&r=float
#27556 [NEW]: argc not working correctly
From: stan at workflowinc dot com Operating system: Windows XP PHP version: 4.3.5RC3 PHP Bug Type: Session related Bug description: argc not working correctly Description: $_SERVER['argv'] is not detecting any arguments (register_argc_argv in php.ini is turned on). I'm actually working with 4.3.5RC4-dev, it wasn't on the list. Reproduce code: --- Expected result: Array ( [0] => test.php [1] => arg1 ) Actual result: -- Array ( [0] => test.php ) -- Edit bug report at http://bugs.php.net/?id=27556&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27556&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27556&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27556&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27556&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27556&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27556&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27556&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27556&r=support Expected behavior: http://bugs.php.net/fix.php?id=27556&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27556&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27556&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27556&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27556&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27556&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27556&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27556&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27556&r=float
#27509 [Opn->Fbk]: fsockopen() failed with "Addr family not supported by protocol" error
ID: 27509 Updated by: [EMAIL PROTECTED] Reported By: scott at abcoa dot com -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: AIX 4.3.3 PHP Version: 4.3.4 New Comment: First off, thanks for being so patient and helpful. I'd like to ask you to apply a small patch which introduces several debug watchpoints. Then compile, run your test script, and post the results (they'll be a bit on the verbose side). http://169.229.135.175/test/27509-diff.txt Previous Comments: [2004-03-10 16:23:39] scott at abcoa dot com Oh I forgot! I did the "rm config.cache" and "make clean" before using this configure line, "./configure --enable-sockets". [2004-03-10 16:20:52] scott at abcoa dot com In response to [EMAIL PROTECTED]'s comment... Removed the config.cache, rebuild PHP with "./configure --disable-all --disable-cgi", ran the test script using CLI and still get this same error message. --snip-- !#/usr/local/bin/php Warning: fsockopen(): unable to connect to www.google.com:80 in <> on line 6 66 Addr family not supported by protocol --snip-- It had been observed that during most of those compilation using "make" I saw this warning messages. I don't think this is related to socket stuffs but thought you may would to know. -snip-- gcc -Iext/standard/ -I/usr/local/src3/php4-STABLE-200403081230/ext/standard/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend -I/usr/local/src3/php4-STABLE-200403081230/TSRM -O2 -c /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c -o ext/standard/file.o && echo > ext/standard/file.lo /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c: In function `zif_fgetcsv': /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c:2308: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c:2373: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type gcc -Iext/standard/ -I/usr/local/src3/php4-STABLE-200403081230/ext/standard/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend -I/usr/local/src3/php4-STABLE-200403081230/TSRM -O2 -c /usr/local/src3/php4-STABLE-200403081230/ext/standard/filestat.c -o ext/standard/filestat.o && echo > ext/standard/filestat.lo --snip-- In response to [EMAIL PROTECTED]'s comment... >>whether there are "lingering ghosts" of >>the prior version. Could be, I wouldn't deny it. The error message you saw in the original report was the output from the website. The ./configure command line was --snip-- ./configure --with-apache=../apache_1.3.27 --with-ibm-db2=/usr/lpp/db2_06_01 --with-openssl --with-mcrypt --with-curl --without-mysql --enable-track-vars --snip-- Since then, I found that I can produce this error through the CLI, so I did away with the website and use CLI instead because it is alot quicker to recompile than it is with PHP and webserver. Since then there have been a numerous recompiling as instructed by this bug report. >>Can you confirm that you're still getting that >>specific error message in your output? I can confirm that the "php_hostconnect" does not exist anymore. I am unable to reproduce this "php_hostconnect" error this time. I don't remember what I did to make this happen. All I know is that it was as result of fiddling around with the wording in the fsockopen()'s parameter arguements to find out what work and what doesn't. >>Of course, you'll need to ./configure --enable-sockets >>in order to try these tests. Okay, did the favor and recompile it with "./configure --enable-sockets" configure line. Saw two warning messages, one from above and other is --snip-- gcc -Iext/sockets/ -I/usr/local/src3/php4-STABLE-200403081230/ext/sockets/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend -I/usr/local/src3/php4-STABLE-200403081230/ext/xml/expat -I/usr/local/src3/php4-STABLE-200403081230/TSRM -O2 -c /usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c -o ext/sockets/sockets.o && echo > ext/sockets/sockets.lo /usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c: In function `php_strerror': /usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c:350: warning: assignment makes pointer from integer without a cast
#27555 [NEW]: Unable to modify $_SESSION from __destruct()
From: jaanus at heeringson dot com Operating system: Linux 2.4.24 PHP version: 5CVS-2004-03-10 (dev) PHP Bug Type: Session related Bug description: Unable to modify $_SESSION from __destruct() Description: Unable to add session variables from the __destruct() handler in a class. The $_SESSION variable can be accessed and viewed in the __destruct() handler though. Reproduce code: --- Expected result: Array ( [destructor] => Yes [working] => Yes ) Actual result: -- Array ( [working] => Yes ) -- Edit bug report at http://bugs.php.net/?id=27555&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27555&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27555&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27555&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27555&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27555&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27555&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27555&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27555&r=support Expected behavior: http://bugs.php.net/fix.php?id=27555&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27555&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27555&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27555&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27555&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27555&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27555&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27555&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27555&r=float
#27554 [NEW]: GTK installation failed
From: timon at digitalforce dot ch Operating system: Suse Linux 9.0 PHP version: Irrelevant PHP Bug Type: Unknown/Other Function Bug description: GTK installation failed Description: Hello my dearest i am trying to install PHP-GTK (Version 0.5 and/or 1.0) on my machine (SUSE-Linux 9.0) in both cases when i call the #./buildconf shellscript i get the following error. make: phpize: Kommando nicht gefunden make: *** [buildmk.stamp] Fehler 127 the above is in german an will mean make: phpize: command not found make: *** [buildmk.stamp] error 127 so whats the problem? -- Edit bug report at http://bugs.php.net/?id=27554&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27554&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27554&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27554&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27554&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27554&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27554&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27554&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27554&r=support Expected behavior: http://bugs.php.net/fix.php?id=27554&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27554&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27554&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27554&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27554&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27554&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27554&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27554&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27554&r=float
#27553 [NEW]: odbc.ini file descriptors left open
From: bradleyb at trans-soft dot net
Operating system: redhat 9
PHP version: 4.3.4
PHP Bug Type: Apache related
Bug description: odbc.ini file descriptors left open
Description:
When i make a connection to my sybase db using odbc_connect, apache leaves
the odbc.ini file open even thought i call odbc_close().
I am unable to figure out how to get these files closed. I have done quite
a bit of research but am unable to locate any one who has experienced this
issue.
Apache is the User assigned to the file which is located -> etc/odbc.ini
At the top of each page that i load is an include statement that creates a
connection to the db. When i have finished running my query (odbc_do()),
i call odbc_close().
For each page that is loaded, a new instance of odbc.ini is opened for
each call to odbc_connect().
I verify this by using -> lsof odbc.ini in the etc/ directory.
Reproduce code:
---
$db = odbc_connect($DSN, $dbUserName, $dbPassWord);
if(!$db)
{
die("Failure to connect to DB");
}
if(@ $dbResource = odbc_do($db, $query))
{
if(@ odbc_fetch_row($dbResource))
{
$myData = odbc_result $dbResource, "ColumnName");
}
odbc_close($db);
}
Expected result:
The odbc.ini file descriptor located in the etc/ directory to be closed.
Actual result:
--
file is left open?
lsof odbc.ini
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
httpd 20268 apache8r REG3,6 1105 244685 odbc.ini
--
Edit bug report at http://bugs.php.net/?id=27553&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27553&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27553&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27553&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27553&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27553&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27553&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27553&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27553&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27553&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27553&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27553&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27553&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27553&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27553&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27553&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27553&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27553&r=float
#27509 [Opn]: fsockopen() failed with "Addr family not supported by protocol" error
ID: 27509 User updated by: scott at abcoa dot com Reported By: scott at abcoa dot com Status: Open Bug Type: Sockets related Operating System: AIX 4.3.3 PHP Version: 4.3.4 New Comment: Oh I forgot! I did the "rm config.cache" and "make clean" before using this configure line, "./configure --enable-sockets". Previous Comments: [2004-03-10 16:20:52] scott at abcoa dot com In response to [EMAIL PROTECTED]'s comment... Removed the config.cache, rebuild PHP with "./configure --disable-all --disable-cgi", ran the test script using CLI and still get this same error message. --snip-- !#/usr/local/bin/php Warning: fsockopen(): unable to connect to www.google.com:80 in <> on line 6 66 Addr family not supported by protocol --snip-- It had been observed that during most of those compilation using "make" I saw this warning messages. I don't think this is related to socket stuffs but thought you may would to know. -snip-- gcc -Iext/standard/ -I/usr/local/src3/php4-STABLE-200403081230/ext/standard/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend -I/usr/local/src3/php4-STABLE-200403081230/TSRM -O2 -c /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c -o ext/standard/file.o && echo > ext/standard/file.lo /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c: In function `zif_fgetcsv': /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c:2308: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c:2373: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type gcc -Iext/standard/ -I/usr/local/src3/php4-STABLE-200403081230/ext/standard/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend -I/usr/local/src3/php4-STABLE-200403081230/TSRM -O2 -c /usr/local/src3/php4-STABLE-200403081230/ext/standard/filestat.c -o ext/standard/filestat.o && echo > ext/standard/filestat.lo --snip-- In response to [EMAIL PROTECTED]'s comment... >>whether there are "lingering ghosts" of >>the prior version. Could be, I wouldn't deny it. The error message you saw in the original report was the output from the website. The ./configure command line was --snip-- ./configure --with-apache=../apache_1.3.27 --with-ibm-db2=/usr/lpp/db2_06_01 --with-openssl --with-mcrypt --with-curl --without-mysql --enable-track-vars --snip-- Since then, I found that I can produce this error through the CLI, so I did away with the website and use CLI instead because it is alot quicker to recompile than it is with PHP and webserver. Since then there have been a numerous recompiling as instructed by this bug report. >>Can you confirm that you're still getting that >>specific error message in your output? I can confirm that the "php_hostconnect" does not exist anymore. I am unable to reproduce this "php_hostconnect" error this time. I don't remember what I did to make this happen. All I know is that it was as result of fiddling around with the wording in the fsockopen()'s parameter arguements to find out what work and what doesn't. >>Of course, you'll need to ./configure --enable-sockets >>in order to try these tests. Okay, did the favor and recompile it with "./configure --enable-sockets" configure line. Saw two warning messages, one from above and other is --snip-- gcc -Iext/sockets/ -I/usr/local/src3/php4-STABLE-200403081230/ext/sockets/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend -I/usr/local/src3/php4-STABLE-200403081230/ext/xml/expat -I/usr/local/src3/php4-STABLE-200403081230/TSRM -O2 -c /usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c -o ext/sockets/sockets.o && echo > ext/sockets/sockets.lo /usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c: In function `php_strerror': /usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c:350: warning: assignment makes pointer from integer without a cast --snip-- Ran the sample test of the codes you posted, I included both by the way. Ran it through the CLI and here's the response I got... --snip-- Content-type: text/html X-Powered-By: PHP/4.3.5RC4-dev !#/usr/local/bin/php resource(1) of type (Socket) bool(true) resource(2) of type (Socket) bool(true) --snip-- [2004-03-10 14:03:
#27509 [Fbk->Opn]: fsockopen() failed with "Addr family not supported by protocol" error
ID: 27509 User updated by: scott at abcoa dot com Reported By: scott at abcoa dot com -Status: Feedback +Status: Open Bug Type: Sockets related Operating System: AIX 4.3.3 PHP Version: 4.3.4 New Comment: In response to [EMAIL PROTECTED]'s comment... Removed the config.cache, rebuild PHP with "./configure --disable-all --disable-cgi", ran the test script using CLI and still get this same error message. --snip-- !#/usr/local/bin/php Warning: fsockopen(): unable to connect to www.google.com:80 in <> on line 6 66 Addr family not supported by protocol --snip-- It had been observed that during most of those compilation using "make" I saw this warning messages. I don't think this is related to socket stuffs but thought you may would to know. -snip-- gcc -Iext/standard/ -I/usr/local/src3/php4-STABLE-200403081230/ext/standard/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend -I/usr/local/src3/php4-STABLE-200403081230/TSRM -O2 -c /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c -o ext/standard/file.o && echo > ext/standard/file.lo /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c: In function `zif_fgetcsv': /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c:2308: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c:2373: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type gcc -Iext/standard/ -I/usr/local/src3/php4-STABLE-200403081230/ext/standard/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend -I/usr/local/src3/php4-STABLE-200403081230/TSRM -O2 -c /usr/local/src3/php4-STABLE-200403081230/ext/standard/filestat.c -o ext/standard/filestat.o && echo > ext/standard/filestat.lo --snip-- In response to [EMAIL PROTECTED]'s comment... >>whether there are "lingering ghosts" of >>the prior version. Could be, I wouldn't deny it. The error message you saw in the original report was the output from the website. The ./configure command line was --snip-- ./configure --with-apache=../apache_1.3.27 --with-ibm-db2=/usr/lpp/db2_06_01 --with-openssl --with-mcrypt --with-curl --without-mysql --enable-track-vars --snip-- Since then, I found that I can produce this error through the CLI, so I did away with the website and use CLI instead because it is alot quicker to recompile than it is with PHP and webserver. Since then there have been a numerous recompiling as instructed by this bug report. >>Can you confirm that you're still getting that >>specific error message in your output? I can confirm that the "php_hostconnect" does not exist anymore. I am unable to reproduce this "php_hostconnect" error this time. I don't remember what I did to make this happen. All I know is that it was as result of fiddling around with the wording in the fsockopen()'s parameter arguements to find out what work and what doesn't. >>Of course, you'll need to ./configure --enable-sockets >>in order to try these tests. Okay, did the favor and recompile it with "./configure --enable-sockets" configure line. Saw two warning messages, one from above and other is --snip-- gcc -Iext/sockets/ -I/usr/local/src3/php4-STABLE-200403081230/ext/sockets/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend -I/usr/local/src3/php4-STABLE-200403081230/ext/xml/expat -I/usr/local/src3/php4-STABLE-200403081230/TSRM -O2 -c /usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c -o ext/sockets/sockets.o && echo > ext/sockets/sockets.lo /usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c: In function `php_strerror': /usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c:350: warning: assignment makes pointer from integer without a cast --snip-- Ran the sample test of the codes you posted, I included both by the way. Ran it through the CLI and here's the response I got... --snip-- Content-type: text/html X-Powered-By: PHP/4.3.5RC4-dev !#/usr/local/bin/php resource(1) of type (Socket) bool(true) resource(2) of type (Socket) bool(true) --snip-- Previous Comments: [2004-03-10 14:03:57] [EMAIL PROTECTED] I'm also concerned that you may not actually be testing against 4.3... One of the error messages you noted in your original report "php_hostconnect: connect failed in ..." only appears in PHP >pr
#27531 [Opn]: configure works, but make breaks when --enable-xslt and --with-xslt-sablot
ID: 27531 User updated by: mrowe at pointsystems dot com Reported By: mrowe at pointsystems dot com Status: Open Bug Type: XSLT related Operating System: Solaris 9 PHP Version: 4.3.4 New Comment: note: when i edited the include/php_sab_info.h file, i was sure to add the "\n" characters, so the file now looks like the single line you suggested: #define SAB_INFO "Cflags: -g -O2\nLibs: -L/www/sablot-1.0/lib -lexpat\nPrefix: /www/sablot-1.0" Previous Comments: [2004-03-10 14:26:17] mrowe at pointsystems dot com still no luck. i've tried the 4.3.4 release as well as the latest stable release. i've edited the include/php_sab_info.h files such that they are a single line (both had real line breaks in the distributions, as displayed by 'vi' and 'more'). for what it's worth, i tried [EMAIL PROTECTED]'s solution listed here: http://www.php.net/manual/en/ref.xslt.php. that's not doing anything productive either. i'm still getting as similar error message: /bin/sh /raid/people/psystems/download/php-4.3.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/xslt/ -I/raid/people/psystems/download/php-4.3.4/ext/xslt/ -DPHP_ATOM_INC -I/raid/people/psystems/download/php-4.3.4/include -I/raid/people/psystems/download/php-4.3.4/main -I/raid/people/psystems/download/php-4.3.4 -I/raid/people/psystems/download/php-4.3.4/Zend -I/usr/local/include -I/usr/include/libxml2 -I/raid/people/psystems/download/php-4.3.4/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/raid/people/psystems/download/php-4.3.4/TSRM -g -O2 -prefer-pic -c /raid/people/psystems/download/php-4.3.4/ext/xslt/sablot.c -o ext/xslt/sablot.lo In file included from /raid/people/psystems/download/php-4.3.4/ext/xslt/sablot.c:36: /raid/people/psystems/download/php-4.3.4/include/php_sab_info.h:1:18: missing terminating " character In file included from /raid/people/psystems/download/php-4.3.4/ext/xslt/sablot.c:36: /raid/people/psystems/download/php-4.3.4/include/php_sab_info.h:2: error: parse error before ':' token /raid/people/psystems/download/php-4.3.4/include/php_sab_info.h:3:19: missing terminating " character In file included from /usr/include/fcntl.h:24, from /raid/people/psystems/download/php-4.3.4/ext/xslt/sablot.c:44: /usr/include/sys/fcntl.h:180: error: parse error before '}' token *** Error code 1 make: Fatal error: Command failed for target `ext/xslt/sablot.lo' thanks, matt [2004-03-09 19:38:40] [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 That file should be all in one line, with \n between them, here's mine with latest CVS snapshot: #define SAB_INFO "Cflags: -g -O2\nLibs: -L/www/sablot-1.0/lib -lexpat\nPrefix: /www/sablot-1.0" [2004-03-09 19:29:49] mrowe at pointsystems dot com there are 4 lines in the file: first line: #define SAB_INFO "Cflags: -g -O2 -I/usr/local/include -I/usr/local/include second line: Libs: -L/usr/local/lib -liconv -lexpat third line: Prefix: /usr/local" fourth line is blank, with no whitespace. thanks, matt [2004-03-09 19:00:30] [EMAIL PROTECTED] Was that all in one line? Didn't it have any \n in it? [2004-03-09 12:20:29] mrowe at pointsystems dot com here is the content of /raid/people/psystems/download/php-4.3.4/include/php_sab_info.h: #define SAB_INFO "Cflags: -g -O2 -I/usr/local/include -I/usr/local/include Libs: -L/usr/local/lib -liconv -lexpat Prefix: /usr/local" 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/27531 -- Edit this bug report at http://bugs.php.net/?id=27531&edit=1
#27531 [Fbk->Opn]: configure works, but make breaks when --enable-xslt and --with-xslt-sablot
ID: 27531 User updated by: mrowe at pointsystems dot com Reported By: mrowe at pointsystems dot com -Status: Feedback +Status: Open Bug Type: XSLT related Operating System: Solaris 9 PHP Version: 4.3.4 New Comment: still no luck. i've tried the 4.3.4 release as well as the latest stable release. i've edited the include/php_sab_info.h files such that they are a single line (both had real line breaks in the distributions, as displayed by 'vi' and 'more'). for what it's worth, i tried [EMAIL PROTECTED]'s solution listed here: http://www.php.net/manual/en/ref.xslt.php. that's not doing anything productive either. i'm still getting as similar error message: /bin/sh /raid/people/psystems/download/php-4.3.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/xslt/ -I/raid/people/psystems/download/php-4.3.4/ext/xslt/ -DPHP_ATOM_INC -I/raid/people/psystems/download/php-4.3.4/include -I/raid/people/psystems/download/php-4.3.4/main -I/raid/people/psystems/download/php-4.3.4 -I/raid/people/psystems/download/php-4.3.4/Zend -I/usr/local/include -I/usr/include/libxml2 -I/raid/people/psystems/download/php-4.3.4/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/raid/people/psystems/download/php-4.3.4/TSRM -g -O2 -prefer-pic -c /raid/people/psystems/download/php-4.3.4/ext/xslt/sablot.c -o ext/xslt/sablot.lo In file included from /raid/people/psystems/download/php-4.3.4/ext/xslt/sablot.c:36: /raid/people/psystems/download/php-4.3.4/include/php_sab_info.h:1:18: missing terminating " character In file included from /raid/people/psystems/download/php-4.3.4/ext/xslt/sablot.c:36: /raid/people/psystems/download/php-4.3.4/include/php_sab_info.h:2: error: parse error before ':' token /raid/people/psystems/download/php-4.3.4/include/php_sab_info.h:3:19: missing terminating " character In file included from /usr/include/fcntl.h:24, from /raid/people/psystems/download/php-4.3.4/ext/xslt/sablot.c:44: /usr/include/sys/fcntl.h:180: error: parse error before '}' token *** Error code 1 make: Fatal error: Command failed for target `ext/xslt/sablot.lo' thanks, matt Previous Comments: [2004-03-09 19:38:40] [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 That file should be all in one line, with \n between them, here's mine with latest CVS snapshot: #define SAB_INFO "Cflags: -g -O2\nLibs: -L/www/sablot-1.0/lib -lexpat\nPrefix: /www/sablot-1.0" [2004-03-09 19:29:49] mrowe at pointsystems dot com there are 4 lines in the file: first line: #define SAB_INFO "Cflags: -g -O2 -I/usr/local/include -I/usr/local/include second line: Libs: -L/usr/local/lib -liconv -lexpat third line: Prefix: /usr/local" fourth line is blank, with no whitespace. thanks, matt [2004-03-09 19:00:30] [EMAIL PROTECTED] Was that all in one line? Didn't it have any \n in it? [2004-03-09 12:20:29] mrowe at pointsystems dot com here is the content of /raid/people/psystems/download/php-4.3.4/include/php_sab_info.h: #define SAB_INFO "Cflags: -g -O2 -I/usr/local/include -I/usr/local/include Libs: -L/usr/local/lib -liconv -lexpat Prefix: /usr/local" [2004-03-09 08:39:25] [EMAIL PROTECTED] Please paste the contents of this file: /raid/people/psystems/download/php-4.3.4/include/php_sab_info.h 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/27531 -- Edit this bug report at http://bugs.php.net/?id=27531&edit=1
#27509 [Fbk]: fsockopen() failed with "Addr family not supported by protocol" error
ID: 27509 Updated by: [EMAIL PROTECTED] Reported By: scott at abcoa dot com Status: Feedback Bug Type: Sockets related Operating System: AIX 4.3.3 PHP Version: 4.3.4 New Comment: I'm also concerned that you may not actually be testing against 4.3... One of the error messages you noted in your original report "php_hostconnect: connect failed in ..." only appears in PHP >prior< to version 4.3.0. As of the 4.3 branch that message contains noticably different text. This discrepency doesn't necessary speak to the fact that the error is occuring. But it raises a question as to whether there are "lingering ghosts" of the prior version. Perhaps creating a conflict with 4.3 which leads to the emergence of the error. Can you conirm that (after the copious number of recompiles you've been asked for) you're still getting that specific error message in your output? It'd also be interresting to see if the sockets extension behaves in the same way: or (for a slight variation: Of course, you'll need to ./configure --enable-sockets in order to try these tests. Previous Comments: [2004-03-10 13:21:47] [EMAIL PROTECTED] Try this: # rm config.cache ; ./configure --disable-all --disable-cgi And use the CLI binary for testing. [2004-03-10 09:26:05] scott at abcoa dot com The configure options I use are --snip-- ./configure --disable-ipv6 --snip-- [2004-03-09 19:15:57] [EMAIL PROTECTED] Works fine for me with latest stable CVS snapshot on AIX 4.3.3. Exactly what configure line did you use? [2004-03-09 16:22:47] scott at abcoa dot com I tried the latest PHP 4 snapshot from CVS yesterday, unzipped it, out came the directory name, "php4-STABLE-200403081230", build it and still get the error code of 66 with error string of "Addr family not supported by protocol". Let me know what you got and of what further homework assignment do I need to do. By the way, I'm using the R/S6000. [2004-03-09 13:24:04] [EMAIL PROTECTED] Please do NOT paste configure outputs here unless asked for. And this bug is about PHP 4, not PHP 5 so try the correct snaphot. (PHP 5 beta 4 is too old already anyway) I will try this myself on an AIX machine. 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/27509 -- Edit this bug report at http://bugs.php.net/?id=27509&edit=1
#27550 [Opn->Bgs]: session_name doesn't fail or compensate for illegal white space
ID: 27550
Updated by: [EMAIL PROTECTED]
Reported By: whelan at nexserver dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Windows XP
PHP Version: 4.3.4
New Comment:
No, he said "RTFM":
http://nl2.php.net/manual/en/function.session-name.php says:
The session name references the session id in cookies and URLs. It
should contain only alphanumeric characters; it should be short and
descriptive (i.e. for users with enabled cookie warnings).
Previous Comments:
[2004-03-10 13:31:54] whelan at nexserver dot com
This is definately a problem with php. It is either an illegal
parameter, or it should be handled as if it were a correct parameter.
It does neither at this time. It will not maintain a session of a name
with a space in it. You're saying it should start a new session with a
new session id every time it encounters a session with the same name,
so it doesn't maintain the session variables? This doesn't make any
sense.
[2004-03-10 13:23:19] [EMAIL PROTECTED]
RTFM
[2004-03-10 10:42:11] whelan at nexserver dot com
Description:
if it contains a space, you get a new session_id on every page calling
session_start(). I believe php should either fail and return an error
or compensate for the space. It shouldn't just not work correctly.
Reproduce code:
---
session_name('New Session');
session_start();
Expected result:
It should maintain the same session id for each session with the same
session name.
Actual result:
--
It will create a new session id for each time this is called.
--
Edit this bug report at http://bugs.php.net/?id=27550&edit=1
#27548 [Bgs->Fbk]: Php crashes when i want to store more then 1 var in $this->menu
ID: 27548 Updated by: [EMAIL PROTECTED] Reported By: maarten at servicez dot org -Status: Bogus +Status: Feedback Bug Type: Reproducible crash Operating System: WinXP PHP Version: 4.3.4 New Comment: Allocating more than 1 GB is not good, but we really do need a smalls script so that we can try to reproduce it. Derick Previous Comments: [2004-03-10 13:29:11] maarten at servicez dot org How is that possible when the script executes in less then 1 secs..it's not like it's taking a long time or something [2004-03-10 13:24:15] [EMAIL PROTECTED] You run out of memory, of course it fails. (fix your script..) [2004-03-10 08:49:14] maarten at servicez dot org I am afraid that isn't possible because the script is using an database to load it's items and it's a part of a bigger site. Any ideas? [2004-03-10 08:45:56] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-03-10 08:41:37] maarten at servicez dot org Description: I have a class making a menu List for my website. It retrieves information out of a mysql database and then stores this information in menuItem objects. Then when i want to order and move with some items i have a problem with one array. PHP sometimes shows the page, sometimes it doesn't. It is only when the variable has the name: menu ANY other name is allowed and the script is just working fine. It's line 52 of the script @ servertjuh.nl When i ran php with --enabled-debug i got this: FATAL: erealloc(): Unable to allocate 1685227521 bytes Reproduce code: --- http://www.servertjuh.nl/external/menuServer.class.phps Expected result: To put $val in $this->menu[] Actual result: -- an popup of windows with: In PHP Script Interpreter is een fout opgetreden en moet worden afgesloten. Onze excuses voor dit ongemak. That means that PHP Script Interpreter has caused a fault. -- Edit this bug report at http://bugs.php.net/?id=27548&edit=1
#27550 [Bgs->Opn]: session_name doesn't fail or compensate for illegal white space
ID: 27550
User updated by: whelan at nexserver dot com
Reported By: whelan at nexserver dot com
-Status: Bogus
+Status: Open
Bug Type: Session related
Operating System: Windows XP
PHP Version: 4.3.4
New Comment:
This is definately a problem with php. It is either an illegal
parameter, or it should be handled as if it were a correct parameter.
It does neither at this time. It will not maintain a session of a name
with a space in it. You're saying it should start a new session with a
new session id every time it encounters a session with the same name,
so it doesn't maintain the session variables? This doesn't make any
sense.
Previous Comments:
[2004-03-10 13:23:19] [EMAIL PROTECTED]
RTFM
[2004-03-10 10:42:11] whelan at nexserver dot com
Description:
if it contains a space, you get a new session_id on every page calling
session_start(). I believe php should either fail and return an error
or compensate for the space. It shouldn't just not work correctly.
Reproduce code:
---
session_name('New Session');
session_start();
Expected result:
It should maintain the same session id for each session with the same
session name.
Actual result:
--
It will create a new session id for each time this is called.
--
Edit this bug report at http://bugs.php.net/?id=27550&edit=1
#27548 [Bgs]: Php crashes when i want to store more then 1 var in $this->menu
ID: 27548 User updated by: maarten at servicez dot org Reported By: maarten at servicez dot org Status: Bogus Bug Type: Reproducible crash Operating System: WinXP PHP Version: 4.3.4 New Comment: How is that possible when the script executes in less then 1 secs..it's not like it's taking a long time or something Previous Comments: [2004-03-10 13:24:15] [EMAIL PROTECTED] You run out of memory, of course it fails. (fix your script..) [2004-03-10 08:49:14] maarten at servicez dot org I am afraid that isn't possible because the script is using an database to load it's items and it's a part of a bigger site. Any ideas? [2004-03-10 08:45:56] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-03-10 08:41:37] maarten at servicez dot org Description: I have a class making a menu List for my website. It retrieves information out of a mysql database and then stores this information in menuItem objects. Then when i want to order and move with some items i have a problem with one array. PHP sometimes shows the page, sometimes it doesn't. It is only when the variable has the name: menu ANY other name is allowed and the script is just working fine. It's line 52 of the script @ servertjuh.nl When i ran php with --enabled-debug i got this: FATAL: erealloc(): Unable to allocate 1685227521 bytes Reproduce code: --- http://www.servertjuh.nl/external/menuServer.class.phps Expected result: To put $val in $this->menu[] Actual result: -- an popup of windows with: In PHP Script Interpreter is een fout opgetreden en moet worden afgesloten. Onze excuses voor dit ongemak. That means that PHP Script Interpreter has caused a fault. -- Edit this bug report at http://bugs.php.net/?id=27548&edit=1
#27551 [Opn->Fbk]: strtotime fails to parse ISO 8601 timestamps with fractional seconds
ID: 27551 Updated by: [EMAIL PROTECTED] Reported By: daniele at orlandi dot com -Status: Open +Status: Feedback Bug Type: Date/time related Operating System: SuSE Linux 9.0 PHP Version: 4.3.5RC3 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. Previous Comments: [2004-03-10 11:27:35] daniele at orlandi dot com Description: strtotime fails to parse timestamp returned by PostgreSQL in the default ISO 8601 output due to fractional seconds. This time stamp is not parsed (invalid): 2004-03-10 16:33:17.11403+01 This is correctly parsed: 2004-03-10 16:33:17+01 Fractional part could be ignored but shouldn't make strtotime consider the timestamp as invalid. -- Edit this bug report at http://bugs.php.net/?id=27551&edit=1
#27539 [Opn->Fbk]: PHP output: No input file specified
ID: 27539
Updated by: [EMAIL PROTECTED]
Reported By: barry at teleserver dot es
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: Sun Solaris 2.6
PHP Version: 4.3.4
New Comment:
Please close the other report, the issue is same.
And provide the backtrace of the crash here.
Previous Comments:
[2004-03-10 03:56:35] barry at teleserver dot es
First of all thanks for your request.
The PHP script seems to work fine from de unix command line:
About the C coded CGI: The webserver starts up a normal CGI programmed
in C. This CGY starts up the PHP script as it was from the command
line, by using the C system() function as followed:
system("/disco1/php/test.php");
About apache: For this tests I used the netscape webserver because of
some other problems I have using apache with this same configuration
and reported as bug: 27540
[2004-03-09 19:10:51] [EMAIL PROTECTED]
Does it work if you run the script on command line?
What do you mean with "I try to start up a PHP script from
a C coded binary CGY by the C system() functión" ???
How did you configure PHP for Apache in httpd.conf ??
[2004-03-09 12:10:18] barry at teleserver dot es
Description:
After instalation and configuratión I try to start up a PHP script from
a C coded binary CGY by the C system() functión. The text "No input
file specified" appears in the navigator.
Configure line:./configure
--prefix=/disco1/aplicaciones/QuorumEnterpriseCenter/apache/php_4.3.4
--with-oracle=/disco1/oracle/8.0.4 --with-oci8=/disco1/oracle/8.0.4
--enable-discard-path --enable-sockets --enable-force-cgi-redirect
--with-config-file-path=/disco1/aplicaciones/QuorumEnterpriseCenter/apache/php_4.3.4
Changes to php.ini: cgi.force_redirect = 0
Observations: This same configuration with earlier version of PHP works
fine.
Reproduce code:
---
PHP script:
#!/disco1/aplicaciones/QuorumEnterpriseCenter/apache/php_4.3.4/bin/php
Expected result:
Yust nothing, an empty page
Actual result:
--
"No input file specified"
--
Edit this bug report at http://bugs.php.net/?id=27539&edit=1
#27548 [Opn->Bgs]: Php crashes when i want to store more then 1 var in $this->menu
ID: 27548 Updated by: [EMAIL PROTECTED] Reported By: maarten at servicez dot org -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: WinXP PHP Version: 4.3.4 New Comment: You run out of memory, of course it fails. (fix your script..) Previous Comments: [2004-03-10 08:49:14] maarten at servicez dot org I am afraid that isn't possible because the script is using an database to load it's items and it's a part of a bigger site. Any ideas? [2004-03-10 08:45:56] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-03-10 08:41:37] maarten at servicez dot org Description: I have a class making a menu List for my website. It retrieves information out of a mysql database and then stores this information in menuItem objects. Then when i want to order and move with some items i have a problem with one array. PHP sometimes shows the page, sometimes it doesn't. It is only when the variable has the name: menu ANY other name is allowed and the script is just working fine. It's line 52 of the script @ servertjuh.nl When i ran php with --enabled-debug i got this: FATAL: erealloc(): Unable to allocate 1685227521 bytes Reproduce code: --- http://www.servertjuh.nl/external/menuServer.class.phps Expected result: To put $val in $this->menu[] Actual result: -- an popup of windows with: In PHP Script Interpreter is een fout opgetreden en moet worden afgesloten. Onze excuses voor dit ongemak. That means that PHP Script Interpreter has caused a fault. -- Edit this bug report at http://bugs.php.net/?id=27548&edit=1
#27550 [Opn->Bgs]: session_name doesn't fail or compensate for illegal white space
ID: 27550
Updated by: [EMAIL PROTECTED]
Reported By: whelan at nexserver dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Windows XP
PHP Version: 4.3.4
New Comment:
RTFM
Previous Comments:
[2004-03-10 10:42:11] whelan at nexserver dot com
Description:
if it contains a space, you get a new session_id on every page calling
session_start(). I believe php should either fail and return an error
or compensate for the space. It shouldn't just not work correctly.
Reproduce code:
---
session_name('New Session');
session_start();
Expected result:
It should maintain the same session id for each session with the same
session name.
Actual result:
--
It will create a new session id for each time this is called.
--
Edit this bug report at http://bugs.php.net/?id=27550&edit=1
#27509 [Opn->Fbk]: fsockopen() failed with "Addr family not supported by protocol" error
ID: 27509 Updated by: [EMAIL PROTECTED] Reported By: scott at abcoa dot com -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: AIX 4.3.3 PHP Version: 4.3.4 New Comment: Try this: # rm config.cache ; ./configure --disable-all --disable-cgi And use the CLI binary for testing. Previous Comments: [2004-03-10 09:26:05] scott at abcoa dot com The configure options I use are --snip-- ./configure --disable-ipv6 --snip-- [2004-03-09 19:15:57] [EMAIL PROTECTED] Works fine for me with latest stable CVS snapshot on AIX 4.3.3. Exactly what configure line did you use? [2004-03-09 16:22:47] scott at abcoa dot com I tried the latest PHP 4 snapshot from CVS yesterday, unzipped it, out came the directory name, "php4-STABLE-200403081230", build it and still get the error code of 66 with error string of "Addr family not supported by protocol". Let me know what you got and of what further homework assignment do I need to do. By the way, I'm using the R/S6000. [2004-03-09 13:24:04] [EMAIL PROTECTED] Please do NOT paste configure outputs here unless asked for. And this bug is about PHP 4, not PHP 5 so try the correct snaphot. (PHP 5 beta 4 is too old already anyway) I will try this myself on an AIX machine. [2004-03-09 08:17:24] [EMAIL PROTECTED] You have to delete config.cache when you reconfigure. Otherwise the change will NOT be noted. So please try again.. 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/27509 -- Edit this bug report at http://bugs.php.net/?id=27509&edit=1
#27342 [Csd]: zend_fetch_debug_backtrace segfault
ID: 27342 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Zend Engine 2 problem Operating System: win32 only -PHP Version: 5CVS-2004-02-23 (dev) +PHP Version: 5CVS-2004-03-10 (dev) New Comment: Hi sniper, It doesn't crash apache and windows doesn't display an error box, but GDB still complain. Take a look: [EMAIL PROTECTED] /cygdrive/c/nuno/testing $ php bug-tidy.php [EMAIL PROTECTED] /cygdrive/c/nuno/testing $ gdb php (...) (gdb) run bug-tidy.php Starting program: /cygdrive/c/php/php.exe bug-tidy.php ---Type to continue, or q to quit--- Program received signal SIGSEGV, Segmentation fault. 0x1000a8a4 in zend_fetch_debug_backtrace () from /cygdrive/c/php/php5ts.dll (gdb) run bug-tidy2.php The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /cygdrive/c/php/php.exe bug-tidy2.php ---Type to continue, or q to quit--- Program received signal SIGSEGV, Segmentation fault. 0x1000a8a4 in zend_fetch_debug_backtrace () from /cygdrive/c/php/php5ts.dll (gdb) Strange... Previous Comments: [2004-03-09 19:30:46] [EMAIL PROTECTED] Does not crash using latest CVS snapshot. (neither the first script or the non-existing file test) [2004-02-26 10:46:25] [EMAIL PROTECTED] This code also segfaults: where bogus.htm file doesn't exist [2004-02-24 13:01:40] [EMAIL PROTECTED] I've compiled with Cygwin/gcc. Maybe the problem is in the microsoft VC compiler... [2004-02-24 12:05:05] [EMAIL PROTECTED] well..then there's surely something wrong with the snaps since those won't work but self-compiled one works? :) [2004-02-24 10:00:01] [EMAIL PROTECTED] Just FYI, snaps box is not for debug purposes. Its "if we were releasing PHP today you would get this". 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/27342 -- Edit this bug report at http://bugs.php.net/?id=27342&edit=1
#21891 [WFx]: Closing PHP tag and Newlines Revisted
ID: 21891 Updated by: [EMAIL PROTECTED] Reported By: hz11 at nyu dot edu Status: Wont fix Bug Type: Feature/Change Request Operating System: FreeBSD/Linux PHP Version: 4.3.0 New Comment: Making a setting in php.ini would make writing portable scripts harder, so that's a no-go too. Previous Comments: [2004-03-10 11:48:37] zizka at seznam dot cz Heeyyy!!! Wake UP! It wouldn't break ANY script if it was optional in the php.ini file As I wrote to derick: Are the PHP developers getting too lazy to improve PHP a bit? [2004-03-10 10:56:45] hz11 at nyu dot edu How would it break existing scripts? Firstly, CLI scripts aren't that common yet, and especially those that rely on this type of behavior. Secondly, what if it was a config setting, available only when running as a CLI (akin to argv/argc). When working with scripts on the console for interactive programs, or using a CLI script to generate raw XML for instance, this type of newline mangle makes no sense and is cause for very hackish scripts. [2004-03-08 12:03:42] [EMAIL PROTECTED] Can not be fixed, as it breaks existing scripts. [2004-03-08 11:29:38] hz11 at nyu dot edu I agree. Now that the CLI interface has matured it's in fairly widespread use. I use CLI continually and this "feature" is a royal pain. Perhaps when running in CLI mode this behavior could be automatically disabled... this would be a much appreciated change. Or, a special tag as suggested: or something?). That way it would still be backwards-compatible. 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/21891 -- Edit this bug report at http://bugs.php.net/?id=21891&edit=1
#27552 [Opn->Fbk]: fwrite fails after writing 8k bytes
ID: 27552 Updated by: [EMAIL PROTECTED] Reported By: jeroen dot pulles at redslider dot net -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: Windows 2000 PHP Version: 5CVS-2004-03-10 (dev) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Please try a real windows binary, not a cygwin emulation and see if the problem persists. Previous Comments: [2004-03-10 11:39:19] jeroen dot pulles at redslider dot net Description: When writing data to a socket, the program fails when writing more than 8192 bytes, irrespective of a given buffersize. Specifics: - Windows 2000 - 5.0.0.0 RC1-dev (-200403101130) - Command line interface (using cygwin) - Almost no modules, just php_sockets.dll - Default php.ini(-dist), apart from E_ALL for the error logging Note: The socket shouldn't be blocking, I didn't ask for it, and set_stream_blocking(true) doesn't change it; I'm guessing this is some irrelevant (for me) implementation detail for PHP. Note: Writing to localhost does work. Note: Writing less than 8192 bytes does work (well, didn't check the exact size where failure starts to happen). Note: No problems on my Linux box and PHP 5.*. Reproduce code: --- Expected result: Expecting to just see "Done" Actual result: -- [EMAIL PROTECTED] bin/php fwrite-bug.php Notice: fwrite(): send of 8192 bytes failed with errno=0 A non-blocking socket o peration could not be completed immediately. in C:\home\wwwroot\aria\fwrite-bug.php on line 12 Done -- Edit this bug report at http://bugs.php.net/?id=27552&edit=1
#27549 [Bgs]: Removing whitespace after closing tag should be optional
ID: 27549 User updated by: zizka at seznam dot cz Reported By: zizka at seznam dot cz Status: Bogus Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.4 New Comment: It wouldn't break ANY script if it was optional in the php.ini file. Are the Zend developers getting too lazy to improve their engine a bit? This feature, actually an intended bug, makes a lot of people mad. Tell me why shouln't it have a directive in php.ini like closing_tag_trimmed = On | Off , On by default ??? Previous Comments: [2004-03-10 09:26:44] [EMAIL PROTECTED] Already filed, and already declined. [2004-03-10 09:19:29] zizka at seznam dot cz Description: Removing whitespace after closing tag is quite annoying and should be optional. Every webmaster looks into the page code to see what's the problem, and when he drops out of PHP parsing mode with ?> instead of echo()ing, the resulting code is quite awful: Without this feature, the output would be like this: About PHP PHP's quite good thing, but still can be better About PHP PHP's quite good thing, but still can be better But, because of it, instead of such nice code we get: About PHP PHP's quite good thing, but still can be better About PHP PHP's quite good thing, but still can be better I could come up with better examples, but they would be too complex. But believe me, sometimes I get a line > 2000 characters long! (And adding echo "\n"; is out of question.) Thx -- Edit this bug report at http://bugs.php.net/?id=27549&edit=1
#21891 [Com]: Closing PHP tag and Newlines Revisted
ID: 21891 Comment by: zizka at seznam dot cz Reported By: hz11 at nyu dot edu Status: Wont fix Bug Type: Feature/Change Request Operating System: FreeBSD/Linux PHP Version: 4.3.0 New Comment: Heeyyy!!! Wake UP! It wouldn't break ANY script if it was optional in the php.ini file As I wrote to derick: Are the PHP developers getting too lazy to improve PHP a bit? Previous Comments: [2004-03-10 10:56:45] hz11 at nyu dot edu How would it break existing scripts? Firstly, CLI scripts aren't that common yet, and especially those that rely on this type of behavior. Secondly, what if it was a config setting, available only when running as a CLI (akin to argv/argc). When working with scripts on the console for interactive programs, or using a CLI script to generate raw XML for instance, this type of newline mangle makes no sense and is cause for very hackish scripts. [2004-03-08 12:03:42] [EMAIL PROTECTED] Can not be fixed, as it breaks existing scripts. [2004-03-08 11:29:38] hz11 at nyu dot edu I agree. Now that the CLI interface has matured it's in fairly widespread use. I use CLI continually and this "feature" is a royal pain. Perhaps when running in CLI mode this behavior could be automatically disabled... this would be a much appreciated change. Or, a special tag as suggested: or something?). That way it would still be backwards-compatible. [2003-05-20 15:34:06] csnyder at chxo dot com "Included files shouldn't even contain a closing tag, for these exact reasons." This is excellent advice, but it is *not* a documented practice. All of the examples in the Basic Syntax documentation include closing tags. In fact, the documentation for include() says: "... any code inside the target file which should be executed as PHP code must be enclosed within valid PHP start and end tags." I agree wholeheartedly that both the documentation and the behavior should be changed, but to do so is to risk breaking a lot of existing code. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21891 -- Edit this bug report at http://bugs.php.net/?id=21891&edit=1
#27552 [NEW]: fwrite fails after writing 8k bytes
From: jeroen dot pulles at redslider dot net Operating system: Windows 2000 PHP version: 5CVS-2004-03-10 (dev) PHP Bug Type: Sockets related Bug description: fwrite fails after writing 8k bytes Description: When writing data to a socket, the program fails when writing more than 8192 bytes, irrespective of a given buffersize. Specifics: - Windows 2000 - 5.0.0.0 RC1-dev (-200403101130) - Command line interface (using cygwin) - Almost no modules, just php_sockets.dll - Default php.ini(-dist), apart from E_ALL for the error logging Note: The socket shouldn't be blocking, I didn't ask for it, and set_stream_blocking(true) doesn't change it; I'm guessing this is some irrelevant (for me) implementation detail for PHP. Note: Writing to localhost does work. Note: Writing less than 8192 bytes does work (well, didn't check the exact size where failure starts to happen). Note: No problems on my Linux box and PHP 5.*. Reproduce code: --- Expected result: Expecting to just see "Done" Actual result: -- [EMAIL PROTECTED] bin/php fwrite-bug.php Notice: fwrite(): send of 8192 bytes failed with errno=0 A non-blocking socket o peration could not be completed immediately. in C:\home\wwwroot\aria\fwrite-bug.php on line 12 Done -- Edit bug report at http://bugs.php.net/?id=27552&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27552&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27552&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27552&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27552&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27552&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27552&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27552&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27552&r=support Expected behavior: http://bugs.php.net/fix.php?id=27552&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27552&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27552&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27552&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27552&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27552&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27552&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27552&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27552&r=float
#26765 [Com]: Objects destroyed twice?
ID: 26765
Comment by: jaanus at heeringson dot com
Reported By: alex_mailbox53 at yahoo dot com
Status: Critical
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2004-02-25
New Comment:
Ok, I have found out why the above example occaisionally worked. It
seems the order in which properties are declared play a ignificant
role. I guess the "destruction" propagates along in the order of
declarations. You can try it yourself by swaping two lines in the code
below (the lines are commented).
child[$class][]=$_temp;
if(is_object($parent)) {
$parent->mount($_temp);
}
Return $_temp;
}
}
class root {
public $child; //If the order of these two lines
public $ref;//is changed, you get a segfault
public $parent;
public function __construct($factory){
$this->ref['factory']=$factory;
}
public function mount($obj){
$this->child[]=$obj;
$obj->setParent($this);
$obj->setRef($this->ref+array('root'=>$this));
}
public function setRef($pref) {
$this->ref=array_merge($pref,$this->ref);
}
public function setParent($parent){
$this->parent=$parent;
}
}
class child extends root{
public function mount($obj){
$this->child[]=$obj;
$obj->setParent($this);
$obj->setRef($this->ref+array('child'=>$this));
}
}
$factory=new factory();
$a=$factory->make('root');
$b=$factory->make('child',$a);
$c=$factory->make('child',$a);
print_r($a);
?>
Previous Comments:
[2004-03-09 15:33:17] jaanus at heeringson dot com
Hmm, I was totally wrong in my last posting. Of cause there are four
objects.
After updating my apache and php (from 20040307 to 20040309) the latest
test code works without causing segfaults now, even with print_r().
Anyway, since this bug is still making my life very miserabe, here
comes a new test case. This i a simplification of a object factory that
creates recursive trees.
$this));
$this->child[$obj][]=$_temp;
if(is_object($parent)) {
$parent->mount($_temp);
}
Return $_temp;
}
}
class root {
protected $ref;
protected $chid;
protected $parent;
protected $test;
public function __construct($baseref) {
$this->ref=$baseref;
$this->ref['root']=$this;
print_r(array_keys($this->ref));
}
function mount($obj) {
$this->child[]=$obj;
$obj->setref($this->ref); //Both these lines individually
$obj->setParent($this); //cause the code to segfault
}
function setref($parentref) {
$this->ref=array_merge($parentref,$this->ref);
}
function setParent($parent) {
$this->parent=$parent;
}
}
class child extends root {
public function __construct($baseref) {
$this->ref=$baseref;
$this->ref['child']=$this;
print_r(array_keys($this->ref));
}
}
$factory=new ObjFactory();
$a=$factory->make('root');
$b=$factory->make('child',$a);
print_r($factory);
?>
Expected result:
Dump of the $factory object, with LOTS of cirular and recursive
relations
Actual result:
--
Segfault
gdb dump
--
Program received signal SIGSEGV, Segmentation fault.
zend_hash_destroy (ht=0x5a5a5a5a) at
/usr/src/lastphp/Zend/zend_hash.c:53
53 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 zend_hash_destroy (ht=0x5a5a5a5a) at
/usr/src/lastphp/Zend/zend_hash.c:53
#1 0x40b808de in zend_objects_free_object_storage (object=0x41646678)
at /usr/src/lastphp/Zend/zend_objects.c:88
#2 0x40b83145 in zend_objects_store_del_ref (zobject=0x1)
at /usr/src/lastphp/Zend/zend_objects_API.c:144
#3 0x40b6967d in _zval_dtor (zvalue=0x41646780,
__zend_filename=0x40d387e0
"/usr/src/lastphp/Zend/zend_execute_API.c",
__zend_lineno=1087946752) at
/usr/src/lastphp/Zend/zend_variables.c:61
#4 0x40b605b2 in _zval_ptr_dtor (zval_ptr=0x41652ac0,
__zend_filename=0x1 , __zend_lineno=1)
at /usr/src/lastphp/Zend/zend_execute_API.c:358
#5 0x40b69a71 in _zval_ptr_dtor_wrapper (zval_ptr=0x1)
at /usr/src/lastphp/Zend/zend_variables.c:196
#6 0x40b7307d in zend_hash_destroy (ht=0x41652840)
at /usr/src/lastphp/Zend/zend_hash.c:513
#7 0x40b696a9 in _zval_dtor (zvalue=0x416527c0,
__zend_filename=0x40d387e0
"/usr/src/lastphp/Ze
#27551 [NEW]: strtotime fails to parse ISO 8601 timestamps with fractional seconds
From: daniele at orlandi dot com Operating system: SuSE Linux 9.0 PHP version: 4.3.5RC3 PHP Bug Type: Date/time related Bug description: strtotime fails to parse ISO 8601 timestamps with fractional seconds Description: strtotime fails to parse timestamp returned by PostgreSQL in the default ISO 8601 output due to fractional seconds. This time stamp is not parsed (invalid): 2004-03-10 16:33:17.11403+01 This is correctly parsed: 2004-03-10 16:33:17+01 Fractional part could be ignored but shouldn't make strtotime consider the timestamp as invalid. -- Edit bug report at http://bugs.php.net/?id=27551&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27551&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27551&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27551&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27551&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27551&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27551&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27551&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27551&r=support Expected behavior: http://bugs.php.net/fix.php?id=27551&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27551&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27551&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27551&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27551&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27551&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27551&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27551&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27551&r=float
#21891 [WFx]: Closing PHP tag and Newlines Revisted
ID: 21891 User updated by: hz11 at nyu dot edu Reported By: hz11 at nyu dot edu Status: Wont fix Bug Type: Feature/Change Request Operating System: FreeBSD/Linux PHP Version: 4.3.0 New Comment: How would it break existing scripts? Firstly, CLI scripts aren't that common yet, and especially those that rely on this type of behavior. Secondly, what if it was a config setting, available only when running as a CLI (akin to argv/argc). When working with scripts on the console for interactive programs, or using a CLI script to generate raw XML for instance, this type of newline mangle makes no sense and is cause for very hackish scripts. Previous Comments: [2004-03-08 12:03:42] [EMAIL PROTECTED] Can not be fixed, as it breaks existing scripts. [2004-03-08 11:29:38] hz11 at nyu dot edu I agree. Now that the CLI interface has matured it's in fairly widespread use. I use CLI continually and this "feature" is a royal pain. Perhaps when running in CLI mode this behavior could be automatically disabled... this would be a much appreciated change. Or, a special tag as suggested: or something?). That way it would still be backwards-compatible. [2003-05-20 15:34:06] csnyder at chxo dot com "Included files shouldn't even contain a closing tag, for these exact reasons." This is excellent advice, but it is *not* a documented practice. All of the examples in the Basic Syntax documentation include closing tags. In fact, the documentation for include() says: "... any code inside the target file which should be executed as PHP code must be enclosed within valid PHP start and end tags." I agree wholeheartedly that both the documentation and the behavior should be changed, but to do so is to risk breaking a lot of existing code. [2003-05-07 08:30:43] hz11 at nyu dot edu I very much would like this reconsidered, for a number of reasons, including documentation and functionality. Granted, the documentation does say "will include," but in combination with other statements it's simply not clear. If this behavior is vital that it must remain, perhaps another look at this would avoid others opening bug reports. More importantly, however, is the fact that this behavior occurs at all. Yes, PHP is primarily a web scripting language, but even in this vein of usage, there's no reason for this. First, included files generally don't contain trailing newlines. For example, in your text editor of choice, going to the end of the document, placing the cursor directly after ?> and deleting everything to the right, you will not end up with any trailing newlines. So, is this behavior in place to simply allow one newline, but not more than one? Simply, there either is a character after the closing tag, or there isn't. Secondly, and most importantly, is that this shouldn't even be an issue. Included files shouldn't even contain a closing tag, for these exact reasons. PHP will end parsing at an end-of-file and placing a closing tag will only cause problems with header() calls, etc. as pointed out. Lastly, if this behavior is vital enough to keep, I hope that a consideration for CLI usage can be made. Ambigously keeping a newline after a closing tag makes even less sense on the console. At the very least, if PHP is compiled as a CLI, can this behavior can be eliminated? Thank you, Hans 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/21891 -- Edit this bug report at http://bugs.php.net/?id=21891&edit=1
#27550 [NEW]: session_name doesn't fail or compensate for illegal white space
From: whelan at nexserver dot com
Operating system: Windows XP
PHP version: 4.3.4
PHP Bug Type: Session related
Bug description: session_name doesn't fail or compensate for illegal white space
Description:
if it contains a space, you get a new session_id on every page calling
session_start(). I believe php should either fail and return an error or
compensate for the space. It shouldn't just not work correctly.
Reproduce code:
---
session_name('New Session');
session_start();
Expected result:
It should maintain the same session id for each session with the same
session name.
Actual result:
--
It will create a new session id for each time this is called.
--
Edit bug report at http://bugs.php.net/?id=27550&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27550&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27550&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27550&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27550&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27550&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27550&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27550&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27550&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27550&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27550&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27550&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27550&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27550&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27550&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27550&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27550&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27550&r=float
#27549 [Opn->Bgs]: Removing whitespace after closing tag should be optional
ID: 27549 Updated by: [EMAIL PROTECTED] Reported By: zizka at seznam dot cz -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.4 New Comment: Already filed, and already declined. Previous Comments: [2004-03-10 09:19:29] zizka at seznam dot cz Description: Removing whitespace after closing tag is quite annoying and should be optional. Every webmaster looks into the page code to see what's the problem, and when he drops out of PHP parsing mode with ?> instead of echo()ing, the resulting code is quite awful: Without this feature, the output would be like this: About PHP PHP's quite good thing, but still can be better About PHP PHP's quite good thing, but still can be better But, because of it, instead of such nice code we get: About PHP PHP's quite good thing, but still can be better About PHP PHP's quite good thing, but still can be better I could come up with better examples, but they would be too complex. But believe me, sometimes I get a line > 2000 characters long! (And adding echo "\n"; is out of question.) Thx -- Edit this bug report at http://bugs.php.net/?id=27549&edit=1
#27509 [Fbk->Opn]: fsockopen() failed with "Addr family not supported by protocol" error
ID: 27509 User updated by: scott at abcoa dot com Reported By: scott at abcoa dot com -Status: Feedback +Status: Open Bug Type: Sockets related Operating System: AIX 4.3.3 PHP Version: 4.3.4 New Comment: The configure options I use are --snip-- ./configure --disable-ipv6 --snip-- Previous Comments: [2004-03-09 19:15:57] [EMAIL PROTECTED] Works fine for me with latest stable CVS snapshot on AIX 4.3.3. Exactly what configure line did you use? [2004-03-09 16:22:47] scott at abcoa dot com I tried the latest PHP 4 snapshot from CVS yesterday, unzipped it, out came the directory name, "php4-STABLE-200403081230", build it and still get the error code of 66 with error string of "Addr family not supported by protocol". Let me know what you got and of what further homework assignment do I need to do. By the way, I'm using the R/S6000. [2004-03-09 13:24:04] [EMAIL PROTECTED] Please do NOT paste configure outputs here unless asked for. And this bug is about PHP 4, not PHP 5 so try the correct snaphot. (PHP 5 beta 4 is too old already anyway) I will try this myself on an AIX machine. [2004-03-09 08:17:24] [EMAIL PROTECTED] You have to delete config.cache when you reconfigure. Otherwise the change will NOT be noted. So please try again.. [2004-03-08 16:51:22] scott at abcoa dot com Further notice... I noticed the PHP version 4.3.1 on an another AIX machine does have this same problem with the fsockopen(). So, it could be between 4.2.3 and 4.3.1 when it all of a sudden just don't work. 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/27509 -- Edit this bug report at http://bugs.php.net/?id=27509&edit=1
#27547 [Bgs]: Sqlite column names change, but PRAGMA short_column_names=ON not working
ID: 27547
User updated by: col at mportal dot hu
Reported By: col at mportal dot hu
Status: Bogus
Bug Type: SQLite related
Operating System: linux, windows
PHP Version: 4.3.4
New Comment:
Thanx, but this problem exists in bundled 2.8.11 too. I just found this
pragma option workin in sqlite console, but not in php. The problem not
the "PRAGMA short_column_names=ON". The problem is the name of
returning columns, and the short_column_names option in sqlite which
changed, and can not be set from php.
Probably a php.ini setting (or else, if it's not working from the
query) could help this bug, in feature.
Previous Comments:
[2004-03-10 09:08:18] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Bundled sqlite library is version 2.8.11, if you want to
have latest features like "PRAGMA short_column_names" use
external sqlite library.
[2004-03-10 07:51:28] col at mportal dot hu
Description:
In sqlite then return of the column names changed in new versions
(aktual: 2.8.13)
The return type (short name or long name) can be set with: PRAGMA
short_column_names=ON; It works fine from sqlite console, but not from
php. And php has no any ini setting, to change this variable. Setting
this from query before select query, has no affect.
Reproduce code:
---
$db = sqlite_open('mydb.db',0666, $sqliteerror);
sqlite_query($db,"create table t1(id1 int,n1 varchar(5)");
sqlite_query($db,"create table t2(id2 int,n2 varchar(5)");
sqlite_query($db,"insert into t1(id1,n1) values (1,'N1')");
sqlite_query($db,"insert into t2(id2,n2) values (1,'N2')");
sqlite_query($db, 'PRAGMA short_column_names=ON');
/**
select *, or select t1.id1, t2.id2, t1.n1, t2.n2, or select t1.*, t2.*
is the same effect
*/
$result=sqlite_query($db,'select * from t1,t2 where t1.id=t2.id');
echo
"",var_dump(sqlite_fetch_array($result,SQLITE_ASSOC)),"";
Expected result:
array(4) {
["id1"]=>
string(1) "1"
["n1"]=>
string(1) "N1"
["id2"]=>
string(1) "1"
["n2"]=>
string(2) "N2"
}
Actual result:
--
array(4) {
["t1.id1"]=>
string(1) "1"
["t1.n1"]=>
string(1) "N1"
["t2.id2"]=>
string(1) "1"
["t2.n2"]=>
string(2) "N2"
}
--
Edit this bug report at http://bugs.php.net/?id=27547&edit=1
#27549 [NEW]: Removing whitespace after closing tag should be optional
From: zizka at seznam dot cz Operating system: All PHP version: 4.3.4 PHP Bug Type: Feature/Change Request Bug description: Removing whitespace after closing tag should be optional Description: Removing whitespace after closing tag is quite annoying and should be optional. Every webmaster looks into the page code to see what's the problem, and when he drops out of PHP parsing mode with ?> instead of echo()ing, the resulting code is quite awful: Without this feature, the output would be like this: About PHP PHP's quite good thing, but still can be better About PHP PHP's quite good thing, but still can be better But, because of it, instead of such nice code we get: About PHP PHP's quite good thing, but still can be better About PHP PHP's quite good thing, but still can be better I could come up with better examples, but they would be too complex. But believe me, sometimes I get a line > 2000 characters long! (And adding echo "\n"; is out of question.) Thx -- Edit bug report at http://bugs.php.net/?id=27549&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27549&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27549&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27549&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27549&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27549&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27549&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27549&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27549&r=support Expected behavior: http://bugs.php.net/fix.php?id=27549&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27549&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27549&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27549&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27549&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27549&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27549&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27549&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27549&r=float
#27547 [Opn->Bgs]: Sqlite column names change, but PRAGMA short_column_names=ON not working
ID: 27547
Updated by: [EMAIL PROTECTED]
Reported By: col at mportal dot hu
-Status: Open
+Status: Bogus
Bug Type: SQLite related
Operating System: linux, windows
PHP Version: 4.3.4
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Bundled sqlite library is version 2.8.11, if you want to
have latest features like "PRAGMA short_column_names" use
external sqlite library.
Previous Comments:
[2004-03-10 07:51:28] col at mportal dot hu
Description:
In sqlite then return of the column names changed in new versions
(aktual: 2.8.13)
The return type (short name or long name) can be set with: PRAGMA
short_column_names=ON; It works fine from sqlite console, but not from
php. And php has no any ini setting, to change this variable. Setting
this from query before select query, has no affect.
Reproduce code:
---
$db = sqlite_open('mydb.db',0666, $sqliteerror);
sqlite_query($db,"create table t1(id1 int,n1 varchar(5)");
sqlite_query($db,"create table t2(id2 int,n2 varchar(5)");
sqlite_query($db,"insert into t1(id1,n1) values (1,'N1')");
sqlite_query($db,"insert into t2(id2,n2) values (1,'N2')");
sqlite_query($db, 'PRAGMA short_column_names=ON');
/**
select *, or select t1.id1, t2.id2, t1.n1, t2.n2, or select t1.*, t2.*
is the same effect
*/
$result=sqlite_query($db,'select * from t1,t2 where t1.id=t2.id');
echo
"",var_dump(sqlite_fetch_array($result,SQLITE_ASSOC)),"";
Expected result:
array(4) {
["id1"]=>
string(1) "1"
["n1"]=>
string(1) "N1"
["id2"]=>
string(1) "1"
["n2"]=>
string(2) "N2"
}
Actual result:
--
array(4) {
["t1.id1"]=>
string(1) "1"
["t1.n1"]=>
string(1) "N1"
["t2.id2"]=>
string(1) "1"
["t2.n2"]=>
string(2) "N2"
}
--
Edit this bug report at http://bugs.php.net/?id=27547&edit=1
#27532 [Opn->Csd]: session_id is changed after refresh....
ID: 27532 Updated by: [EMAIL PROTECTED] Reported By: capsx at divx dot team dot lv -Status: Open +Status: Closed Bug Type: Session related Operating System: Linux PHP Version: 4.3.5RC3 Previous Comments: [2004-03-10 09:05:56] capsx at divx dot team dot lv strange :] but now working, only i swear: before i report that bug i search for session bugs and installed snapshot... ok thx [2004-03-09 18:28:52] [EMAIL PROTECTED] Please include a short script that can be used to replicate the problem. [2004-03-09 15:55:08] capsx at divx dot team dot lv as i said - I already yesterday installed snapshot but problem is the same... [2004-03-09 08:33:28] [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 with latest stable CVS snapshot.. [2004-03-08 22:47:51] capsx at divx dot team dot lv sorry :] with site 1:1 on RC2 server all was fine but on RC3 server session id changes everytime when page was refreshed. 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/27532 -- Edit this bug report at http://bugs.php.net/?id=27532&edit=1
#27532 [Fbk->Opn]: session_id is changed after refresh....
ID: 27532 User updated by: capsx at divx dot team dot lv Reported By: capsx at divx dot team dot lv -Status: Feedback +Status: Open Bug Type: Session related Operating System: Linux PHP Version: 4.3.5RC3 New Comment: strange :] but now working, only i swear: before i report that bug i search for session bugs and installed snapshot... ok thx Previous Comments: [2004-03-09 18:28:52] [EMAIL PROTECTED] Please include a short script that can be used to replicate the problem. [2004-03-09 15:55:08] capsx at divx dot team dot lv as i said - I already yesterday installed snapshot but problem is the same... [2004-03-09 08:33:28] [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 with latest stable CVS snapshot.. [2004-03-08 22:47:51] capsx at divx dot team dot lv sorry :] with site 1:1 on RC2 server all was fine but on RC3 server session id changes everytime when page was refreshed. [2004-03-08 22:45:40] capsx at divx dot team dot lv nop! nothing was changed in code, with RC2 all works fine, also i tested one site on my RC3 and the same site (1:1) on other my RC2 server - session id changes everytime... try http://web.team.lv/test/test.php in that page below is source... 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/27532 -- Edit this bug report at http://bugs.php.net/?id=27532&edit=1
#26742 [Com]: The base64_encode() function returns an string that cannot decoded by outlook
ID: 26742
Comment by: louloufox29 at hotmail dot com
Reported By: eric dot maman at free dot fr
Status: No Feedback
Bug Type: *URL Functions
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Just for information, the problem exist with or without using the
function send by eric. In my case, it wasn't a workaround.
Regards.
Previous Comments:
[2004-03-10 08:49:43] louloufox29 at hotmail dot com
I have the same problem (using PHP 4.3.3 with Easy PHP on a win XP
server)
When i send the attachment using Outlook, the part of message source
about attachement is different. The string is not the same... (that's
why it seems sorrupted).
I've try to encode a file and then decode the same file, save it using
a different name and can't open it, it is the same probleme.
So i think it's realy a PHP Bogus (i can't believe in the config way of
resolution...)
Regards !
[2004-01-22 14:48:32] luis dot cervantes at uspeurope dot com
Hi.
I have the same problem with function.
Can you tell me how you resolved the problem.
Its is possible that the problem is the instalation of php.
mimetypes, etc.
Thanks for all.
Luis
[2004-01-06 20:51:46] [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-12-29 10:35:22] [EMAIL PROTECTED]
What is the value of $this->LE ?
[2003-12-29 09:32:14] eric dot maman at free dot fr
Description:
I am using the base64_encode() function to send attachements by email.
When I receive the mail on Outlook, the attachement is visible but
corrupeted.
I have tested the whole process and my conclusion is that the
base64_encode() function does not work correctly.
I have made a workarround with an extrenal program that performs the
base64 encoding and it work correctly.
Reproduce code:
---
function EncodeString ($str, $encoding = "base64") {
$encoded = "";
switch(strtolower($encoding)) {
case "base64":
$encoded = chunk_split(base64_encode($str), 76,
$this->LE);
break;
case "7bit":
case "8bit":
$encoded = $this->FixEOL($str);
if (substr($encoded, -(strlen($this->LE))) != $this->LE)
$encoded .= $this->LE;
break;
case "binary":
$encoded = $str;
break;
case "quoted-printable":
$encoded = $this->EncodeQP($str);
break;
default:
$this->SetError($this->Lang("encoding") . $encoding);
break;
}
return $encoded;
}
--
Edit this bug report at http://bugs.php.net/?id=26742&edit=1
#26742 [Com]: The base64_encode() function returns an string that cannot decoded by outlook
ID: 26742
Comment by: louloufox29 at hotmail dot com
Reported By: eric dot maman at free dot fr
Status: No Feedback
Bug Type: *URL Functions
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
I have the same problem (using PHP 4.3.3 with Easy PHP on a win XP
server)
When i send the attachment using Outlook, the part of message source
about attachement is different. The string is not the same... (that's
why it seems sorrupted).
I've try to encode a file and then decode the same file, save it using
a different name and can't open it, it is the same probleme.
So i think it's realy a PHP Bogus (i can't believe in the config way of
resolution...)
Regards !
Previous Comments:
[2004-01-22 14:48:32] luis dot cervantes at uspeurope dot com
Hi.
I have the same problem with function.
Can you tell me how you resolved the problem.
Its is possible that the problem is the instalation of php.
mimetypes, etc.
Thanks for all.
Luis
[2004-01-06 20:51:46] [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-12-29 10:35:22] [EMAIL PROTECTED]
What is the value of $this->LE ?
[2003-12-29 09:32:14] eric dot maman at free dot fr
Description:
I am using the base64_encode() function to send attachements by email.
When I receive the mail on Outlook, the attachement is visible but
corrupeted.
I have tested the whole process and my conclusion is that the
base64_encode() function does not work correctly.
I have made a workarround with an extrenal program that performs the
base64 encoding and it work correctly.
Reproduce code:
---
function EncodeString ($str, $encoding = "base64") {
$encoded = "";
switch(strtolower($encoding)) {
case "base64":
$encoded = chunk_split(base64_encode($str), 76,
$this->LE);
break;
case "7bit":
case "8bit":
$encoded = $this->FixEOL($str);
if (substr($encoded, -(strlen($this->LE))) != $this->LE)
$encoded .= $this->LE;
break;
case "binary":
$encoded = $str;
break;
case "quoted-printable":
$encoded = $this->EncodeQP($str);
break;
default:
$this->SetError($this->Lang("encoding") . $encoding);
break;
}
return $encoded;
}
--
Edit this bug report at http://bugs.php.net/?id=26742&edit=1
#27548 [Fbk->Opn]: Php crashes when i want to store more then 1 var in $this->menu
ID: 27548 User updated by: maarten at servicez dot org Reported By: maarten at servicez dot org -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: WinXP PHP Version: 4.3.4 New Comment: I am afraid that isn't possible because the script is using an database to load it's items and it's a part of a bigger site. Any ideas? Previous Comments: [2004-03-10 08:45:56] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-03-10 08:41:37] maarten at servicez dot org Description: I have a class making a menu List for my website. It retrieves information out of a mysql database and then stores this information in menuItem objects. Then when i want to order and move with some items i have a problem with one array. PHP sometimes shows the page, sometimes it doesn't. It is only when the variable has the name: menu ANY other name is allowed and the script is just working fine. It's line 52 of the script @ servertjuh.nl When i ran php with --enabled-debug i got this: FATAL: erealloc(): Unable to allocate 1685227521 bytes Reproduce code: --- http://www.servertjuh.nl/external/menuServer.class.phps Expected result: To put $val in $this->menu[] Actual result: -- an popup of windows with: In PHP Script Interpreter is een fout opgetreden en moet worden afgesloten. Onze excuses voor dit ongemak. That means that PHP Script Interpreter has caused a fault. -- Edit this bug report at http://bugs.php.net/?id=27548&edit=1
#27548 [Opn->Fbk]: Php crashes when i want to store more then 1 var in $this->menu
ID: 27548 Updated by: [EMAIL PROTECTED] Reported By: maarten at servicez dot org -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: WinXP PHP Version: 4.3.4 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. Previous Comments: [2004-03-10 08:41:37] maarten at servicez dot org Description: I have a class making a menu List for my website. It retrieves information out of a mysql database and then stores this information in menuItem objects. Then when i want to order and move with some items i have a problem with one array. PHP sometimes shows the page, sometimes it doesn't. It is only when the variable has the name: menu ANY other name is allowed and the script is just working fine. It's line 52 of the script @ servertjuh.nl When i ran php with --enabled-debug i got this: FATAL: erealloc(): Unable to allocate 1685227521 bytes Reproduce code: --- http://www.servertjuh.nl/external/menuServer.class.phps Expected result: To put $val in $this->menu[] Actual result: -- an popup of windows with: In PHP Script Interpreter is een fout opgetreden en moet worden afgesloten. Onze excuses voor dit ongemak. That means that PHP Script Interpreter has caused a fault. -- Edit this bug report at http://bugs.php.net/?id=27548&edit=1
#27548 [NEW]: Php crashes when i want to store more then 1 var in $this->menu
From: maarten at servicez dot org Operating system: WinXP PHP version: 4.3.4 PHP Bug Type: Reproducible crash Bug description: Php crashes when i want to store more then 1 var in $this->menu Description: I have a class making a menu List for my website. It retrieves information out of a mysql database and then stores this information in menuItem objects. Then when i want to order and move with some items i have a problem with one array. PHP sometimes shows the page, sometimes it doesn't. It is only when the variable has the name: menu ANY other name is allowed and the script is just working fine. It's line 52 of the script @ servertjuh.nl When i ran php with --enabled-debug i got this: FATAL: erealloc(): Unable to allocate 1685227521 bytes Reproduce code: --- http://www.servertjuh.nl/external/menuServer.class.phps Expected result: To put $val in $this->menu[] Actual result: -- an popup of windows with: In PHP Script Interpreter is een fout opgetreden en moet worden afgesloten. Onze excuses voor dit ongemak. That means that PHP Script Interpreter has caused a fault. -- Edit bug report at http://bugs.php.net/?id=27548&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27548&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27548&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27548&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27548&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27548&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27548&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27548&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27548&r=support Expected behavior: http://bugs.php.net/fix.php?id=27548&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27548&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27548&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27548&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27548&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27548&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27548&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27548&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27548&r=float
#27547 [NEW]: Sqlite column names change, but PRAGMA short_column_names=ON not working
From: col at mportal dot hu
Operating system: linux, windows
PHP version: 4.3.4
PHP Bug Type: SQLite related
Bug description: Sqlite column names change, but PRAGMA short_column_names=ON not
working
Description:
In sqlite then return of the column names changed in new versions (aktual:
2.8.13)
The return type (short name or long name) can be set with: PRAGMA
short_column_names=ON; It works fine from sqlite console, but not from
php. And php has no any ini setting, to change this variable. Setting this
from query before select query, has no affect.
Reproduce code:
---
$db = sqlite_open('mydb.db',0666, $sqliteerror);
sqlite_query($db,"create table t1(id1 int,n1 varchar(5)");
sqlite_query($db,"create table t2(id2 int,n2 varchar(5)");
sqlite_query($db,"insert into t1(id1,n1) values (1,'N1')");
sqlite_query($db,"insert into t2(id2,n2) values (1,'N2')");
sqlite_query($db, 'PRAGMA short_column_names=ON');
/**
select *, or select t1.id1, t2.id2, t1.n1, t2.n2, or select t1.*, t2.* is
the same effect
*/
$result=sqlite_query($db,'select * from t1,t2 where t1.id=t2.id');
echo "",var_dump(sqlite_fetch_array($result,SQLITE_ASSOC)),"";
Expected result:
array(4) {
["id1"]=>
string(1) "1"
["n1"]=>
string(1) "N1"
["id2"]=>
string(1) "1"
["n2"]=>
string(2) "N2"
}
Actual result:
--
array(4) {
["t1.id1"]=>
string(1) "1"
["t1.n1"]=>
string(1) "N1"
["t2.id2"]=>
string(1) "1"
["t2.n2"]=>
string(2) "N2"
}
--
Edit bug report at http://bugs.php.net/?id=27547&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27547&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27547&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27547&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27547&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27547&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27547&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27547&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27547&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27547&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27547&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27547&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27547&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27547&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27547&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27547&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27547&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27547&r=float
#27484 [Fbk->Csd]: serialize / unserialize crash
ID: 27484
User updated by: friosa at pnpitalia dot it
Reported By: friosa at pnpitalia dot it
-Status: Feedback
+Status: Closed
Bug Type: Reproducible crash
Operating System: Linux 2.4.18-4GB
PHP Version: 5CVS-2004-03-03 (dev)
New Comment:
Sorry the machine has become a production server so I can't recreate
any more the problem.
I think that if it's not possible recreate this problem on other
computers (it was on mine getting the data from *this* page) it's
better to close this bug.
Previous Comments:
[2004-03-09 08:53:27] [EMAIL PROTECTED]
The serialized string in your example code is invalid.
Please provide a working version and WITHOUT the base64 encoding!!
[2004-03-03 15:32:29] friosa at pnpitalia dot it
Description:
investigating on bug #27469 I've tryed to serialize an object that used
was crashing php + apache.
Trying to unserialize it on php 4.x produces a boolean true variable,
doing the same on php 5 cvs create a crash but in a different
fx/program (php_var_serialize_class_name / var.c).
Reproduce code:
---
buildMessagePart($mime_part);
define('MIME_CONTENTS_CACHE', 'mimecache');
class MIME_Contents {
function MIME_Contents($messageOb, $viewID = array(), $contents =
array()) {}
function buildMessagePart(&$mime_part)
{
$msg = '';
// CRASH HERE
echo "" . addslashes(serialize($mime_part)) . "";
return $msg;
}
}
class IMP_Contents extends MIME_Contents {
function IMP_Contents($index) {}
}
?>
Actual result:
--
Bug #27469 zend_variables.c problem
Submitted: 2 Mar 6:00pm ESTModified: 3 Mar 4:32am EST
From: friosa at pnpitalia dot it
Status: FeedbackCategory: Zend Engine 2 problem
Version:5.0.0b4 (beta4) OS: Linux 2.4.18-4GB
gdb ./httpd
(gdb) run -X
Starting program: /TEST/apache/bin/./httpd -X
[New Thread 1024 (LWP 17036)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 17036)]
0x4035080f in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x4035080f in memcpy () from /lib/libc.so.6
#1 0x405f8b0b in php_var_serialize_class_name (buf=0xbfffc4dc,
struc=0x16f1520) at /TEST/php5-200403022230/ext/standard/var.c:480
#2 0x40698d73 in zend_do_fcall_common_helper (execute_data=0xbfffc850,
opline=0xbfffc4d5, op_array=0xa) at
/TEST/php5-200403022230/Zend/zend_execute.c:2677
#3 0x406703b9 in zend_execute_scripts (type=1081403672,
retval=0x40d0d24c, file_count=516) at
/TEST/php5-200403022230/Zend/zend.c:1041
(gdb)
--
Edit this bug report at http://bugs.php.net/?id=27484&edit=1
#26666 [Ver]: crash in zend_mm_alloc
ID: 2
User updated by: jan at horde dot org
Reported By: jan at horde dot org
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2004-02-18
New Comment:
These strange UNKNOWN:0 properties appear after the get_object_vars()
call in buildMessage(). Without this call, everything looks fine.
Previous Comments:
[2004-03-05 04:25:53] jan at horde dot org
Since Stanislavs work on zend_mm.c the script doesn't segfault anymore,
but produces the error:
PHP Fatal error: Out of memory: cannot allocate -1263225620 bytes! in
/home/jan/prop_test/ob_vars.php on line 20
That's a step forward but still doesn't explain what's happening with
the MIME_Message object.
[2004-02-17 17:39:13] [EMAIL PROTECTED]
Here's the backtrace with today's CVS checkout:
#0 0x406d7563 in mmap () from /lib/i686/libc.so.6
#1 0x4066fdac in sYSMALLOc () from /lib/i686/libc.so.6
#2 0x4066c853 in malloc () from /lib/i686/libc.so.6
#3 0x08356954 in zend_mm_add_memory_block (heap=0x864c008,
block_size=3031741692)
at /usr/src/web/php/php5/Zend/zend_mm.c:223
#4 0x08356bfb in zend_mm_alloc (heap=0x864c008, size=3031741664) at
/usr/src/web/php/php5/Zend/zend_mm.c:321
#5 0x08356c22 in zend_mm_alloc (heap=0x864c008, size=3031741664) at
/usr/src/web/php/php5/Zend/zend_mm.c:325
#6 0x08356c22 in zend_mm_alloc (heap=0x864c008, size=3031741664) at
/usr/src/web/php/php5/Zend/zend_mm.c:325
#7 0x08356c22 in zend_mm_alloc (heap=0x864c008, size=3031741664) at
/usr/src/web/php/php5/Zend/zend_mm.c:325
#8 0x08356c22 in zend_mm_alloc (heap=0x864c008, size=3031741664) at
/usr/src/web/php/php5/Zend/zend_mm.c:325
[2004-02-12 07:18:51] jan at horde dot org
Can you find out what statement triggers that error from your bt?
Perhaps I am able to strip the example down if I know where to start.
No promises though.
[2004-02-04 20:35:55] [EMAIL PROTECTED]
This is the backtrace I got:
0x082c1c9d in _zend_is_inconsistent (ht=0x1b, file=0x8403060
"/usr/src/web/php/php5/Zend/zend_hash.c", line=841)
at /usr/src/web/php/php5/Zend/zend_hash.c:53
53 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 0x082c1c9d in _zend_is_inconsistent (ht=0x1b, file=0x8403060
"/usr/src/web/php/php5/Zend/zend_hash.c", line=841)
at /usr/src/web/php/php5/Zend/zend_hash.c:53
#1 0x082c3dcc in zend_hash_find (ht=0x1b, arKey=0x4111999c "__wakeup",
nKeyLength=9, pData=0xbfffd088)
at /usr/src/web/php/php5/Zend/zend_hash.c:841
#2 0x082b2489 in zend_call_function (fci=0xbfffd130, fci_cache=0x0)
at /usr/src/web/php/php5/Zend/zend_execute_API.c:619
#3 0x082b2033 in call_user_function_ex (function_table=0x8613e08,
object_pp=0xbfffd270, function_name=0xbfffd1a0,
retval_ptr_ptr=0xbfffd1bc, param_count=0, params=0x0,
no_separation=1, symbol_table=0x0)
at /usr/src/web/php/php5/Zend/zend_execute_API.c:517
#4 0x0825cb91 in object_common2 (rval=0xbfffd270, p=0xbfffd42c,
max=0x41117545 "", var_hash=0xbfffd430, elements=20)
at var_unserializer.re:233
#5 0x0825bc53 in php_var_unserialize (rval=0xbfffd270, p=0xbfffd42c,
max=0x41117545 "", var_hash=0xbfffd430)
at var_unserializer.re:452
#6 0x0825c945 in process_nested_data (rval=0xbfffd320, p=0xbfffd42c,
max=0x41117545 "", var_hash=0xbfffd430,
ht=0x4111985c, elements=0) at var_unserializer.re:173
#7 0x0825bea1 in php_var_unserialize (rval=0xbfffd320, p=0xbfffd42c,
max=0x41117545 "", var_hash=0xbfffd430)
at var_unserializer.re:361
#8 0x0825c945 in process_nested_data (rval=0xbfffd444, p=0xbfffd42c,
max=0x41117545 "", var_hash=0xbfffd430,
ht=0x41118918, elements=9) at var_unserializer.re:173
#9 0x0825cb1f in object_common2 (rval=0xbfffd444, p=0xbfffd42c,
max=0x41117545 "", var_hash=0xbfffd430, elements=22)
at var_unserializer.re:226
#10 0x0825bc53 in php_var_unserialize (rval=0xbfffd444, p=0xbfffd42c,
max=0x41117545 "", var_hash=0xbfffd430)
at var_unserializer.re:452
#11 0x0824fb39 in zif_unserialize (ht=1, return_value=0x40e6abdc,
this_ptr=0x0, return_value_used=1)
at /usr/src/web/php/php5/ext/standard/var.c:742
#12 0x082dd628 in zend_do_fcall_common_helper (execute_data=0xbfffd7a0,
opline=0x40e42aa0, op_array=0x40e426ac)
at /usr/src/web/php/php5/Zend/zend_execute.c:2558
#13 0x082ddc5e in zend_do_fcall_handler (execute_data=0xbfffd7a0,
opline=0x40e42aa0, op_array=0x40e426ac)
at /usr/src/web/php/php5/Zend/zend_execute.c:2700
#14 0x082da46c in execute (op_array=0x40e426ac) at
/usr/src/web/php/php5/Zend/zend_execute.c:1272
#15 0x082bcaa7 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/web/php/php5/Zend/zend.c:1051
#16 0x082
#27539 [Fbk->Opn]: PHP output: No input file specified
ID: 27539
User updated by: barry at teleserver dot es
Reported By: barry at teleserver dot es
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Sun Solaris 2.6
PHP Version: 4.3.4
New Comment:
First of all thanks for your request.
The PHP script seems to work fine from de unix command line:
About the C coded CGI: The webserver starts up a normal CGI programmed
in C. This CGY starts up the PHP script as it was from the command
line, by using the C system() function as followed:
system("/disco1/php/test.php");
About apache: For this tests I used the netscape webserver because of
some other problems I have using apache with this same configuration
and reported as bug: 27540
Previous Comments:
[2004-03-09 19:10:51] [EMAIL PROTECTED]
Does it work if you run the script on command line?
What do you mean with "I try to start up a PHP script from
a C coded binary CGY by the C system() functión" ???
How did you configure PHP for Apache in httpd.conf ??
[2004-03-09 12:10:18] barry at teleserver dot es
Description:
After instalation and configuratión I try to start up a PHP script from
a C coded binary CGY by the C system() functión. The text "No input
file specified" appears in the navigator.
Configure line:./configure
--prefix=/disco1/aplicaciones/QuorumEnterpriseCenter/apache/php_4.3.4
--with-oracle=/disco1/oracle/8.0.4 --with-oci8=/disco1/oracle/8.0.4
--enable-discard-path --enable-sockets --enable-force-cgi-redirect
--with-config-file-path=/disco1/aplicaciones/QuorumEnterpriseCenter/apache/php_4.3.4
Changes to php.ini: cgi.force_redirect = 0
Observations: This same configuration with earlier version of PHP works
fine.
Reproduce code:
---
PHP script:
#!/disco1/aplicaciones/QuorumEnterpriseCenter/apache/php_4.3.4/bin/php
Expected result:
Yust nothing, an empty page
Actual result:
--
"No input file specified"
--
Edit this bug report at http://bugs.php.net/?id=27539&edit=1
#27546 [Opn->Bgs]: Apache 2 Segfault when restarting
ID: 27546 Updated by: [EMAIL PROTECTED] Reported By: markus dot reinhardt at wsl dot ch -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Solaris 9 PHP Version: 4.3.4 New Comment: You're using atleast a couple of extensions (gettext and mcrypt most likely) that are not thread safe. Tip: Don't use MPM. Previous Comments: [2004-03-10 01:59:49] markus dot reinhardt at wsl dot ch Description: Apache 2 processes die when restarting and PHP module is loaded. Occurs only with Apache 2 mpm worker. See also bugs #17414 and #24567. Apache 2 mpm prefork is o.k. Apache 2 version: 2.0.48 PHP configure: configure --with-apxs2=/usr/local/apache/bin/apxs \ --with-config-file-path=/usr/local/apache/conf \ --with-openssl=/usr/local/ssl \ --with-oci8=/usr/local/app/oracle/product/prog92 \ --enable-sigchild \ --with-gettext \ --with-xml \ --with-mcrypt \ --with-pear \ --with-ldap \ --with-imap=/usr/local/imap-2002e \ --with-imap-ssl Reproduce code: --- Apache error_log: [notice] seg fault or similar nasty error detected in the parent process Expected result: Apache shouldn't die. -- Edit this bug report at http://bugs.php.net/?id=27546&edit=1
#19219 [Opn->Csd]: Cannot build with-informix for Apache DSO
ID: 19219 Updated by: [EMAIL PROTECTED] Reported By: jerrysmith at directvinternet dot com -Status: Open +Status: Closed Bug Type: Informix related Operating System: HPUX 11.0 PHP Version: 4.2.2 New Comment: Considered "closed" then. Previous Comments: [2004-03-09 20:07:50] jerrysmith at directvinternet dot com After waiting a year, I recently obtained yet again the 'latest' version only to experience the same issue. Seems no one knows how to fix LIBTOOL. I give up. I will stay with compiled C-langage CGI [2003-02-25 02:03:53] [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-02-20 07:45: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 This should be fixed now, at least that crypt issue is. [2002-11-06 09:22:58] jerrysmith at directvinternet dot com IMHO this problem is related to the make file that is included with the PHP that builds the module. This make file is including (erroneously) a static library. Yes if I run the build WITHOUT informix the PHP module works and the Apache can render the test page. I have been using the esql on HPUX for a few years now to write esql-C dynamically generated webpages..see www.cosworthvega.com [2002-11-06 03:31:08] cvb at clausvb dot de @sniper "this really is not PHP bug but libtool one." I don't know if it's a libtool bug or a bug within the IfxCSDK, but imho it's defenitly no bug within PHP, so I would close this bug. It could be an user error, too, because installing PHP with Ifx is tricky. We had to install two different IfxCSDK, to get it work. Regards, Claus 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/19219 -- Edit this bug report at http://bugs.php.net/?id=19219&edit=1
