#20389 [NEW]: user defined session handler is broken
From: [EMAIL PROTECTED] Operating system: Solaris PHP version: 4.2.3 PHP Bug Type: Session related Bug description: user defined session handler is broken System SunOS 5.8 Generic_108528-14 sun4u sparc SUNW,UltraAX-i2 (Solaris 8) with Apache 1.3.24 and Apache 1.3.26 This also affects PHP 4.2.2. If session.save_handler is set to user, the user defined functions appear to not be called. Furthermore - When Apache is restarted, after the configuration directive has been set to "user" it will very often fail to parse PHP code. I suppose this can be considered equivalent to a crash. My test scripts worked perfectly on my Mac OS X development machine, so I am reasonably sure that there is not an error in my code. My configure command: './configure' '--prefix=/._ark-deploy/php--4.2.3' '--with-mysql=/._ark-deploy/mysql--3.23.51' '--with-apxs=/._ark-deploy/apache--1.3.26/bin/apxs' '--with-config-file-path=/ark/etc' '--with-zlib' '--enable-xslt' '--with-xslt-sablot=/._ark-deploy/sablotron--0.96.1' '--with-sablot-js' '--with-expat-dir=/._ark-deploy/expat--1.95.4' '--with-gd=/._ark-deploy/gd--1.8.4' '--with-png-dir=/._ark-deploy/libpng--1.2.4' '--with-jpeg-dir=/._ark-deploy/jpeg--6b' '--with-freetype-dir=/._ark-deploy/freetype--2.1.2' '--with-java=/usr/java' '--with-ming=/._ark-deploy/ming--0.2a' '--enable-trans-sid' -- Edit bug report at http://bugs.php.net/?id=20389&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20389&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20389&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20389&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20389&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20389&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20389&r=support Expected behavior: http://bugs.php.net/fix.php?id=20389&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20389&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20389&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20389&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20389&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20389&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20389&r=isapi
#20389 [NoF->Opn]: user defined session handler is broken
ID: 20389 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: Session related Operating System: Solaris PHP Version: 4.2.3 New Comment: The reason that I didn't feedback on the was that the suggested fix was to move to a later build of PHP for Solaris . Since all our Solaris machines are in Production I couldn't risk the upgrade. I beleive this is still a significant problem Previous Comments: [2002-11-26 20:02:40] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-11-12 08:36:53] [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-11-12 08:19:15] [EMAIL PROTECTED] System SunOS 5.8 Generic_108528-14 sun4u sparc SUNW,UltraAX-i2 (Solaris 8) with Apache 1.3.24 and Apache 1.3.26 This also affects PHP 4.2.2. If session.save_handler is set to user, the user defined functions appear to not be called. Furthermore - When Apache is restarted, after the configuration directive has been set to "user" it will very often fail to parse PHP code. I suppose this can be considered equivalent to a crash. My test scripts worked perfectly on my Mac OS X development machine, so I am reasonably sure that there is not an error in my code. My configure command: './configure' '--prefix=/._ark-deploy/php--4.2.3' '--with-mysql=/._ark-deploy/mysql--3.23.51' '--with-apxs=/._ark-deploy/apache--1.3.26/bin/apxs' '--with-config-file-path=/ark/etc' '--with-zlib' '--enable-xslt' '--with-xslt-sablot=/._ark-deploy/sablotron--0.96.1' '--with-sablot-js' '--with-expat-dir=/._ark-deploy/expat--1.95.4' '--with-gd=/._ark-deploy/gd--1.8.4' '--with-png-dir=/._ark-deploy/libpng--1.2.4' '--with-jpeg-dir=/._ark-deploy/jpeg--6b' '--with-freetype-dir=/._ark-deploy/freetype--2.1.2' '--with-java=/usr/java' '--with-ming=/._ark-deploy/ming--0.2a' '--enable-trans-sid' -- Edit this bug report at http://bugs.php.net/?id=20389&edit=1
#20389 [Fbk->Opn]: scott@budomail.com
ID: 20389 User updated by: [EMAIL PROTECTED] -Summary: user defined session handler is broken Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Session related Operating System: Solaris PHP Version: 4.2.3 New Comment: OK, fair comment - I can do that. It's just that I had so many problems with the last upgrade that I didn't want to do it again (our system layout is *very* unusual) but your request is a reasonable one and I would like to help - so, to clarify, we're talking about moving 4.3.0 here, right? Previous Comments: [2002-11-27 06:24:33] [EMAIL PROTECTED] "The 4.2.x branch is as stable (or more stable) than the 4.2.3." did you mean the 4.3.x branch? :) [2002-11-27 06:18:31] [EMAIL PROTECTED] You have the option of trying 4.2.3 + some fixes or trying the release candidate of 4.3. The 4.2.x branch is as stable (or more stable) than the 4.2.3. If we were going to release a 4.2.4, that would be it. However, we are not going to do that; we are focusing on 4.3 instead. There is not much more we can do for you without access to your boxes, and why should we do that? You are the one being paid to look after your boxes, not us. Please test a newer version as suggested so that we can determine if the problem has been corrected already. If it has not, then someone may *volunteer* to look into the problem and resolve it. [Remember; you can test a newer version of PHP by running a separate apache instance on another port.] [2002-11-27 04:36:48] [EMAIL PROTECTED] The reason that I didn't feedback on the was that the suggested fix was to move to a later build of PHP for Solaris . Since all our Solaris machines are in Production I couldn't risk the upgrade. I beleive this is still a significant problem [2002-11-26 20:02:40] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-11-12 08:36:53] [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 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/20389 -- Edit this bug report at http://bugs.php.net/?id=20389&edit=1
#20389 [Fbk->Opn]: scott@budomail.com
ID: 20389 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Session related Operating System: Solaris PHP Version: 4.2.3 New Comment: Hi. I decided to go for a snapshot, and chose the latest and greatest: php4-STABLE-200211271830. Seems to be a bug in configure: checking Checking for libjava... configure: error: unable to find Java VM libraries in /usr/java The Java libraries on this machine have not moved since the 4.2.3 build and the configure options are identical, so I think that there is a good chance that the problem is with configure, around line 37071 - part of the libjava.so search process. Do you want a copy of the config.log? I've run out time this evening, but I'll ahve another look at the problem soon. Previous Comments: [2002-11-27 07:37:22] [EMAIL PROTECTED] The choice is yours; we'd really appreciate some feedback on the 4.3 branch, but you do have the option of the 4.2 branch. IMO, 4.3 branch is more likely to fix the problem, but may introduce others (but is actually pretty stable, as far as we can tell so far). Apparently, our snaps page no longer carries the 4.2 branch as the stable snap; if you want to try it, you can check it out of CVS (php.net/anoncvs.php; the branch tag is PHP_4_2). [You will need some build tools to generate configure] [2002-11-27 06:43:17] [EMAIL PROTECTED] OK, fair comment - I can do that. It's just that I had so many problems with the last upgrade that I didn't want to do it again (our system layout is *very* unusual) but your request is a reasonable one and I would like to help - so, to clarify, we're talking about moving 4.3.0 here, right? [2002-11-27 06:24:33] [EMAIL PROTECTED] "The 4.2.x branch is as stable (or more stable) than the 4.2.3." did you mean the 4.3.x branch? :) [2002-11-27 06:18:31] [EMAIL PROTECTED] You have the option of trying 4.2.3 + some fixes or trying the release candidate of 4.3. The 4.2.x branch is as stable (or more stable) than the 4.2.3. If we were going to release a 4.2.4, that would be it. However, we are not going to do that; we are focusing on 4.3 instead. There is not much more we can do for you without access to your boxes, and why should we do that? You are the one being paid to look after your boxes, not us. Please test a newer version as suggested so that we can determine if the problem has been corrected already. If it has not, then someone may *volunteer* to look into the problem and resolve it. [Remember; you can test a newer version of PHP by running a separate apache instance on another port.] [2002-11-27 04:36:48] [EMAIL PROTECTED] The reason that I didn't feedback on the was that the suggested fix was to move to a later build of PHP for Solaris . Since all our Solaris machines are in Production I couldn't risk the upgrade. I beleive this is still a significant problem 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/20389 -- Edit this bug report at http://bugs.php.net/?id=20389&edit=1
#20389 [Opn]: user defined session handler is broken
ID: 20389 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Solaris PHP Version: 4.2.3 New Comment: Hi sniper (?), Though I bow to your superior experience, I have to add that the location of the Java installation is being passed into configure with the --with-java option. This is what configure is for, and should be acceptable, right? Would you like me to try to build again and copy down the exact configure line that got invoked and mail it to you? It's the same one that got called on previous successful builds. I see that RC2 has just been released... I'll have another go with that later. Regards, Scott Previous Comments: [2002-11-28 04:46:18] [EMAIL PROTECTED] Fixed the summary line..and you propably don't have JAVA_LIBPATH set when you get that java error.. (it's required) [2002-11-27 15:50:58] [EMAIL PROTECTED] Hi. I decided to go for a snapshot, and chose the latest and greatest: php4-STABLE-200211271830. Seems to be a bug in configure: checking Checking for libjava... configure: error: unable to find Java VM libraries in /usr/java The Java libraries on this machine have not moved since the 4.2.3 build and the configure options are identical, so I think that there is a good chance that the problem is with configure, around line 37071 - part of the libjava.so search process. Do you want a copy of the config.log? I've run out time this evening, but I'll ahve another look at the problem soon. [2002-11-27 07:37:22] [EMAIL PROTECTED] The choice is yours; we'd really appreciate some feedback on the 4.3 branch, but you do have the option of the 4.2 branch. IMO, 4.3 branch is more likely to fix the problem, but may introduce others (but is actually pretty stable, as far as we can tell so far). Apparently, our snaps page no longer carries the 4.2 branch as the stable snap; if you want to try it, you can check it out of CVS (php.net/anoncvs.php; the branch tag is PHP_4_2). [You will need some build tools to generate configure] [2002-11-27 06:43:17] [EMAIL PROTECTED] OK, fair comment - I can do that. It's just that I had so many problems with the last upgrade that I didn't want to do it again (our system layout is *very* unusual) but your request is a reasonable one and I would like to help - so, to clarify, we're talking about moving 4.3.0 here, right? [2002-11-27 06:24:33] [EMAIL PROTECTED] "The 4.2.x branch is as stable (or more stable) than the 4.2.3." did you mean the 4.3.x branch? :) 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/20389 -- Edit this bug report at http://bugs.php.net/?id=20389&edit=1
Bug #16828: Excel remains resident in memory after using it via PHP+COM
From: [EMAIL PROTECTED] Operating system: Win 2000 PHP version: 4.2.0 PHP Bug Type: COM related Bug description: Excel remains resident in memory after using it via PHP+COM When using Excel.Application via the COM interface with PHP version (4.1.2 and 4.2.0), EXCEL.EXE stays resident in memory after script execution. To verify this is not an Excel issue, i created two separate scripts that did the same thing; one in perl, and one in PHP. After execution of the perl script, no EXCEL.EXE is in the Task list; yet after execution of the PHP script, EXCEL.EXE is in the Task list. Some more info and test scripts are available at: http://www.furt.com/code/php/com_issues/ -- Edit bug report at http://bugs.php.net/?id=16828&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16828&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16828&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16828&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16828&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16828&r=support Expected behavior: http://bugs.php.net/fix.php?id=16828&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16828&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16828&r=submittedtwice
Bug #17444: image* or imageCreateFrom* has size limitation in certain cases
From: [EMAIL PROTECTED] Operating system: WinXP PHP version: 4.1.2 PHP Bug Type: GD related Bug description: image* or imageCreateFrom* has size limitation in certain cases Once large.png is above a certain size, the image is not loaded past a certain offset. >From what I have seen though, if you pipe it out to a file imagePNG($im, "out.png"), then it is a complete file. I haven't expiremented with it enough to figure out which has the limitation. It would seem that image* does, but you can imageCreate(x,y) the same size image and the image does not get truncated on output to stdout. -- Edit bug report at http://bugs.php.net/?id=17444&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17444&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17444&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17444&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17444&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17444&r=support Expected behavior: http://bugs.php.net/fix.php?id=17444&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17444&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17444&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17444&r=globals
Bug #17468: CGI Error
From: [EMAIL PROTECTED] Operating system: Win2k/IIS PHP version: 4.1.2 PHP Bug Type: IIS related Bug description: CGI Error This problem occurs on 4.1.2 and 4.2.1 (maybe earlier versions, too) running on the CGI version for Win2k. This may be related to bug 16313. Randomly when I have a page redirect using the "location" header command, I get the message: "CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:" I can then refresh the browser and see the page (usually). It happens one time every 5 - 10 pages viewed. No event log entry is made, and no other information is provided. Here's the interesting bit: 1. It doesn't happen all the time 2. It doesn't happen at all on another Win2k machine of mine (same software config) The major difference between the two servers is the speed of the second server. The failing server is a dual processor server, while my happy server is a single processor PIII. -- Edit bug report at http://bugs.php.net/?id=17468&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17468&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17468&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17468&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17468&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17468&r=support Expected behavior: http://bugs.php.net/fix.php?id=17468&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17468&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17468&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17468&r=globals
Bug #9852 Updated: Header redirect and db connection cause "CGI misbehaved"
ID: 9852
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.1.1
New Comment:
I have the same problem, but I have some more interesting facts to
add...
I can reproduce it with mssql or odbc drivers, and intererstingly I can
get it breaking without using a header redirect.
I have an application that uses a frameset, and it appears that
sometimes (2 out of 3 times) it will give me the CGI error in multiple
frames, even though I've switched from header redirects to javascript
redirects. The URL changes at the browser, and it's the target page
that fails to load - not the page with the redirect code.
I have also had it failing on another page that used the IIS custom
error page functionality (i.e. replacing a 404 error with a nice custom
page)...again, a "fast redirect" issue, just like the original bug
reporter.
I do believe it is a timing problem - for me it only fails on a fast
dual-processor production server, but works fine on my slower
single-processor development server.
It also works fine if I shift the production server to a MySQL
database.
Note that I tried using the slowdown function above, but it didn't work
for me - perhaps multiple simultaneous page loads from the frameset
also breaks it?
By the way, mine fails on version 4.2.1 (released May 2002), so
obviously this little bug hasn't been caught for over a year.
I read above that the ISAPI version doesn't seem to do it, so I'll look
at implementing ISAPI for this job. However, that could mean that
it's to do with the persistant database connection, as the ISAPI module
remains loaded between page views.
Previous Comments:
[2002-04-22 17:50:12] [EMAIL PROTECTED]
It seems to be a timing problem (the PHP script outruns the IIS/MSSQL
or something). I came up with a simple solution to this by inserting a
short delay before every location header in my scripts.
I successfully made the workaround by using a function from a user
comment on the http://www.php.net/manual/en/function.usleep.php page
The function was:
--
function usleepWindows($usec) {
$start = gettimeofday();
do {
$stop = gettimeofday();
$timePassed = 100 * ($stop['sec'] - $start['sec'])
+ $stop['usec'] - $start['usec'];
}
while($timePassed < $usec);
}
--
Every header call should then look like this:
--
usleepWindows(20);
header("Location: http://www.myserver.dk/mypage.php";);
exit;
--
/watson
[2002-04-22 16:36:05] [EMAIL PROTECTED]
I tried to use both a MySQL and a MSSQL database server on the same
machine. When using the MySQL database there where no problem, and when
using the MSSQL database the problem was there.
So the problem seems to follow the combination of: IIS and MSSQL. I
have seen this error on all the PHP versions that I tried, and that is:
PHP 4.0.6, PHP 4.1.1 and PHP 4.1.2. I don't know if it's in any other
PHP versions besides that.
[2002-03-27 13:16:00] [EMAIL PROTECTED]
I can reproduce the problem with a simple "bounce" page (used for
measuring roundtrip times). With two active browser windows requesting
the same page, I see this error repeat (apparently at random) on one
out of 10-40 thousand requests.
This is with PHP 4.1.2 on Windows 2000 Professional w/ IIS 5 and all
the current updates from Windows Update.
bounce.php
--
BOUNCE
BOUNCING
BOUNCE
millisecondsrequests
latest
cumulative
[2002-01-16 13:45:10] [EMAIL PROTECTED]
I have tried this with W2K server and php 4.1.1 and I am getting the
same problem. Its taken a while and in fact it was only when pointed at
this bug request that the answer was apparent. My problem was it wasnt
constant, it was intimittent, so, I assumed my server was crud. I
actually had rulled out a PHP bug coz it works fine on my portable
(W2K pro) every time, but under server .. no.. Although my server does
also farm hits to the company intranet so is generally under a lot more
stress than my portable.
I will continue further tests to see if doing includes takes the
problem away, as certainly, it seems the javascript of window.location=
seems to be fine. I assume PHP is being too fast for itself?
[2002-01-12 06:58:59] [EMAIL PROTECTED]
Can you try this with 4.1.1? There been alot of fixes for IIS in the
recent versions.
Bug #17468 Updated: CGI Error
ID: 17468 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Win2k/IIS PHP Version: 4.1.2 New Comment: I have looked further into it, and found that it is related to the mssql and odbc drivers - it doesn't fail if I use mysql. Bug #9852 discusses this in more depth, and I feel that it is what I have, so I've posted some further comments to it. The issue appears to be timing related. Previous Comments: [2002-05-28 02:14:54] [EMAIL PROTECTED] This problem occurs on 4.1.2 and 4.2.1 (maybe earlier versions, too) running on the CGI version for Win2k. This may be related to bug 16313. Randomly when I have a page redirect using the "location" header command, I get the message: "CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:" I can then refresh the browser and see the page (usually). It happens one time every 5 - 10 pages viewed. No event log entry is made, and no other information is provided. Here's the interesting bit: 1. It doesn't happen all the time 2. It doesn't happen at all on another Win2k machine of mine (same software config) The major difference between the two servers is the speed of the second server. The failing server is a dual processor server, while my happy server is a single processor PIII. -- Edit this bug report at http://bugs.php.net/?id=17468&edit=1
Bug #9852 Updated: Header redirect and db connection cause "CGI misbehaved"
ID: 9852
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.1.1
New Comment:
I tried the ISAPI module, but that died in *lots* of other ways - I get
the impression I should stay with CGI :(
I've since tried playing with the mssql parameters in php.ini (thought
persistent connections may be the problem) with no success.
I think I may try that slowdown script, but against all queries - it
didn't work for me before the redirect - I don't always have a redirect
:(
Any other suggestions welcome...
Previous Comments:
[2002-05-28 06:10:52] [EMAIL PROTECTED]
I have the same problem, but I have some more interesting facts to
add...
I can reproduce it with mssql or odbc drivers, and intererstingly I can
get it breaking without using a header redirect.
I have an application that uses a frameset, and it appears that
sometimes (2 out of 3 times) it will give me the CGI error in multiple
frames, even though I've switched from header redirects to javascript
redirects. The URL changes at the browser, and it's the target page
that fails to load - not the page with the redirect code.
I have also had it failing on another page that used the IIS custom
error page functionality (i.e. replacing a 404 error with a nice custom
page)...again, a "fast redirect" issue, just like the original bug
reporter.
I do believe it is a timing problem - for me it only fails on a fast
dual-processor production server, but works fine on my slower
single-processor development server.
It also works fine if I shift the production server to a MySQL
database.
Note that I tried using the slowdown function above, but it didn't work
for me - perhaps multiple simultaneous page loads from the frameset
also breaks it?
By the way, mine fails on version 4.2.1 (released May 2002), so
obviously this little bug hasn't been caught for over a year.
I read above that the ISAPI version doesn't seem to do it, so I'll look
at implementing ISAPI for this job. However, that could mean that
it's to do with the persistant database connection, as the ISAPI module
remains loaded between page views.
[2002-04-22 17:50:12] [EMAIL PROTECTED]
It seems to be a timing problem (the PHP script outruns the IIS/MSSQL
or something). I came up with a simple solution to this by inserting a
short delay before every location header in my scripts.
I successfully made the workaround by using a function from a user
comment on the http://www.php.net/manual/en/function.usleep.php page
The function was:
--
function usleepWindows($usec) {
$start = gettimeofday();
do {
$stop = gettimeofday();
$timePassed = 100 * ($stop['sec'] - $start['sec'])
+ $stop['usec'] - $start['usec'];
}
while($timePassed < $usec);
}
--
Every header call should then look like this:
--
usleepWindows(20);
header("Location: http://www.myserver.dk/mypage.php";);
exit;
--
/watson
[2002-04-22 16:36:05] [EMAIL PROTECTED]
I tried to use both a MySQL and a MSSQL database server on the same
machine. When using the MySQL database there where no problem, and when
using the MSSQL database the problem was there.
So the problem seems to follow the combination of: IIS and MSSQL. I
have seen this error on all the PHP versions that I tried, and that is:
PHP 4.0.6, PHP 4.1.1 and PHP 4.1.2. I don't know if it's in any other
PHP versions besides that.
[2002-03-27 13:16:00] [EMAIL PROTECTED]
I can reproduce the problem with a simple "bounce" page (used for
measuring roundtrip times). With two active browser windows requesting
the same page, I see this error repeat (apparently at random) on one
out of 10-40 thousand requests.
This is with PHP 4.1.2 on Windows 2000 Professional w/ IIS 5 and all
the current updates from Windows Update.
bounce.php
--
BOUNCE
BOUNCING
BOUNCE
millisecondsrequests
latest
cumulative
[2002-01-16 13:45:10] [EMAIL PROTECTED]
I have tried this with W2K server and php 4.1.1 and I am getting the
same problem. Its taken a while and in fact it was only when pointed at
this bug request that the answer was apparent. My problem was it wasnt
constant, it was intimittent, so, I assumed my server was crud. I
actually had rulled out a PHP bug coz it works fine on my portable
(W2K pro) every time, but under server .. no.. Althoug
Bug #9852 Updated: Header redirect and db connection cause "CGI misbehaved"
ID: 9852
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.1.1
New Comment:
Some further info on the problem:
I applied the slowdown script after each query (in the simpleQuery
method of PEAR's mssql driver) but I still got the occasional CGI Error
(and it was awfully slow, too).
I then applied the slowdown script at the start of each script, but
still to no avail.
What I did notice was that it did help the problem, but not eliminate
it.My problem was still there when I refreshed my entire frameset
(which caused 6 scripts to run mssql db commands simultaneously).
Often 2 or 3 of these scripts failed with CGI errors.
Previous Comments:
[2002-05-28 08:30:12] [EMAIL PROTECTED]
I tried the ISAPI module, but that died in *lots* of other ways - I get
the impression I should stay with CGI :(
I've since tried playing with the mssql parameters in php.ini (thought
persistent connections may be the problem) with no success.
I think I may try that slowdown script, but against all queries - it
didn't work for me before the redirect - I don't always have a redirect
:(
Any other suggestions welcome...
[2002-05-28 06:10:52] [EMAIL PROTECTED]
I have the same problem, but I have some more interesting facts to
add...
I can reproduce it with mssql or odbc drivers, and intererstingly I can
get it breaking without using a header redirect.
I have an application that uses a frameset, and it appears that
sometimes (2 out of 3 times) it will give me the CGI error in multiple
frames, even though I've switched from header redirects to javascript
redirects. The URL changes at the browser, and it's the target page
that fails to load - not the page with the redirect code.
I have also had it failing on another page that used the IIS custom
error page functionality (i.e. replacing a 404 error with a nice custom
page)...again, a "fast redirect" issue, just like the original bug
reporter.
I do believe it is a timing problem - for me it only fails on a fast
dual-processor production server, but works fine on my slower
single-processor development server.
It also works fine if I shift the production server to a MySQL
database.
Note that I tried using the slowdown function above, but it didn't work
for me - perhaps multiple simultaneous page loads from the frameset
also breaks it?
By the way, mine fails on version 4.2.1 (released May 2002), so
obviously this little bug hasn't been caught for over a year.
I read above that the ISAPI version doesn't seem to do it, so I'll look
at implementing ISAPI for this job. However, that could mean that
it's to do with the persistant database connection, as the ISAPI module
remains loaded between page views.
[2002-04-22 17:50:12] [EMAIL PROTECTED]
It seems to be a timing problem (the PHP script outruns the IIS/MSSQL
or something). I came up with a simple solution to this by inserting a
short delay before every location header in my scripts.
I successfully made the workaround by using a function from a user
comment on the http://www.php.net/manual/en/function.usleep.php page
The function was:
--
function usleepWindows($usec) {
$start = gettimeofday();
do {
$stop = gettimeofday();
$timePassed = 100 * ($stop['sec'] - $start['sec'])
+ $stop['usec'] - $start['usec'];
}
while($timePassed < $usec);
}
--
Every header call should then look like this:
--
usleepWindows(20);
header("Location: http://www.myserver.dk/mypage.php";);
exit;
--
/watson
[2002-04-22 16:36:05] [EMAIL PROTECTED]
I tried to use both a MySQL and a MSSQL database server on the same
machine. When using the MySQL database there where no problem, and when
using the MSSQL database the problem was there.
So the problem seems to follow the combination of: IIS and MSSQL. I
have seen this error on all the PHP versions that I tried, and that is:
PHP 4.0.6, PHP 4.1.1 and PHP 4.1.2. I don't know if it's in any other
PHP versions besides that.
[2002-03-27 13:16:00] [EMAIL PROTECTED]
I can reproduce the problem with a simple "bounce" page (used for
measuring roundtrip times). With two active browser windows requesting
the same page, I see this error repeat (apparently at random) on one
out of 10-40 thousand requests.
This is with PHP 4.1.2 on Windows 2000 Professional w/ IIS 5 and all
the current updates
#19528 [NEW]: odbc_function_row() doesn't returned true if there is one row only
From: [EMAIL PROTECTED]
Operating system: AIX (UNIX)
PHP version: 4.2.2
PHP Bug Type: ODBC related
Bug description: odbc_function_row() doesn't returned true if there is one row only
The odbc_fetch_row() function worked fine when I used PHP version 4.0.6 but
when I upgraded PHP to 4.2.2, the odbc_fetch_row() doesn't work when there
is 1 row.
When I use the echo command to see the response to the odbc_fetch_row()
before the while loop, it showed that it doesn't return True or anything
when there is 1 row.
I made the workaround to the problem by including the "$bug_workaround"
into the script, this is to be use as 'row number' as shown in the PHP
manual at "http://www.php.net/manual/en/function.odbc-fetch-row.php";.
I enclosed two clipping to point this out. The 1st clipping is the one
that don't work and the 2nd clipping showed the work-around to it. In
this script, you'll find the word, 'INQUIRIES', it is a table that contain
number of companies and users. What the script does is to display each
user whenever the company is selected. The cool thing about it is it
won't display the data if there is no row for any user.
--clip--
$cid = odbc_connect('blah blah blah');
$ask7 = "SELECT * FROM INQUIRIES WHERE USER_ID = '38SCK3'";
$R7 = odbc_exec($cid,$ask7);
$result = odbc_result($R7,1);
echo "Result or No Result??? --> ".odbc_fetch_row($R7);
while (odbc_fetch_row($R7))
{
odbc_fetch_into($R7,$inquiry,$inq_c);
echo $inquiry[0], $inquiry[1];
}
--clip--
--clip--
$cid = odbc_connect('blah blah blah');
$ask7 = "SELECT * FROM INQUIRIES WHERE USER_ID = '38SCK3'";
$R7 = odbc_exec($cid,$ask7);
$result = odbc_result($R7,1);
echo "Result or No Result??? --> ".odbc_fetch_row($R7);
$bug_workaround=0;
while (odbc_fetch_row($R7,++$bug_workaround))
{
odbc_fetch_into($R7,$inquiry,$inq_c);
echo $inquiry[0], $inquiry[1];
}
--clip--
--
Edit bug report at http://bugs.php.net/?id=19528&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19528&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19528&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19528&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19528&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=19528&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19528&r=support
Expected behavior: http://bugs.php.net/fix.php?id=19528&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19528&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19528&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19528&r=globals
#19528 [Fbk->Opn]: odbc_function_row() doesn't returned true if there is one row only
ID: 19528
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: ODBC related
Operating System: AIX (UNIX)
PHP Version: 4.2.2
New Comment:
The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for
database.
The odbc_fetch_into() worked fine. To test it the functionality of the
odbc_fetch_row(), I do the echo command followed by 'Result or No
Result??? -->' then the odbc_fetch_row(). This tell me whether the
result is returned in form of data or not. So, this showed the problem
lie with odbc_fetch_into().
Because when there is two rows, it work okay and allow the
odbc_fetch_into() to show two rows. When I delete one row, the
odbc_fetch_row() saw one row and it does not allow the
odbc_fetch_into() to show the one row.
Previous Comments:
[2002-09-22 20:00:43] [EMAIL PROTECTED]
Considering the code in question hasn't changed since 4.0.5, I don't
think this is a bug in PHP. Regardless what ODBC driver, and DB are
you connecting to?
And are you sure you're not refering to odbc_fetch_into? Because that
prototype did change...
[2002-09-20 12:38:29] [EMAIL PROTECTED]
The odbc_fetch_row() function worked fine when I used PHP version 4.0.6
but when I upgraded PHP to 4.2.2, the odbc_fetch_row() doesn't work
when there is 1 row.
When I use the echo command to see the response to the odbc_fetch_row()
before the while loop, it showed that it doesn't return True or
anything when there is 1 row.
I made the workaround to the problem by including the "$bug_workaround"
into the script, this is to be use as 'row number' as shown in the PHP
manual at "http://www.php.net/manual/en/function.odbc-fetch-row.php";.
I enclosed two clipping to point this out. The 1st clipping is the one
that don't work and the 2nd clipping showed the work-around to it. In
this script, you'll find the word, 'INQUIRIES', it is a table that
contain number of companies and users. What the script does is to
display each user whenever the company is selected. The cool thing
about it is it won't display the data if there is no row for any user.
--clip--
$cid = odbc_connect('blah blah blah');
$ask7 = "SELECT * FROM INQUIRIES WHERE USER_ID = '38SCK3'";
$R7 = odbc_exec($cid,$ask7);
$result = odbc_result($R7,1);
echo "Result or No Result??? --> ".odbc_fetch_row($R7);
while (odbc_fetch_row($R7))
{
odbc_fetch_into($R7,$inquiry,$inq_c);
echo $inquiry[0], $inquiry[1];
}
--clip--
--clip--
$cid = odbc_connect('blah blah blah');
$ask7 = "SELECT * FROM INQUIRIES WHERE USER_ID = '38SCK3'";
$R7 = odbc_exec($cid,$ask7);
$result = odbc_result($R7,1);
echo "Result or No Result??? --> ".odbc_fetch_row($R7);
$bug_workaround=0;
while (odbc_fetch_row($R7,++$bug_workaround))
{
odbc_fetch_into($R7,$inquiry,$inq_c);
echo $inquiry[0], $inquiry[1];
}
--clip--
--
Edit this bug report at http://bugs.php.net/?id=19528&edit=1
#19528 [Opn]: odbc_function_row() doesn't returned true if there is one row only
ID: 19528
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: ODBC related
Operating System: AIX (UNIX)
PHP Version: 4.2.2
New Comment:
Forget the last comment I made, I typed down the wrong function, so use
this comment instead of hte last comment. Should have read it once
more time to make sure I don't overlook something.
---
The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for
database.
The odbc_fetch_into() worked fine. To test it the functionality of the
odbc_fetch_row(), I do the echo command followed by 'Result or No
Result??? -->' then the odbc_fetch_row(). This tell me whether the
result is returned in form of data or not. So, this showed the problem
lie with odbc_fetch_row().
Because when there is two rows, it work okay and allow the
odbc_fetch_into() to show two rows. When I delete one row, the
odbc_fetch_row() saw one row and it does not allow the
odbc_fetch_into() to show the one row.
Previous Comments:
[2002-09-23 08:39:07] [EMAIL PROTECTED]
The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for
database.
The odbc_fetch_into() worked fine. To test it the functionality of the
odbc_fetch_row(), I do the echo command followed by 'Result or No
Result??? -->' then the odbc_fetch_row(). This tell me whether the
result is returned in form of data or not. So, this showed the problem
lie with odbc_fetch_into().
Because when there is two rows, it work okay and allow the
odbc_fetch_into() to show two rows. When I delete one row, the
odbc_fetch_row() saw one row and it does not allow the
odbc_fetch_into() to show the one row.
[2002-09-22 20:00:43] [EMAIL PROTECTED]
Considering the code in question hasn't changed since 4.0.5, I don't
think this is a bug in PHP. Regardless what ODBC driver, and DB are
you connecting to?
And are you sure you're not refering to odbc_fetch_into? Because that
prototype did change...
[2002-09-20 12:38:29] [EMAIL PROTECTED]
The odbc_fetch_row() function worked fine when I used PHP version 4.0.6
but when I upgraded PHP to 4.2.2, the odbc_fetch_row() doesn't work
when there is 1 row.
When I use the echo command to see the response to the odbc_fetch_row()
before the while loop, it showed that it doesn't return True or
anything when there is 1 row.
I made the workaround to the problem by including the "$bug_workaround"
into the script, this is to be use as 'row number' as shown in the PHP
manual at "http://www.php.net/manual/en/function.odbc-fetch-row.php";.
I enclosed two clipping to point this out. The 1st clipping is the one
that don't work and the 2nd clipping showed the work-around to it. In
this script, you'll find the word, 'INQUIRIES', it is a table that
contain number of companies and users. What the script does is to
display each user whenever the company is selected. The cool thing
about it is it won't display the data if there is no row for any user.
--clip--
$cid = odbc_connect('blah blah blah');
$ask7 = "SELECT * FROM INQUIRIES WHERE USER_ID = '38SCK3'";
$R7 = odbc_exec($cid,$ask7);
$result = odbc_result($R7,1);
echo "Result or No Result??? --> ".odbc_fetch_row($R7);
while (odbc_fetch_row($R7))
{
odbc_fetch_into($R7,$inquiry,$inq_c);
echo $inquiry[0], $inquiry[1];
}
--clip--
--clip--
$cid = odbc_connect('blah blah blah');
$ask7 = "SELECT * FROM INQUIRIES WHERE USER_ID = '38SCK3'";
$R7 = odbc_exec($cid,$ask7);
$result = odbc_result($R7,1);
echo "Result or No Result??? --> ".odbc_fetch_row($R7);
$bug_workaround=0;
while (odbc_fetch_row($R7,++$bug_workaround))
{
odbc_fetch_into($R7,$inquiry,$inq_c);
echo $inquiry[0], $inquiry[1];
}
--clip--
--
Edit this bug report at http://bugs.php.net/?id=19528&edit=1
#19528 [Opn]: odbc_function_row() doesn't returned true if there is one row only
ID: 19528
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: ODBC related
Operating System: AIX (UNIX)
PHP Version: 4.2.2
New Comment:
I found one interesting observation when I write a short test script.
It showed that if I use the odbc_fetch_row() only, it work fine. It
showed that if I use the odbc_fetch_into() only, it work fine. It
showed that if I use both the odbc_fetch_row() and odbc_fetch_into(),
it showed a minor problem, that is not being able to display one row if
there is only one row. But work fine when there's two rows or more.
Previous Comments:
[2002-09-23 08:41:14] [EMAIL PROTECTED]
Forget the last comment I made, I typed down the wrong function, so use
this comment instead of hte last comment. Should have read it once
more time to make sure I don't overlook something.
---
The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for
database.
The odbc_fetch_into() worked fine. To test it the functionality of the
odbc_fetch_row(), I do the echo command followed by 'Result or No
Result??? -->' then the odbc_fetch_row(). This tell me whether the
result is returned in form of data or not. So, this showed the problem
lie with odbc_fetch_row().
Because when there is two rows, it work okay and allow the
odbc_fetch_into() to show two rows. When I delete one row, the
odbc_fetch_row() saw one row and it does not allow the
odbc_fetch_into() to show the one row.
[2002-09-23 08:39:07] [EMAIL PROTECTED]
The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for
database.
The odbc_fetch_into() worked fine. To test it the functionality of the
odbc_fetch_row(), I do the echo command followed by 'Result or No
Result??? -->' then the odbc_fetch_row(). This tell me whether the
result is returned in form of data or not. So, this showed the problem
lie with odbc_fetch_into().
Because when there is two rows, it work okay and allow the
odbc_fetch_into() to show two rows. When I delete one row, the
odbc_fetch_row() saw one row and it does not allow the
odbc_fetch_into() to show the one row.
[2002-09-22 20:00:43] [EMAIL PROTECTED]
Considering the code in question hasn't changed since 4.0.5, I don't
think this is a bug in PHP. Regardless what ODBC driver, and DB are
you connecting to?
And are you sure you're not refering to odbc_fetch_into? Because that
prototype did change...
[2002-09-20 12:38:29] [EMAIL PROTECTED]
The odbc_fetch_row() function worked fine when I used PHP version 4.0.6
but when I upgraded PHP to 4.2.2, the odbc_fetch_row() doesn't work
when there is 1 row.
When I use the echo command to see the response to the odbc_fetch_row()
before the while loop, it showed that it doesn't return True or
anything when there is 1 row.
I made the workaround to the problem by including the "$bug_workaround"
into the script, this is to be use as 'row number' as shown in the PHP
manual at "http://www.php.net/manual/en/function.odbc-fetch-row.php";.
I enclosed two clipping to point this out. The 1st clipping is the one
that don't work and the 2nd clipping showed the work-around to it. In
this script, you'll find the word, 'INQUIRIES', it is a table that
contain number of companies and users. What the script does is to
display each user whenever the company is selected. The cool thing
about it is it won't display the data if there is no row for any user.
--clip--
$cid = odbc_connect('blah blah blah');
$ask7 = "SELECT * FROM INQUIRIES WHERE USER_ID = '38SCK3'";
$R7 = odbc_exec($cid,$ask7);
$result = odbc_result($R7,1);
echo "Result or No Result??? --> ".odbc_fetch_row($R7);
while (odbc_fetch_row($R7))
{
odbc_fetch_into($R7,$inquiry,$inq_c);
echo $inquiry[0], $inquiry[1];
}
--clip--
--clip--
$cid = odbc_connect('blah blah blah');
$ask7 = "SELECT * FROM INQUIRIES WHERE USER_ID = '38SCK3'";
$R7 = odbc_exec($cid,$ask7);
$result = odbc_result($R7,1);
echo "Result or No Result??? --> ".odbc_fetch_row($R7);
$bug_workaround=0;
while (odbc_fetch_row($R7,++$bug_workaround))
{
odbc_fetch_into($R7,$inquiry,$inq_c);
echo $inquiry[0], $inquiry[1];
}
--clip--
--
Edit this bug report at http://bugs.php.net/?id=19528&edit=1
#19528 [Fbk->Opn]: odbc_function_row() doesn't returned true if there is one row only
ID: 19528 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: AIX (UNIX) PHP Version: 4.2.2 New Comment: I have found no sql.log file on this webserver. Any comments or suggestion? Previous Comments: [2002-09-26 10:47:30] [EMAIL PROTECTED] can you please make a sql log file and post the results of this? It would make debugging this a lot easier :) [2002-09-26 10:32:59] [EMAIL PROTECTED] I found one interesting observation when I write a short test script. It showed that if I use the odbc_fetch_row() only, it work fine. It showed that if I use the odbc_fetch_into() only, it work fine. It showed that if I use both the odbc_fetch_row() and odbc_fetch_into(), it showed a minor problem, that is not being able to display one row if there is only one row. But work fine when there's two rows or more. [2002-09-23 08:41:14] [EMAIL PROTECTED] Forget the last comment I made, I typed down the wrong function, so use this comment instead of hte last comment. Should have read it once more time to make sure I don't overlook something. --- The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for database. The odbc_fetch_into() worked fine. To test it the functionality of the odbc_fetch_row(), I do the echo command followed by 'Result or No Result??? -->' then the odbc_fetch_row(). This tell me whether the result is returned in form of data or not. So, this showed the problem lie with odbc_fetch_row(). Because when there is two rows, it work okay and allow the odbc_fetch_into() to show two rows. When I delete one row, the odbc_fetch_row() saw one row and it does not allow the odbc_fetch_into() to show the one row. [2002-09-23 08:39:07] [EMAIL PROTECTED] The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for database. The odbc_fetch_into() worked fine. To test it the functionality of the odbc_fetch_row(), I do the echo command followed by 'Result or No Result??? -->' then the odbc_fetch_row(). This tell me whether the result is returned in form of data or not. So, this showed the problem lie with odbc_fetch_into(). Because when there is two rows, it work okay and allow the odbc_fetch_into() to show two rows. When I delete one row, the odbc_fetch_row() saw one row and it does not allow the odbc_fetch_into() to show the one row. [2002-09-22 20:00:43] [EMAIL PROTECTED] Considering the code in question hasn't changed since 4.0.5, I don't think this is a bug in PHP. Regardless what ODBC driver, and DB are you connecting to? And are you sure you're not refering to odbc_fetch_into? Because that prototype did change... 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/19528 -- Edit this bug report at http://bugs.php.net/?id=19528&edit=1
#19528 [Opn]: odbc_function_row() doesn't returned true if there is one row only
ID: 19528 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating System: AIX (UNIX) PHP Version: 4.2.2 New Comment: To my dismay, I thought that including hte counter as the 2nd paramater to the odbc_fetch_row() function would fix this problem but it turned out that it doesn't. It turned out that it help a little bit but it is only an intermitted problem. Previous Comments: [2002-09-26 10:57:50] [EMAIL PROTECTED] I have found no sql.log file on this webserver. Any comments or suggestion? [2002-09-26 10:47:30] [EMAIL PROTECTED] can you please make a sql log file and post the results of this? It would make debugging this a lot easier :) [2002-09-26 10:32:59] [EMAIL PROTECTED] I found one interesting observation when I write a short test script. It showed that if I use the odbc_fetch_row() only, it work fine. It showed that if I use the odbc_fetch_into() only, it work fine. It showed that if I use both the odbc_fetch_row() and odbc_fetch_into(), it showed a minor problem, that is not being able to display one row if there is only one row. But work fine when there's two rows or more. [2002-09-23 08:41:14] [EMAIL PROTECTED] Forget the last comment I made, I typed down the wrong function, so use this comment instead of hte last comment. Should have read it once more time to make sure I don't overlook something. --- The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for database. The odbc_fetch_into() worked fine. To test it the functionality of the odbc_fetch_row(), I do the echo command followed by 'Result or No Result??? -->' then the odbc_fetch_row(). This tell me whether the result is returned in form of data or not. So, this showed the problem lie with odbc_fetch_row(). Because when there is two rows, it work okay and allow the odbc_fetch_into() to show two rows. When I delete one row, the odbc_fetch_row() saw one row and it does not allow the odbc_fetch_into() to show the one row. [2002-09-23 08:39:07] [EMAIL PROTECTED] The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for database. The odbc_fetch_into() worked fine. To test it the functionality of the odbc_fetch_row(), I do the echo command followed by 'Result or No Result??? -->' then the odbc_fetch_row(). This tell me whether the result is returned in form of data or not. So, this showed the problem lie with odbc_fetch_into(). Because when there is two rows, it work okay and allow the odbc_fetch_into() to show two rows. When I delete one row, the odbc_fetch_row() saw one row and it does not allow the odbc_fetch_into() to show the one row. 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/19528 -- Edit this bug report at http://bugs.php.net/?id=19528&edit=1
#19528 [Opn]: odbc_function_row() doesn't returned true if there is one row only
ID: 19528 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating System: AIX (UNIX) PHP Version: 4.2.2 New Comment: Disregard my last comment, the bug workaround still work. I made the typo in the counter. So, that leave the original bug as unchanged. Previous Comments: [2002-09-26 11:01:23] [EMAIL PROTECTED] To my dismay, I thought that including hte counter as the 2nd paramater to the odbc_fetch_row() function would fix this problem but it turned out that it doesn't. It turned out that it help a little bit but it is only an intermitted problem. [2002-09-26 10:57:50] [EMAIL PROTECTED] I have found no sql.log file on this webserver. Any comments or suggestion? [2002-09-26 10:47:30] [EMAIL PROTECTED] can you please make a sql log file and post the results of this? It would make debugging this a lot easier :) [2002-09-26 10:32:59] [EMAIL PROTECTED] I found one interesting observation when I write a short test script. It showed that if I use the odbc_fetch_row() only, it work fine. It showed that if I use the odbc_fetch_into() only, it work fine. It showed that if I use both the odbc_fetch_row() and odbc_fetch_into(), it showed a minor problem, that is not being able to display one row if there is only one row. But work fine when there's two rows or more. [2002-09-23 08:41:14] [EMAIL PROTECTED] Forget the last comment I made, I typed down the wrong function, so use this comment instead of hte last comment. Should have read it once more time to make sure I don't overlook something. --- The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for database. The odbc_fetch_into() worked fine. To test it the functionality of the odbc_fetch_row(), I do the echo command followed by 'Result or No Result??? -->' then the odbc_fetch_row(). This tell me whether the result is returned in form of data or not. So, this showed the problem lie with odbc_fetch_row(). Because when there is two rows, it work okay and allow the odbc_fetch_into() to show two rows. When I delete one row, the odbc_fetch_row() saw one row and it does not allow the odbc_fetch_into() to show the one row. 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/19528 -- Edit this bug report at http://bugs.php.net/?id=19528&edit=1
#19528 [Fbk->Opn]: odbc_function_row() doesn't returned true if there is one row only
ID: 19528 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: AIX (UNIX) PHP Version: 4.2.2 New Comment: Oh! That's what it is. No, I do not use the iODBC or OpenLink or anything of that sort. There is no such as odbc.ini feature for IBM DB2. I use this configure command before compiling PHP. --clip-- ./configure --with-apache=../apache_1.3.26 --with-ibm-db2=/usr/lpp/db2_06_01 --with-openssl=../openssl-0.9.6d --with-mcrypt=../libmcrypt-2.5.2 --without-mysql --with-config-file-path=../../apache/conf --enable-track-vars --with-curl --with-xml --clip-- Previous Comments: [2002-09-26 11:46:27] [EMAIL PROTECTED] Creating a sql.log is typically defined in your odbc.ini file, per DSN. You may have to alter that to turn on logging. As per the specific lines, that depends upon your vendors specific implementation. [2002-09-26 11:11:36] [EMAIL PROTECTED] Disregard my last comment, the bug workaround still work. I made the typo in the counter. So, that leave the original bug as unchanged. [2002-09-26 11:01:23] [EMAIL PROTECTED] To my dismay, I thought that including hte counter as the 2nd paramater to the odbc_fetch_row() function would fix this problem but it turned out that it doesn't. It turned out that it help a little bit but it is only an intermitted problem. [2002-09-26 10:57:50] [EMAIL PROTECTED] I have found no sql.log file on this webserver. Any comments or suggestion? [2002-09-26 10:47:30] [EMAIL PROTECTED] can you please make a sql log file and post the results of this? It would make debugging this a lot easier :) 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/19528 -- Edit this bug report at http://bugs.php.net/?id=19528&edit=1
#19528 [Fbk->Opn]: odbc_function_row() doesn't returned true if there is one row only
ID: 19528 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: AIX (UNIX) PHP Version: 4.2.2 New Comment: I looked at few IBM books and IBM website and could find no such documentation about sql.log. I also tried typing in the command "find . -name '*log' -print" and got a few IBM DB2 logs but they aren't related to sql.log. Right now, I'm out of luck. Someone else will know more about it better than I do. Previous Comments: [2002-09-26 15:53:58] [EMAIL PROTECTED] I'm not intimately familiar with the DB2 system, but there has to be a way to turn on ODBC logging. This is a fairly standard debugging method. Can you please check your documentation for it... it would make tracking this bug down infinately easier. [2002-09-26 11:56:56] [EMAIL PROTECTED] Oh! That's what it is. No, I do not use the iODBC or OpenLink or anything of that sort. There is no such as odbc.ini feature for IBM DB2. I use this configure command before compiling PHP. --clip-- ./configure --with-apache=../apache_1.3.26 --with-ibm-db2=/usr/lpp/db2_06_01 --with-openssl=../openssl-0.9.6d --with-mcrypt=../libmcrypt-2.5.2 --without-mysql --with-config-file-path=../../apache/conf --enable-track-vars --with-curl --with-xml --clip-- [2002-09-26 11:46:27] [EMAIL PROTECTED] Creating a sql.log is typically defined in your odbc.ini file, per DSN. You may have to alter that to turn on logging. As per the specific lines, that depends upon your vendors specific implementation. [2002-09-26 11:11:36] [EMAIL PROTECTED] Disregard my last comment, the bug workaround still work. I made the typo in the counter. So, that leave the original bug as unchanged. [2002-09-26 11:01:23] [EMAIL PROTECTED] To my dismay, I thought that including hte counter as the 2nd paramater to the odbc_fetch_row() function would fix this problem but it turned out that it doesn't. It turned out that it help a little bit but it is only an intermitted problem. 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/19528 -- Edit this bug report at http://bugs.php.net/?id=19528&edit=1
#19741 [NEW]: Path no longer works in unlink, pdf_open_file
From: [EMAIL PROTECTED]
Operating system: linux 2.4.18
PHP version: 4.2.3
PHP Bug Type: Apache2 related
Bug description: Path no longer works in unlink, pdf_open_file
In old apache
1.3.26/php.4.0.6
if (file_exists("somefile.pdf")) unlink("somefile.pdf");
pdf_open_file($pdf, "somefile.pdf");
would check the current directory.
ie .. it will do these actions whereever documentroot happens to be.
now it does not do this anymore in Apache/2.0.42 (Unix) mod_ssl/2.0.42
OpenSSL/0.9.6b PHP/4.2.3
in apache 2.0.42
getcwd() returns the current working directory
however if i do chdir (documentroot)
the first command
if (file_exists("somefile.pdf")) unlink("somefile.pdf");
will work
but the 2nd
pdf_open_file($pdf, "somefile.pdf");
will not.
the workaround seems to be to work is to include the whole path
pdf_open_file($pdf, "$documentroot/somefile.pdf");
which appears to work .. is this a bug or a feature?
--
Edit bug report at http://bugs.php.net/?id=19741&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19741&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=19741&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=19741&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19741&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=19741&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19741&r=support
Expected behavior: http://bugs.php.net/fix.php?id=19741&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19741&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19741&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=19741&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19741&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=19741&r=dst
#19741 [Opn]: Path no longer works in unlink, pdf_open_file
ID: 19741
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache2 related
Operating System: linux 2.4.18
PHP Version: 4.2.3
New Comment:
on further examination it appears only
pdf_open_file($pdf, "somefile.pdf");
does not work and must be substituted with
pdf_open_file($pdf, "$documentroot/somefile.pdf");
(or the smart example)
i took the liberty of checking with pdf.c and it doesnt appear to be
any different.
Previous Comments:
[2002-10-03 18:26:38] [EMAIL PROTECTED]
A smarter variant of the workaround is to use
file_exists(realpath('somefile.pdf'));
which works quite fine on Apache 2.0.40
Philipp
[2002-10-03 14:48:06] [EMAIL PROTECTED]
In old apache
1.3.26/php.4.0.6
if (file_exists("somefile.pdf")) unlink("somefile.pdf");
pdf_open_file($pdf, "somefile.pdf");
would check the current directory.
ie .. it will do these actions whereever documentroot happens to be.
now it does not do this anymore in Apache/2.0.42 (Unix) mod_ssl/2.0.42
OpenSSL/0.9.6b PHP/4.2.3
in apache 2.0.42
getcwd() returns the current working directory
however if i do chdir (documentroot)
the first command
if (file_exists("somefile.pdf")) unlink("somefile.pdf");
will work
but the 2nd
pdf_open_file($pdf, "somefile.pdf");
will not.
the workaround seems to be to work is to include the whole path
pdf_open_file($pdf, "$documentroot/somefile.pdf");
which appears to work .. is this a bug or a feature?
--
Edit this bug report at http://bugs.php.net/?id=19741&edit=1
#19804 [Com]: PHP does not take the Libmcrypt ciphers when compiling
ID: 19804
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Compile Issues
Operating System: AIX 4.3.3
PHP Version: 4.2.3
New Comment:
Eh, Didn't finish with all of hte clipping. Could be that bug database
can't accept them all. By the make, I did hte best I could on make
because it is too long for the computer screen. I tried this command,
"make > log_make" but found that not all of hte data go into the
log_make and whatever is left is spitted out onto the screen.
Previous Comments:
[2002-10-07 13:05:35] [EMAIL PROTECTED]
Since Bug #19803 is bogus. I decided to compile libmcrypt and see if
the problem with libmcrypt. It worked out okay, so it is PHP that did
not take in the ciphers from libmcrypt when compiling, so I'm filling a
new bug report.
When I use some PHP function for mcrypt, like
"mcrypt_get_block_size('tripledes', 'ecb')" or
"mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256,
MCRYPT_MODE_ECB), MCRYPT_RAND)". I get all of the warning messages.
like "Warning: mcrypt module initialization failed in ..." or "Warning:
could not open encryption module ". This bug could be critical
because if someone had encrypted the data and one day upgrade PHP and
hte encryption get affected.
I use Libmcrypt-2.5.3, when compiled and installed. The file goes to
both the "/usr/local/lib" and "/usr/local/lib/libmcrypt". I'll include
the brief clip down below. The 1st clipping is for "/usr/local/lib"
and there is one directory as shown in the list.
--clip--
drwxr-xr-x 2 root system 1536 Oct 07 13:30 libmcrypt
-rwxr-xr-x 1 root system 53221 Oct 07 13:30 libmcrypt.a
-rwxr-xr-x 1 root system 738 Oct 07 13:30 libmcrypt.la
--clip--
The 2nd clipping, which is inside the directory of
"/usr/local/lib/libmcrypt".
--clip--
drwxr-xr-x 2 root system 1536 Oct 07 13:30 .
drwxr-xr-x 21 root system 1536 Oct 07 13:30 ..
-rwxr-xr-x 1 root system 750 Oct 07 13:30 arcfour.la
-rwxr-xr-x 1 root system 790 Oct 07 13:30
blowfish-compat.la
-rwxr-xr-x 1 root system 755 Oct 07 13:30 blowfish.la
-rwxr-xr-x 1 root system 755 Oct 07 13:30 cast-128.la
-rwxr-xr-x 1 root system 755 Oct 07 13:29 cast-256.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 cbc.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 cfb.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 ctr.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 des.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 ecb.la
-rwxr-xr-x 1 root system 745 Oct 07 13:30 enigma.la
-rwxr-xr-x 1 root system 735 Oct 07 13:30 gost.la
-rwxr-xr-x 1 root system 13041 Oct 07 13:30 libarcfour.a
-rwxr-xr-x 1 root system 19202 Oct 07 13:30
libblowfish-compat.a
-rwxr-xr-x 1 root system 18270 Oct 07 13:30 libblowfish.a
-rwxr-xr-x 1 root system 25990 Oct 07 13:30 libcast-128.a
-rwxr-xr-x 1 root system 25937 Oct 07 13:29 libcast-256.a
-rwxr-xr-x 1 root system 11262 Oct 07 13:30 libcbc.a
-rwxr-xr-x 1 root system 11056 Oct 07 13:30 libcfb.a
-rwxr-xr-x 1 root system 11822 Oct 07 13:30 libctr.a
-rwxr-xr-x 1 root system 17804 Oct 07 13:30 libdes.a
-rwxr-xr-x 1 root system 8622 Oct 07 13:30 libecb.a
-rwxr-xr-x 1 root system 14990 Oct 07 13:30 libenigma.a
-rwxr-xr-x 1 root system 15787 Oct 07 13:30 libgost.a
-rwxr-xr-x 1 root system 20305 Oct 07 13:29 libloki97.a
-rwxr-xr-x 1 root system 13654 Oct 07 13:30 libncfb.a
-rwxr-xr-x 1 root system 12196 Oct 07 13:30 libnofb.a
-rwxr-xr-x 1 root system 11064 Oct 07 13:30 libofb.a
-rwxr-xr-x 1 root system 17301 Oct 07 13:30 libpanama.a
-rwxr-xr-x 1 root system 13434 Oct 07 13:29 librc2.a
-rwxr-xr-x 1 root system 18682 Oct 07 13:29
librijndael-128.a
-rwxr-xr-x 1 root system 18722 Oct 07 13:29
librijndael-192.a
-rwxr-xr-x 1 root system 18738 Oct 07 13:29
librijndael-256.a
-rwxr-xr-x 1 root system 15640 Oct 07 13:29 libsafer-sk128.a
-rwxr-xr-x 1 root system 15548 Oct 07 13:29 libsafer-sk64.a
-rwxr-xr-x 1 root system 18338 Oct 07 13:29 libsaferplus.a
-rwxr-xr-x 1 root system 28182 Oct 07 13:29 libserpent.a
-rwxr-xr-x 1 root system 8438 Oct 07 13:30 libstream.a
-rwxr-xr-x 1 root system 15805 Oct 07 13:30 libthreeway.a
-rwxr-xr-x 1 root system 20064 Oct 07 13:30 libtripledes.a
-rwxr-xr-x 1 root system 22862 Oct 07 13:29 libtwofish.a
-rwxr-xr-x 1 root system 14323 Oct 07 13:30 libwake.a
-rwxr-xr-x 1 root system 12374 Oct 07 13:29 libxtea.a
-rwxr-xr-x 1 root s
#19804 [Fbk->Opn]: PHP does not take the Libmcrypt ciphers when compiling
ID: 19804
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: *Compile Issues
Operating System: AIX 4.3.3
PHP Version: 4.2.3
New Comment:
Okay, the PATH in the php.ini. Not a problem. What exactly should I
be looking for in the filepath, like mcrypt.algorithms_dir = .
What are the example of files inside one of the directory, so I can
figure out whether am I looking for in libmcrypt or php. What are hte
filenames I should be looking for?
Thanks,
FletchSOD
Previous Comments:
[2002-10-07 13:37:17] [EMAIL PROTECTED]
Set the paths in your php.ini as described on
http://www.php.net/manual/en/ref.mcrypt.php
See "table 1".
Derick
[2002-10-07 13:11:56] [EMAIL PROTECTED]
Eh, Didn't finish with all of hte clipping. Could be that bug database
can't accept them all. By the make, I did hte best I could on make
because it is too long for the computer screen. I tried this command,
"make > log_make" but found that not all of hte data go into the
log_make and whatever is left is spitted out onto the screen.
[2002-10-07 13:05:35] [EMAIL PROTECTED]
Since Bug #19803 is bogus. I decided to compile libmcrypt and see if
the problem with libmcrypt. It worked out okay, so it is PHP that did
not take in the ciphers from libmcrypt when compiling, so I'm filling a
new bug report.
When I use some PHP function for mcrypt, like
"mcrypt_get_block_size('tripledes', 'ecb')" or
"mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256,
MCRYPT_MODE_ECB), MCRYPT_RAND)". I get all of the warning messages.
like "Warning: mcrypt module initialization failed in ..." or "Warning:
could not open encryption module ". This bug could be critical
because if someone had encrypted the data and one day upgrade PHP and
hte encryption get affected.
I use Libmcrypt-2.5.3, when compiled and installed. The file goes to
both the "/usr/local/lib" and "/usr/local/lib/libmcrypt". I'll include
the brief clip down below. The 1st clipping is for "/usr/local/lib"
and there is one directory as shown in the list.
--clip--
drwxr-xr-x 2 root system 1536 Oct 07 13:30 libmcrypt
-rwxr-xr-x 1 root system 53221 Oct 07 13:30 libmcrypt.a
-rwxr-xr-x 1 root system 738 Oct 07 13:30 libmcrypt.la
--clip--
The 2nd clipping, which is inside the directory of
"/usr/local/lib/libmcrypt".
--clip--
drwxr-xr-x 2 root system 1536 Oct 07 13:30 .
drwxr-xr-x 21 root system 1536 Oct 07 13:30 ..
-rwxr-xr-x 1 root system 750 Oct 07 13:30 arcfour.la
-rwxr-xr-x 1 root system 790 Oct 07 13:30
blowfish-compat.la
-rwxr-xr-x 1 root system 755 Oct 07 13:30 blowfish.la
-rwxr-xr-x 1 root system 755 Oct 07 13:30 cast-128.la
-rwxr-xr-x 1 root system 755 Oct 07 13:29 cast-256.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 cbc.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 cfb.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 ctr.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 des.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 ecb.la
-rwxr-xr-x 1 root system 745 Oct 07 13:30 enigma.la
-rwxr-xr-x 1 root system 735 Oct 07 13:30 gost.la
-rwxr-xr-x 1 root system 13041 Oct 07 13:30 libarcfour.a
-rwxr-xr-x 1 root system 19202 Oct 07 13:30
libblowfish-compat.a
-rwxr-xr-x 1 root system 18270 Oct 07 13:30 libblowfish.a
-rwxr-xr-x 1 root system 25990 Oct 07 13:30 libcast-128.a
-rwxr-xr-x 1 root system 25937 Oct 07 13:29 libcast-256.a
-rwxr-xr-x 1 root system 11262 Oct 07 13:30 libcbc.a
-rwxr-xr-x 1 root system 11056 Oct 07 13:30 libcfb.a
-rwxr-xr-x 1 root system 11822 Oct 07 13:30 libctr.a
-rwxr-xr-x 1 root system 17804 Oct 07 13:30 libdes.a
-rwxr-xr-x 1 root system 8622 Oct 07 13:30 libecb.a
-rwxr-xr-x 1 root system 14990 Oct 07 13:30 libenigma.a
-rwxr-xr-x 1 root system 15787 Oct 07 13:30 libgost.a
-rwxr-xr-x 1 root system 20305 Oct 07 13:29 libloki97.a
-rwxr-xr-x 1 root system 13654 Oct 07 13:30 libncfb.a
-rwxr-xr-x 1 root system 12196 Oct 07 13:30 libnofb.a
-rwxr-xr-x 1 root system 11064 Oct 07 13:30 libofb.a
-rwxr-xr-x 1 root system 17301 Oct 07 13:30 libpanama.a
-rwxr-xr-x 1 root system 13434 Oct 07 13:29 librc2.a
-rwxr-xr-x 1 root system 18682 Oct 07 13:29
librijndael-128.a
-rwxr-xr-x 1 root system 18722 Oct 07 13:29
librijndael-192.a
-rwxr-xr-x 1 root system 18738 Oct 07 13:29
librijndael-256
#19804 [Com]: PHP does not take the Libmcrypt ciphers when compiling
ID: 19804
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Compile Issues
Operating System: AIX 4.3.3
PHP Version: 4.2.3
New Comment:
I have been working on this issues for almost a week now. I have been
trying to get it to work. Yes, I did read the manual at php.net/mcrypt
and I still struggle. I will try again with the manual on
mcrypt_module_open(). What make you think I did not read this stupid
manual? Thanks for the comment and I will try it again.
Previous Comments:
[2002-10-07 14:36:30] [EMAIL PROTECTED]
/usr/local/lib/libmcrypt
see also: http://www.php.net/manual/en/function.mcrypt-module-open.php
really, read the manual. If you're certain there is still a bug,
reopen.
Derick
[2002-10-07 13:45:55] [EMAIL PROTECTED]
Okay, the PATH in the php.ini. Not a problem. What exactly should I
be looking for in the filepath, like mcrypt.algorithms_dir = .
What are the example of files inside one of the directory, so I can
figure out whether am I looking for in libmcrypt or php. What are hte
filenames I should be looking for?
Thanks,
FletchSOD
[2002-10-07 13:37:17] [EMAIL PROTECTED]
Set the paths in your php.ini as described on
http://www.php.net/manual/en/ref.mcrypt.php
See "table 1".
Derick
[2002-10-07 13:11:56] [EMAIL PROTECTED]
Eh, Didn't finish with all of hte clipping. Could be that bug database
can't accept them all. By the make, I did hte best I could on make
because it is too long for the computer screen. I tried this command,
"make > log_make" but found that not all of hte data go into the
log_make and whatever is left is spitted out onto the screen.
[2002-10-07 13:05:35] [EMAIL PROTECTED]
Since Bug #19803 is bogus. I decided to compile libmcrypt and see if
the problem with libmcrypt. It worked out okay, so it is PHP that did
not take in the ciphers from libmcrypt when compiling, so I'm filling a
new bug report.
When I use some PHP function for mcrypt, like
"mcrypt_get_block_size('tripledes', 'ecb')" or
"mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256,
MCRYPT_MODE_ECB), MCRYPT_RAND)". I get all of the warning messages.
like "Warning: mcrypt module initialization failed in ..." or "Warning:
could not open encryption module ". This bug could be critical
because if someone had encrypted the data and one day upgrade PHP and
hte encryption get affected.
I use Libmcrypt-2.5.3, when compiled and installed. The file goes to
both the "/usr/local/lib" and "/usr/local/lib/libmcrypt". I'll include
the brief clip down below. The 1st clipping is for "/usr/local/lib"
and there is one directory as shown in the list.
--clip--
drwxr-xr-x 2 root system 1536 Oct 07 13:30 libmcrypt
-rwxr-xr-x 1 root system 53221 Oct 07 13:30 libmcrypt.a
-rwxr-xr-x 1 root system 738 Oct 07 13:30 libmcrypt.la
--clip--
The 2nd clipping, which is inside the directory of
"/usr/local/lib/libmcrypt".
--clip--
drwxr-xr-x 2 root system 1536 Oct 07 13:30 .
drwxr-xr-x 21 root system 1536 Oct 07 13:30 ..
-rwxr-xr-x 1 root system 750 Oct 07 13:30 arcfour.la
-rwxr-xr-x 1 root system 790 Oct 07 13:30
blowfish-compat.la
-rwxr-xr-x 1 root system 755 Oct 07 13:30 blowfish.la
-rwxr-xr-x 1 root system 755 Oct 07 13:30 cast-128.la
-rwxr-xr-x 1 root system 755 Oct 07 13:29 cast-256.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 cbc.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 cfb.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 ctr.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 des.la
-rwxr-xr-x 1 root system 730 Oct 07 13:30 ecb.la
-rwxr-xr-x 1 root system 745 Oct 07 13:30 enigma.la
-rwxr-xr-x 1 root system 735 Oct 07 13:30 gost.la
-rwxr-xr-x 1 root system 13041 Oct 07 13:30 libarcfour.a
-rwxr-xr-x 1 root system 19202 Oct 07 13:30
libblowfish-compat.a
-rwxr-xr-x 1 root system 18270 Oct 07 13:30 libblowfish.a
-rwxr-xr-x 1 root system 25990 Oct 07 13:30 libcast-128.a
-rwxr-xr-x 1 root system 25937 Oct 07 13:29 libcast-256.a
-rwxr-xr-x 1 root system 11262 Oct 07 13:30 libcbc.a
-rwxr-xr-x 1 root system 11056 Oct 07 13:30 libcfb.a
-rwxr-xr-x 1 root system 11822 Oct 07 13:30 libctr.a
-rwxr-xr-x 1 root system 17804 Oct 07 13:30 libdes.a
-rwxr-xr-x 1 root system 8622 Oct 07 13:30 libecb.a
-rwxr-xr-x 1 root
#19804 [Bgs->Opn]: PHP does not take the Libmcrypt ciphers when compiling
ID: 19804 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: *Compile Issues Operating System: AIX 4.3.3 PHP Version: 4.2.3 New Comment: Re-opening the bug I tried many different ways as the PHP Manual stated and I still get the error messasges, 'Warning: mcrypt module initialization failed in '. When PHP manual stated about "mcrypt_module_open (MCRYPT_DES, '', MCRYPT_MODE_ECB, '')" I still get the error, so I tried the other examples. "mcrypt_module_open (MCRYPT_DES, '', MCRYPT_MODE_ECB, '/usr/lib/mcrypt-modes')" I still get the error message. Problme is I have no such directory as "mcrypt-modes" on the server. I also assumed that the 2nd parament refer to "mcrypt-algorithms" since the PHP Manual didn't anything about the 2nd parameter. I checked the PHP Info on the server, the 1st clipping showed the actual result before I add the two lines of code to php.ini. The 2nd clipping showed the actual result of hte 2nd line of codes. (mcrypt directory). --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersnone Supported modesnone DirectiveLocal ValueMaster Value mcrypt.algorithms_dirno valueno value mcrypt.modes_dirno valueno value --clip-- --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersnone Supported modesnone DirectiveLocal ValueMaster Value mcrypt.algorithms_dir/usr/local/lib/libmcrypt/usr/local/lib/libmcrypt mcrypt.modes_dir/usr/local/lib/libmcrypt/usr/local/lib/libmcrypt --clip-- This still does not solve my problem. So, I did hte google search and came upon someone's PHP Info website and found this if their encryption function work. --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersarcfour blowfish-compat blowfish cast-128 cast-256 des enigma gost loki97 panama rc2 rijndael-128 rijndael-192 rijndael-256 safer-sk128 safer-sk64 saferplus serpent threeway tripledes twofish wake xtea Supported modescbc cfb ecb ncfb nofb ofb stream DirectiveLocal ValueMaster Value mcrypt.algorithms_dirno valueno value mcrypt.modes_dirno valueno value --clip-- Since mine still have no supported ciphers, so it explain why the php-mycrypt function don't work at all. I was trying to say that I have been working on it for almost a week and I can tell that PHP ./configure didn't find it and when compiling PHP, PHP does not take in hte libmcrypt algorithm. It only take in libmcrypt but not the algorithm or modes. So, I believe I stand correct on this php bug. Previous Comments: [2002-10-07 14:49:29] [EMAIL PROTECTED] I have been working on this issues for almost a week now. I have been trying to get it to work. Yes, I did read the manual at php.net/mcrypt and I still struggle. I will try again with the manual on mcrypt_module_open(). What make you think I did not read this stupid manual? Thanks for the comment and I will try it again. [2002-10-07 14:36:30] [EMAIL PROTECTED] /usr/local/lib/libmcrypt see also: http://www.php.net/manual/en/function.mcrypt-module-open.php really, read the manual. If you're certain there is still a bug, reopen. Derick [2002-10-07 13:45:55] [EMAIL PROTECTED] Okay, the PATH in the php.ini. Not a problem. What exactly should I be looking for in the filepath, like mcrypt.algorithms_dir = . What are the example of files inside one of the directory, so I can figure out whether am I looking for in libmcrypt or php. What are hte filenames I should be looking for? Thanks, FletchSOD [2002-10-07 13:37:17] [EMAIL PROTECTED] Set the paths in your php.ini as described on http://www.php.net/manual/en/ref.mcrypt.php See "table 1". Derick [2002-10-07 13:11:56] [EMAIL PROTECTED] Eh, Didn't finish with all of hte clipping. Could be that bug database can't accept them all. By the make, I did hte best I could on make because it is too long for the computer screen. I tried this command, "make > log_make" but found that not all of hte data go into the log_make and whatever is left is spitted out onto the screen. 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/19804 -- Edit this bug report at http://bugs.php.net/?id=19804&edit=1
#19804 [Com]: PHP does not take the Libmcrypt ciphers when compiling
ID: 19804 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Compile Issues Operating System: AIX 4.3.3 PHP Version: 4.2.3 New Comment: I have this code in php.ini and it does nothing! --clip-- mcrypt.algorithms_dir = /usr/local/lib/libmcrypt mcrypt.modes_dir = /usr/local/lib/libmcrypt --clip-- Previous Comments: [2002-10-08 09:25:45] [EMAIL PROTECTED] Again, this is NOT a bug. Just set the correct paths in php.ini mcrypt.modules_dir AND mcrypt.algorithms_dir are where your ciphers and modules are. As you already pasted in your first bugreport, this is "/usr/local/lib/libmcrypt". You see those files with ls -l ? That are your ciphers and modes. Derick [2002-10-08 09:21:58] [EMAIL PROTECTED] Re-opening the bug I tried many different ways as the PHP Manual stated and I still get the error messasges, 'Warning: mcrypt module initialization failed in '. When PHP manual stated about "mcrypt_module_open (MCRYPT_DES, '', MCRYPT_MODE_ECB, '')" I still get the error, so I tried the other examples. "mcrypt_module_open (MCRYPT_DES, '', MCRYPT_MODE_ECB, '/usr/lib/mcrypt-modes')" I still get the error message. Problme is I have no such directory as "mcrypt-modes" on the server. I also assumed that the 2nd parament refer to "mcrypt-algorithms" since the PHP Manual didn't anything about the 2nd parameter. I checked the PHP Info on the server, the 1st clipping showed the actual result before I add the two lines of code to php.ini. The 2nd clipping showed the actual result of hte 2nd line of codes. (mcrypt directory). --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersnone Supported modesnone DirectiveLocal ValueMaster Value mcrypt.algorithms_dirno valueno value mcrypt.modes_dirno valueno value --clip-- --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersnone Supported modesnone DirectiveLocal ValueMaster Value mcrypt.algorithms_dir/usr/local/lib/libmcrypt/usr/local/lib/libmcrypt mcrypt.modes_dir/usr/local/lib/libmcrypt/usr/local/lib/libmcrypt --clip-- This still does not solve my problem. So, I did hte google search and came upon someone's PHP Info website and found this if their encryption function work. --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersarcfour blowfish-compat blowfish cast-128 cast-256 des enigma gost loki97 panama rc2 rijndael-128 rijndael-192 rijndael-256 safer-sk128 safer-sk64 saferplus serpent threeway tripledes twofish wake xtea Supported modescbc cfb ecb ncfb nofb ofb stream DirectiveLocal ValueMaster Value mcrypt.algorithms_dirno valueno value mcrypt.modes_dirno valueno value --clip-- Since mine still have no supported ciphers, so it explain why the php-mycrypt function don't work at all. I was trying to say that I have been working on it for almost a week and I can tell that PHP ./configure didn't find it and when compiling PHP, PHP does not take in hte libmcrypt algorithm. It only take in libmcrypt but not the algorithm or modes. So, I believe I stand correct on this php bug. [2002-10-07 14:49:29] [EMAIL PROTECTED] I have been working on this issues for almost a week now. I have been trying to get it to work. Yes, I did read the manual at php.net/mcrypt and I still struggle. I will try again with the manual on mcrypt_module_open(). What make you think I did not read this stupid manual? Thanks for the comment and I will try it again. [2002-10-07 14:36:30] [EMAIL PROTECTED] /usr/local/lib/libmcrypt see also: http://www.php.net/manual/en/function.mcrypt-module-open.php really, read the manual. If you're certain there is still a bug, reopen. Derick [2002-10-07 13:45:55] [EMAIL PROTECTED] Okay, the PATH in the php.ini. Not a problem. What exactly should I be looking for in the filepath, like mcrypt.algorithms_dir = . What are the example of files inside one of the directory, so I can figure out whether am I looking for in libmcrypt or php. What are hte filenames I should be looking for? Thanks, FletchSOD 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/19804 -- Edit this bug report at http://bugs.php.net/?id=19804&edit=1
#19804 [Bgs]: PHP does not take the Libmcrypt ciphers when compiling
ID: 19804 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Compile Issues Operating System: AIX 4.3.3 PHP Version: 4.2.3 New Comment: Since the php.ini does nothing, I did find something interesting. When I changed the file path in php.ini to the open-source libmcrypt-2.5.3 that had been untarred but not configured or compiled. Here's what I did ... --clip-- mcrypt.algorithms_dir = /usr/local/src3/libmcrypt-2.5.3/modules/algorithms mcrypt.modes_dir = /usr/local/src3/libmcrypt-2.5.3/modules/modes --clip-- This fix my problem with the mcrypt stuffs. So, I looked into the files and saw bunch of files that end with *.c and *.h. So, why does it work with the open source files but not with the *.la or *.a files in /usr/local/lib/libmcrypt??? Do you have an explanation or an answer to this??? I would appreciate it. I want to know is is it safe for me to use the open source files?? Thanks! Previous Comments: [2002-10-08 09:27:59] [EMAIL PROTECTED] I have this code in php.ini and it does nothing! --clip-- mcrypt.algorithms_dir = /usr/local/lib/libmcrypt mcrypt.modes_dir = /usr/local/lib/libmcrypt --clip-- [2002-10-08 09:25:45] [EMAIL PROTECTED] Again, this is NOT a bug. Just set the correct paths in php.ini mcrypt.modules_dir AND mcrypt.algorithms_dir are where your ciphers and modules are. As you already pasted in your first bugreport, this is "/usr/local/lib/libmcrypt". You see those files with ls -l ? That are your ciphers and modes. Derick [2002-10-08 09:21:58] [EMAIL PROTECTED] Re-opening the bug I tried many different ways as the PHP Manual stated and I still get the error messasges, 'Warning: mcrypt module initialization failed in '. When PHP manual stated about "mcrypt_module_open (MCRYPT_DES, '', MCRYPT_MODE_ECB, '')" I still get the error, so I tried the other examples. "mcrypt_module_open (MCRYPT_DES, '', MCRYPT_MODE_ECB, '/usr/lib/mcrypt-modes')" I still get the error message. Problme is I have no such directory as "mcrypt-modes" on the server. I also assumed that the 2nd parament refer to "mcrypt-algorithms" since the PHP Manual didn't anything about the 2nd parameter. I checked the PHP Info on the server, the 1st clipping showed the actual result before I add the two lines of code to php.ini. The 2nd clipping showed the actual result of hte 2nd line of codes. (mcrypt directory). --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersnone Supported modesnone DirectiveLocal ValueMaster Value mcrypt.algorithms_dirno valueno value mcrypt.modes_dirno valueno value --clip-- --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersnone Supported modesnone DirectiveLocal ValueMaster Value mcrypt.algorithms_dir/usr/local/lib/libmcrypt/usr/local/lib/libmcrypt mcrypt.modes_dir/usr/local/lib/libmcrypt/usr/local/lib/libmcrypt --clip-- This still does not solve my problem. So, I did hte google search and came upon someone's PHP Info website and found this if their encryption function work. --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersarcfour blowfish-compat blowfish cast-128 cast-256 des enigma gost loki97 panama rc2 rijndael-128 rijndael-192 rijndael-256 safer-sk128 safer-sk64 saferplus serpent threeway tripledes twofish wake xtea Supported modescbc cfb ecb ncfb nofb ofb stream DirectiveLocal ValueMaster Value mcrypt.algorithms_dirno valueno value mcrypt.modes_dirno valueno value --clip-- Since mine still have no supported ciphers, so it explain why the php-mycrypt function don't work at all. I was trying to say that I have been working on it for almost a week and I can tell that PHP ./configure didn't find it and when compiling PHP, PHP does not take in hte libmcrypt algorithm. It only take in libmcrypt but not the algorithm or modes. So, I believe I stand correct on this php bug. [2002-10-07 14:49:29] [EMAIL PROTECTED] I have been working on this issues for almost a week now. I have been trying to get it to work. Yes, I did read the manual at php.net/mcrypt and I still struggle. I will try again with the manual on mcrypt_module_open(). What make you think I did not read this stupid manual? Thanks for the comment and I will try it again. [2002-10-07 14:36:30] [EMAIL PROTECTED] /usr/local/lib/libmcrypt see also: http://www.php.net/manual/en/function.mcrypt-module-open.php really, read the manual. If you're certain there is still a b
#19804 [Bgs->Opn]: PHP does not take the Libmcrypt ciphers when compiling
ID: 19804 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: *Compile Issues Operating System: AIX 4.3.3 PHP Version: 4.2.3 New Comment: Re-opening bug cause I'm waiting for a response to the last comment I posted. Then you can close the bug after that. Previous Comments: [2002-10-08 12:56:35] [EMAIL PROTECTED] Since the php.ini does nothing, I did find something interesting. When I changed the file path in php.ini to the open-source libmcrypt-2.5.3 that had been untarred but not configured or compiled. Here's what I did ... --clip-- mcrypt.algorithms_dir = /usr/local/src3/libmcrypt-2.5.3/modules/algorithms mcrypt.modes_dir = /usr/local/src3/libmcrypt-2.5.3/modules/modes --clip-- This fix my problem with the mcrypt stuffs. So, I looked into the files and saw bunch of files that end with *.c and *.h. So, why does it work with the open source files but not with the *.la or *.a files in /usr/local/lib/libmcrypt??? Do you have an explanation or an answer to this??? I would appreciate it. I want to know is is it safe for me to use the open source files?? Thanks! [2002-10-08 09:27:59] [EMAIL PROTECTED] I have this code in php.ini and it does nothing! --clip-- mcrypt.algorithms_dir = /usr/local/lib/libmcrypt mcrypt.modes_dir = /usr/local/lib/libmcrypt --clip-- [2002-10-08 09:25:45] [EMAIL PROTECTED] Again, this is NOT a bug. Just set the correct paths in php.ini mcrypt.modules_dir AND mcrypt.algorithms_dir are where your ciphers and modules are. As you already pasted in your first bugreport, this is "/usr/local/lib/libmcrypt". You see those files with ls -l ? That are your ciphers and modes. Derick [2002-10-08 09:21:58] [EMAIL PROTECTED] Re-opening the bug I tried many different ways as the PHP Manual stated and I still get the error messasges, 'Warning: mcrypt module initialization failed in '. When PHP manual stated about "mcrypt_module_open (MCRYPT_DES, '', MCRYPT_MODE_ECB, '')" I still get the error, so I tried the other examples. "mcrypt_module_open (MCRYPT_DES, '', MCRYPT_MODE_ECB, '/usr/lib/mcrypt-modes')" I still get the error message. Problme is I have no such directory as "mcrypt-modes" on the server. I also assumed that the 2nd parament refer to "mcrypt-algorithms" since the PHP Manual didn't anything about the 2nd parameter. I checked the PHP Info on the server, the 1st clipping showed the actual result before I add the two lines of code to php.ini. The 2nd clipping showed the actual result of hte 2nd line of codes. (mcrypt directory). --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersnone Supported modesnone DirectiveLocal ValueMaster Value mcrypt.algorithms_dirno valueno value mcrypt.modes_dirno valueno value --clip-- --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersnone Supported modesnone DirectiveLocal ValueMaster Value mcrypt.algorithms_dir/usr/local/lib/libmcrypt/usr/local/lib/libmcrypt mcrypt.modes_dir/usr/local/lib/libmcrypt/usr/local/lib/libmcrypt --clip-- This still does not solve my problem. So, I did hte google search and came upon someone's PHP Info website and found this if their encryption function work. --clip-- mcrypt mcrypt supportenabled version>= 2.4.x Supported ciphersarcfour blowfish-compat blowfish cast-128 cast-256 des enigma gost loki97 panama rc2 rijndael-128 rijndael-192 rijndael-256 safer-sk128 safer-sk64 saferplus serpent threeway tripledes twofish wake xtea Supported modescbc cfb ecb ncfb nofb ofb stream DirectiveLocal ValueMaster Value mcrypt.algorithms_dirno valueno value mcrypt.modes_dirno valueno value --clip-- Since mine still have no supported ciphers, so it explain why the php-mycrypt function don't work at all. I was trying to say that I have been working on it for almost a week and I can tell that PHP ./configure didn't find it and when compiling PHP, PHP does not take in hte libmcrypt algorithm. It only take in libmcrypt but not the algorithm or modes. So, I believe I stand correct on this php bug. [2002-10-07 14:49:29] [EMAIL PROTECTED] I have been working on this issues for almost a week now. I have been trying to get it to work. Yes, I did read the manual at php.net/mcrypt and I still struggle. I will try again with the manual on mcrypt_module_open(). What make you think I did not read this stupid manual? Thanks for the comment and I will try it again.
#19804 [Bgs]: PHP does not take the Libmcrypt ciphers when compiling
ID: 19804 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: mcrypt related Operating System: AIX 4.3.3 PHP Version: 4.2.3 New Comment: Thanks! Previous Comments: [2002-10-12 09:54:27] [EMAIL PROTECTED] yes, it's perfectly safe. [2002-10-09 11:22:54] [EMAIL PROTECTED] Re-opening bug cause I'm waiting for a response to the last comment I posted. Then you can close the bug after that. [2002-10-08 12:56:35] [EMAIL PROTECTED] Since the php.ini does nothing, I did find something interesting. When I changed the file path in php.ini to the open-source libmcrypt-2.5.3 that had been untarred but not configured or compiled. Here's what I did ... --clip-- mcrypt.algorithms_dir = /usr/local/src3/libmcrypt-2.5.3/modules/algorithms mcrypt.modes_dir = /usr/local/src3/libmcrypt-2.5.3/modules/modes --clip-- This fix my problem with the mcrypt stuffs. So, I looked into the files and saw bunch of files that end with *.c and *.h. So, why does it work with the open source files but not with the *.la or *.a files in /usr/local/lib/libmcrypt??? Do you have an explanation or an answer to this??? I would appreciate it. I want to know is is it safe for me to use the open source files?? Thanks! [2002-10-08 09:27:59] [EMAIL PROTECTED] I have this code in php.ini and it does nothing! --clip-- mcrypt.algorithms_dir = /usr/local/lib/libmcrypt mcrypt.modes_dir = /usr/local/lib/libmcrypt --clip-- [2002-10-08 09:25:45] [EMAIL PROTECTED] Again, this is NOT a bug. Just set the correct paths in php.ini mcrypt.modules_dir AND mcrypt.algorithms_dir are where your ciphers and modules are. As you already pasted in your first bugreport, this is "/usr/local/lib/libmcrypt". You see those files with ls -l ? That are your ciphers and modes. Derick 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/19804 -- Edit this bug report at http://bugs.php.net/?id=19804&edit=1
#19741 [NoF->Opn]: Path no longer works in unlink, pdf_open_file
ID: 19741
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: No Feedback
+Status: Open
Bug Type: Apache2 related
Operating System: linux 2.4.18
-PHP Version: 4.2.3
+PHP Version: 4.2.3 and CVS Snap
New Comment:
Please check
Previous Comments:
[2002-10-19 01:00:05] [EMAIL PROTECTED]
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2002-10-07 10:44:49] [EMAIL PROTECTED]
CVS Snapshot had no impact.
[2002-10-03 19:35:45] [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-10-03 18:39:34] [EMAIL PROTECTED]
on further examination it appears only
pdf_open_file($pdf, "somefile.pdf");
does not work and must be substituted with
pdf_open_file($pdf, "$documentroot/somefile.pdf");
(or the smart example)
i took the liberty of checking with pdf.c and it doesnt appear to be
any different.
[2002-10-03 18:26:38] [EMAIL PROTECTED]
A smarter variant of the workaround is to use
file_exists(realpath('somefile.pdf'));
which works quite fine on Apache 2.0.40
Philipp
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/19741
--
Edit this bug report at http://bugs.php.net/?id=19741&edit=1
Bug #15827: posts with enctype=multipart/form-data do not register post vars.
From: [EMAIL PROTECTED] Operating system: Redhat 7.0 PHP version: 4.1.2 PHP Bug Type: Variables related Bug description: posts with enctype=multipart/form-data do not register post vars. Forms with an enctype of 'multitype/form-data' do not register the POST variables. Here's how to reproduce: - Short Script Follows - - End Script - Run the script above. It is simple enough - it has a form that submits to itself, and then displays the HTTP_POST_VARS variable. When I remove the enctype='multipart/form-data' attribute from the form tag, the script works fine (i.e. the variable 'foo' appears). The enctype directive appears to surpress the variables. -- Edit bug report at http://bugs.php.net/?id=15827&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15827&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15827&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15827&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15827&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15827&r=support Expected behavior: http://bugs.php.net/fix.php?id=15827&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15827&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15827&r=submittedtwice
Bug #15827 Updated: posts with enctype=multipart/form-data do not register post vars.
ID: 15827 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Variables related Operating System: Redhat 7.0 PHP Version: 4.1.2 New Comment: My mistake - after my upgrade (due to the security risk) I didn't re-set the ini file to allow file uploads again. I guess this directive is there to prevent unauthorised multipart submissions. For others experiencing this problem, check your ini file and ensure the following line exists: file_uploads = On Previous Comments: [2002-03-02 00:54:03] [EMAIL PROTECTED] Forms with an enctype of 'multitype/form-data' do not register the POST variables. Here's how to reproduce: - Short Script Follows - - End Script - Run the script above. It is simple enough - it has a form that submits to itself, and then displays the HTTP_POST_VARS variable. When I remove the enctype='multipart/form-data' attribute from the form tag, the script works fine (i.e. the variable 'foo' appears). The enctype directive appears to surpress the variables. -- Edit this bug report at http://bugs.php.net/?id=15827&edit=1
#20352 [NEW]: PHP-GTK apps crash with corrupt argc/argv error
From: [EMAIL PROTECTED] Operating system: RedHat Linux 7.3 PHP version: 4.3.0-pre2 PHP Bug Type: Reproducible crash Bug description: PHP-GTK apps crash with corrupt argc/argv error Trying to run any program that uses the PHP-GTK extension dies immediately with an error message similar to this: PHP Fatal error: php-gtk: argc/argv are corrupted in /root/php-gtk-cvs/test/hello.php on line 7 -- Edit bug report at http://bugs.php.net/?id=20352&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20352&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20352&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20352&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20352&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20352&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20352&r=support Expected behavior: http://bugs.php.net/fix.php?id=20352&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20352&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20352&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20352&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20352&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20352&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20352&r=isapi
[PHP-BUG] Bug #60536 [NEW]: Traits Segfault
From:
Operating system: ubuntu 11.11
PHP version: 5.4SVN-2011-12-15 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Traits Segfault
Description:
Following code crashes.
Test script:
---
x; }
}
class Z extends Y {
function z() { return ++$this->x; }
}
$a = new Z();
$a->x();
--
Edit bug report at https://bugs.php.net/bug.php?id=60536&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60536&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60536&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60536&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60536&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60536&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60536&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60536&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60536&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60536&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60536&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60536&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60536&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60536&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60536&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60536&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60536&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60536&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60536&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60536&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60536&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60536&r=mysqlcfg
Bug #53336 [Com]: queries on create_function return only one result
Edit report at http://bugs.php.net/bug.php?id=53336&edit=1
ID: 53336
Comment by: scott...@php.net
Reported by:cbruner at quadro dot net
Summary:queries on create_function return only one result
Status: Open
Type: Bug
Package:SQLite related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Can you give me a full test script, I'll need data too to track this
down.
Previous Comments:
[2010-11-18 06:19:33] cbruner at quadro dot net
Description:
Using sqlite3, create a function to do a comparison
(SQLite3::createFunction)
Then query a table using the function.
Only one result is returned when multiple results would be expected.
Test script:
---
// callback function for use by the sqlite3 class which returns the
distance between 2 points on the earth
function SqLDistance($Latitude,$Longitude,$Lat,$Long)
{
$result = 1.0; // flag to be off the earth!
if (isset($Latitude) && isset($Longitude))
{
$lat1rad = $Latitude * 0.01745327;// degrees * pi over
180
$lat2rad = $Lat * 0.01745327;// degrees * pi over 180
$long1rad = $Longitude * 0.01745327;// degrees * pi
over 180
$long2rad = $Long * 0.01745327;// degrees * pi over
180
// apply the spherical law of cosines to our
$earthRadius = 6378.1; //km
$result = $earthRadius *
acos(sin($lat1rad) * sin($lat2rad) +
cos($lat1rad) * cos($lat2rad) * cos($long2rad - $long1rad));
}
return $result;
}
class MyDB extends SQLite3
{
function __construct()
{
$this->open('zipcode.db');
$this->createFunction('Distance','SqlDistance',4);
}
function Borked($lat,$long,$count)
{
$result = $this->query("Select *,Distance(Lat,Long,$lat,$long)
as Distance from agents order by Distance Limit 0,$count");
return $result->fetchArray();
}
}
Expected result:
An array of results with a length greater then 1.
Actual result:
--
An array of result.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53336&edit=1
#2873 [Com]: explode not working
ID: 2873 Comment by: scott at yahoo dot com Reported By: mwright29 at hotmail dot com Status: Closed Bug Type: Misbehaving function Operating System: RedHat Linux 6.0 PHP Version: 3.0.12 New Comment: what the f does this mean - why doesn't it work??? Previous Comments: [1999-11-30 15:47:28] mwright29 at hotmail dot com Description: When this script runs, it only returns the word "Array" when it echoes $pieces. This is the exact code from the explode function documentation on the php.net website. I tried using explode to break up a search string and when it didn't work, I tried this. Script: Configure line: ./configure --with-mysql --with-apache=../apache_1.3.x --enable-track-vars --disable-gd -- Edit this bug report at http://bugs.php.net/?id=2873&edit=1
#26637 [NEW]: pickle/unpickle
From: scott at scottdial dot com
Operating system: N/A
PHP version: 4.3.4
PHP Bug Type: Feature/Change Request
Bug description: pickle/unpickle
Description:
For the unknowing, pickle is the python derived term for object
serialization. Currenlty, session management has such functionality, but
this functionality is not exposed to the programmer to be done outside of
using a session. I propose there be a pickle/unpickle function that uses
the same serialization method that the session managment uses.
Reproduce code:
---
$foo = array(1, 2, 3)
$string = pickle($foo);
echo $string;
$bar = unpickle($foo);
echo $bar;
print_r($bar);
Expected result:
a:3:{i:0;i:1;i:1;i:2;i:2;i:3;}
Array
Array ( [0] => 1 [1] => 2 [2] => 3 )
--
Edit bug report at http://bugs.php.net/?id=26637&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26637&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26637&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26637&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26637&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26637&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26637&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26637&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26637&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26637&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26637&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26637&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26637&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26637&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26637&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26637&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26637&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26637&r=float
#26637 [Opn]: pickle/unpickle function
ID: 26637
User updated by: scott at scottdial dot com
-Summary: pickle/unpickle
Reported By: scott at scottdial dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: N/A
-PHP Version: 4.3.4
+PHP Version: Any
New Comment:
I typo'd.. should be: $bar = unpickle($string);
Previous Comments:
[2003-12-16 01:20:34] scott at scottdial dot com
Description:
For the unknowing, pickle is the python derived term for object
serialization. Currenlty, session management has such functionality,
but this functionality is not exposed to the programmer to be done
outside of using a session. I propose there be a pickle/unpickle
function that uses the same serialization method that the session
managment uses.
Reproduce code:
---
$foo = array(1, 2, 3)
$string = pickle($foo);
echo $string;
$bar = unpickle($foo);
echo $bar;
print_r($bar);
Expected result:
a:3:{i:0;i:1;i:1;i:2;i:2;i:3;}
Array
Array ( [0] => 1 [1] => 2 [2] => 3 )
--
Edit this bug report at http://bugs.php.net/?id=26637&edit=1
#26637 [Opn->Bgs]: pickle/unpickle function
ID: 26637
User updated by: scott at scottdial dot com
Reported By: scott at scottdial dot com
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: N/A
PHP Version: Any
New Comment:
Doh, I needed to RTFM harder :-p
Previous Comments:
[2003-12-16 01:23:08] scott at scottdial dot com
I typo'd.. should be: $bar = unpickle($string);
[2003-12-16 01:20:34] scott at scottdial dot com
Description:
For the unknowing, pickle is the python derived term for object
serialization. Currenlty, session management has such functionality,
but this functionality is not exposed to the programmer to be done
outside of using a session. I propose there be a pickle/unpickle
function that uses the same serialization method that the session
managment uses.
Reproduce code:
---
$foo = array(1, 2, 3)
$string = pickle($foo);
echo $string;
$bar = unpickle($foo);
echo $bar;
print_r($bar);
Expected result:
a:3:{i:0;i:1;i:1;i:2;i:2;i:3;}
Array
Array ( [0] => 1 [1] => 2 [2] => 3 )
--
Edit this bug report at http://bugs.php.net/?id=26637&edit=1
#19528 [Fbk->Opn]: odbc_fetch_row() doesn't returned true if there is one row only
ID: 19528 User updated by: scott at abcoa dot com Reported By: scott at abcoa dot com -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: AIX (UNIX) PHP Version: 4.2.2 New Comment: I'm not sure if I would want to try it. Seem that I would need to use the driver manager and the driver. It reminded me of OpenLink that became too much and I threw it out in the past. I like the idea of having PHP's ODBC to work with DB2 by using the '--with-ibm-db2' prefix because it give me fewer softwares to work with. I mean DB2 is not only database I had to deal with, but of some different database softwares as well as some for Windows. I mean no offense. I didn't really have that problem way back in the past. Maybe the problem will fix itself in the near future. Who know! Previous Comments: [2003-03-04 10:36:43] [EMAIL PROTECTED] Any chance you can try building with unixODBC as the driver, and connecting via that? It seems to be the recommended means from IBM for connecting to DB2 systems. [2003-01-27 14:37:58] ranson at ea dot com I am having trouble with this as well, and have put in the bug workaround. It seeks to work but I have noticed that it skips my first row and duplicates my last row. [2002-10-02 12:06:17] [EMAIL PROTECTED] Updating summary ---- [2002-09-27 12:16:06] scott at abcoa dot com I looked at few IBM books and IBM website and could find no such documentation about sql.log. I also tried typing in the command "find . -name '*log' -print" and got a few IBM DB2 logs but they aren't related to sql.log. Right now, I'm out of luck. Someone else will know more about it better than I do. [2002-09-26 15:53:58] [EMAIL PROTECTED] I'm not intimately familiar with the DB2 system, but there has to be a way to turn on ODBC logging. This is a fairly standard debugging method. Can you please check your documentation for it... it would make tracking this bug down infinately easier. 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/19528 -- Edit this bug report at http://bugs.php.net/?id=19528&edit=1
#19528 [NoF->Opn]: odbc_fetch_row() doesn't returned true if there is one row only
ID: 19528 User updated by: scott at abcoa dot com Reported By: scott at abcoa dot com -Status: No Feedback +Status: Open Bug Type: ODBC related Operating System: AIX (UNIX) PHP Version: 4.2.2 New Comment: Lost track of time, so sorry about that. What we're going to need is more people who are experiencing this problem. In answer to your question, I'm not sure if it is a driver issue or not because I have not upgraded the AIX nor have I upgraded the DB2 driver nor have I upgraded the DB2 software. I'm waiting for version 9.1 to come out and buy it, whew, it's a pretty expensive software. The only thing changes from that time of version 4.0.6 to 4.2.3 was the inclusion of the '--with-mcrypt' option to the configure command but this doesn't seem to be the cause of the problem because they are not related. We had one other user in this bug report who reported this problem. So, go ahead and put this bug in inactive status or something until someone can step forward with the problem. I don't have a solution to this problem. Thanks, Scott P.S. I have noticed that PHP have a built-in programming script that allow PHP to create a formatting and datas into a PDF then generate a PDF file. Maybe PHP developers can do that similar thing by coming up with some ideas to create a PHP Database or a PHP CVS file that can act as a database. The logic shouldn't be too difficult to come up with and it could help to depend less on the 3rd party database and instead more on the PHP. It is just an idea but not a bad idea... I would love to hear about it one day. Previous Comments: [2003-03-10 20:41:10] [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-03-05 16:38:52] [EMAIL PROTECTED] To answer some of the comments in here, yes unixODBC is a Driver Manager much in the same vain as iODBC. The reason for asking is that while PHP does support DB2, I (as the developer) have no direct access to a DB2 machine to test if anything at all works on it. The unixODBC DM is actually the suggested and prefered method by IBM for connecting to a DB2 installation, not directly through library linking like you do in a --with-ibm-db2 option. The point of using a Driver Manager though is to remove the headaches of using a different database on a per machine basis. But again absolutely nothing has changed between odbc_fetch_row functionality from 4.0.6 and 4.2.3, hence I'm wondering if it's a driver issue. ---- [2003-03-05 14:37:53] scott at abcoa dot com I'm not sure if I would want to try it. Seem that I would need to use the driver manager and the driver. It reminded me of OpenLink that became too much and I threw it out in the past. I like the idea of having PHP's ODBC to work with DB2 by using the '--with-ibm-db2' prefix because it give me fewer softwares to work with. I mean DB2 is not only database I had to deal with, but of some different database softwares as well as some for Windows. I mean no offense. I didn't really have that problem way back in the past. Maybe the problem will fix itself in the near future. Who know! [2003-03-04 10:36:43] [EMAIL PROTECTED] Any chance you can try building with unixODBC as the driver, and connecting via that? It seems to be the recommended means from IBM for connecting to DB2 systems. [2003-01-27 14:37:58] ranson at ea dot com I am having trouble with this as well, and have put in the bug workaround. It seeks to work but I have noticed that it skips my first row and duplicates my last row. 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/19528 -- Edit this bug report at http://bugs.php.net/?id=19528&edit=1
#32746 [NEW]: PHP command line option doesn't have verbose/debug output.
From: scott at abcoa dot com Operating system: AIX or any Unix(s)/Linux(s) PHP version: 4.3.10 PHP Bug Type: Unknown/Other Function Bug description: PHP command line option doesn't have verbose/debug output. Description: This is a request for enhancement for the command line option. I couldn't find an earlier bug report via bug search, so forgive me if this is a duplicate or something. As I looked up at http://us2.php.net/features.commandline and it doesn't have the option for debugging or verbose output via the shell environment. With most shell environment for bash, ksh, etc., I can do the -x or maybe -d option to see the output via the O/S and I/O so I can see what is goign on behind hte scene when I have problem with why am I not getting response. A line by line trace is useful also... Yes, I can do with exec() or system() but I had cURL compiled with PHP and other stuffs, so it get more complicated than it look. Thanks... Reproduce code: --- #!/usr/local/bin/php Expected result: Something like this or close enough, whatever make it possible for us to read the O/S output or I/O output... --snip-- -=[/usr/local/bin]==>sh -x ./inquiry_pull_test.sh + 0< l + = ./inquiry_pull_test.sh[3]: =: not found. + Testing Inquiry Send... * About to connect() to ec.equifax.com:443 * Connected to ec.equifax.com ((nil)) port 443 * SSL connection using RC4-MD5 * Server certificate: *subject: /C=US/ST=Georgia/L=Alpharetta/O=Equifax Inc/CN=ec.equifax.com *start date: 2004-07-01 02:57:28 GMT *expire date: 2005-07-01 02:57:28 GMT *common name: ec.equifax.com (matched) *issuer: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Server CA/[EMAIL PROTECTED] > POST /servlet/stspost HTTP/1.1 Authorization: Basic blah blah OpenSSL/0.9.6g Host: ec.equifax.com Pragma: no-cache Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Content-Length: 396 Content-Type: application/x-www-form-urlencoded site_id=0&service_name=test&efx_request=DIAL blah blah --snip-- -- Edit bug report at http://bugs.php.net/?id=32746&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32746&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32746&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32746&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32746&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32746&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32746&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32746&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32746&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32746&r=support Expected behavior: http://bugs.php.net/fix.php?id=32746&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32746&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32746&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32746&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32746&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32746&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32746&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32746&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32746&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32746&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32746&r=mysqlcfg
#33268 [Com]: iconv_strlen works only with a parameter of < 3 in length
ID: 33268 Comment by: scott at slerman dot net Reported By: markus dot lervik at necora dot fi Status: Open Bug Type: ICONV related Operating System: SuSE Linux 9.2 PHP Version: 5.0.3 New Comment: I confirmed this problem on Fedora using PHP 5.0.4 and Apache 2.0.54. On Windows/PHP 5.0.4 I get Notice: iconv_strlen(): Unknown error (9) in C:\PHP\test\iconv.php on line 1 On Fedora/PHP 5.0.4 CLI I get Notice: iconv_strlen(): Unknown error (25) in /home/scott/test files/iconv.php on line 1 Previous Comments: [2005-06-08 00:28:48] markus dot lervik at necora dot fi Description: iconv_strlen seems to have a peculiar bug. It doesn't work when the string searched is less than three characters long (or an empty string), but reports Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 7 This is tested on PHP 5.0.3 and 5.1 from CVS (2005-06-07), tested with the built-in (glibc 2.3.3) iconv and libiconv 1.9.2 from gnu.org. This problem doesn't seem to surface on my Debian 3.1 development server, but I get it on my SuSE 9.2 desktop. I have tried to set the encodings with iconv_set_encoding() and I have tried to set the encoding as a parameter to iconv_strlen(), both produce the same error. The other iconv-functions (iconv_strpos, iconv_substr, iconv_strrpos) work fine. Since the iconv-functions do not seem to work from the commandline (produces an Unknown error(29)), I cannot get a proper strace (strace seems to say that iconv is trying to seek on /dev/pts/5, which apparently is impossible). It doesn't crash apache either, so I'm not sure where I'd grab the backtrace. List of modules: [EMAIL PROTECTED]:~> php -m [PHP Modules] bz2 ctype curl dom exif gd iconv libxml openssl pcre PDO pdo_sqlite pgsql posix session SimpleXML soap SPL standard tokenizer wddx xml xmlrpc xsl zlib [Zend Modules] PHP version: [EMAIL PROTECTED]:~> php --version PHP 5.1.0-dev (cli) (built: Jun 7 2005 21:30:37) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies configure line: './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-openssl' '--with-curl' '--with-zlib' '--with-bz2' '--enable-exif' '--with-gd' '--with-pgsql=/usr' '--enable-soap' '--enable-wddx' '--without-sqlite' '--with-xmlrpc' '--with-xsl' '--with-jpeg-dir=/usr/local/' '--with-png-dir=/usr/local/' '--without-mysql' '--with-xslt-sablot' '--with-iconv=/usr/local/' '--enable-debug' Reproduce code: --- Expected result: bool(false) Actual result: -- Notice: iconv_strlen() [function.iconv-strlen]: Unknown error (2) in /usr/local/apache/htdocs/test2.php on line 2 bool(false) -- Edit this bug report at http://bugs.php.net/?id=33268&edit=1
#25127 [Com]: error with memory limit
ID: 25127
Comment by: scott at lenderlab dot com
Reported By: henrik dot gebauer at web dot de
Status: Assigned
Bug Type: GD related
Operating System: Mandrake 9.1
PHP Version: 4.3.3RC5-dev, 5.0.0b2-dev
Assigned To: iliaa
New Comment:
Our company is developing a new network to handle the increase in
files, and database queries. our existing server is running PHP 4.3.0
while our new server is running 4.3.2. We are having issue after issue
with our new server in doing MySQL queries, wether its 30,000, 3000, or
300 records, it exceeds the memory limit. but when doing the same query
on our old server it can return back 40,000 records no problem. the PHP
configurations are the same and the version of MySQL is the same. Both
are running Red Hat 9. any suggestions? could it be the PHP version?
Previous Comments:
[2003-08-22 10:46:09] mpaesold at gmx dot at
The same problem exists in PHP 4.3.2.
Regards, Michael
[2003-08-19 07:06:58] [EMAIL PROTECTED]
[EMAIL PROTECTED] jani]$ php -dmemory_limit=9388608 -r
'imagecreatefromjpeg("p1010025.jpg");'
Fatal error: Allowed memory size of 9388608 bytes exhausted (tried to
allocate 7936 bytes) in Command line code on line 1
/usr/src/web/php/php4_3/main/streams.c(392) : Stream of type 'STDIO'
0x085CAF2C (path:p1010025.jpg) was not closed
[2003-08-19 06:25:00] henrik dot gebauer at web dot de
My configure line:
'./configure' \
'--with-apxs2=/usr/local/apache2/bin/apxs' \
'--with-config-file-path=/etc' \
'--with-zlib' \
'--with-gd' \
'--with-mysql=/usr/src/mysql-4.0.14/include/' \
'--enable-sockets' \
'--enable-memory-limit' \
'--enable-trans-sid' \
'--with-jpeg-dir=/usr/src/jpeg-6b' \
'--with-png-dir=/usr/src/libpng'
The error does not occur with images with a smaller file size.
Try this picture to reproduce it:
http://www.henrikgebauer.de.vu/bilder/klassenfahrt_kanu2003/p1010025.jpg
[2003-08-19 04:42:17] [EMAIL PROTECTED]
What was the configure line you used to configure PHP?
(config.nice)
[2003-08-19 04:22:19] henrik dot gebauer at web dot de
I get the same error using the latest CVS version.
It seems to be luck if it works or not because after reloading the
script a few times it works.
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/25127
--
Edit this bug report at http://bugs.php.net/?id=25127&edit=1
#25467 [Com]: mail corruption
ID: 25467 Comment by: scott at dotsonspace dot com Reported By: drew dot griffiths at clara dot co dot uk Status: Closed Bug Type: Mail related Operating System: windows 2000 PHP Version: 4.3.3 New Comment: I have been experiencing the same problem. I upgraded to 4.3.3 from 4.3.2. Upon upgrading when I would send out an e-mail with my $page_content variable as the body it simply strips a single html opening tag, which in turn messes up my table. But, when I echo the same $page_content variable to the browser no such error exists. I have since rolled back to version 4.3.2 to alleviate the problem and everything appears to work fine. Previous Comments: [2003-09-10 08:00:22] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-09-10 07:49:11] drew dot griffiths at clara dot co dot uk Description: Php 4.3.3 has been installed on a fully patched windows 2000 system with IIS. A function which passes html code within a variable to the mail function produces a random corruption of characters within the email. This has been tested with different SMTP servers with no effect. The problem was resolved by installing a previous version of PHP. (4.2.x) This problem would only occur when the HTML was passed in a variable and echoing the variable to the screen showed no corruption. -- Edit this bug report at http://bugs.php.net/?id=25467&edit=1
#27509 [NEW]: fsockopen() failed with "Addr family not supported by protocol" error
From: scott at abcoa dot com Operating system: AIX 4.3.3 PHP version: 4.3.4 PHP Bug Type: Sockets related Bug description: fsockopen() failed with "Addr family not supported by protocol" error Description: I had no trouble with the fsockopen() until I upgraded to PHP 4.3.4. My last working version was 4.2.3 before the upgrade. It sure look like a fsockopen() issue. Enclosed below is the source code that produce the same error result with both the Apache/Browser and the Shell Environment. I tried variety of URL Address and still get the same result, like www.google.com, www.cnn.com, www.php.net, etc... Been trying different ways with the scripts, machine and network and yet get the same result. I tried with and without the "tcp:\\" and still get the same result. (One more thing, could error 66 meant 6 with an one digit, not two??) Reproduce code: --- Expected result: Should expect to see an successful connection to www.google.com Actual result: -- Warning: fsockopen() [http://www.php.net/function.fsockopen]: php_hostconnect: connect failed in <> on line 5 Warning: fsockopen() [http://www.php.net/function.fsockopen]: unable to connect to www.google.com:80 in <> on line 5 66 Addr family not supported by protocol -- Edit bug report at http://bugs.php.net/?id=27509&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27509&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27509&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27509&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27509&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27509&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27509&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27509&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27509&r=support Expected behavior: http://bugs.php.net/fix.php?id=27509&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27509&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27509&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27509&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27509&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27509&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27509&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27509&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27509&r=float
#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 reply to the 3 comments since my last reply. 1) Excuse my typo, so tried again on the tcp with "//" and got an errno with "0" and errstr with "Error 0". The fsockopen() instruction at php.net showed that this meant an error had occur before the fsockopen(). So, tried the "127.0.0.1" without the "tcp://" and got the original error, with "66" and "Addr family not supported by protocol". You know, I did this one test by using the terminal emulator and use the telnet command, "telnet www.google.com 80" and was able to connected successfully and receive data from it. 2) Recompiled the latest CVS snapshot and still get the same error message. 3) Again, recompiled the latest CVS snapshot with "--disable-ipv6" option and still get this same error message. Now I'm a little concern about how much of a time will be spend on this or whether would this be dragged on like months and months or something. Scott Previous Comments: [2004-03-06 16:35:08] [EMAIL PROTECTED] If that doesn't work, try configuring PHP using --disable-ipv6 [2004-03-06 13:29:13] [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 [2004-03-05 18:16:39] scottmacvicar at ntlworld dot com Should be tcp:// not tcp:\\ since \ is an escape character and will end up being evaluated to tcp:\ How about a local IP do they work? ---- [2004-03-05 17:59:13] scott at abcoa dot com Description: I had no trouble with the fsockopen() until I upgraded to PHP 4.3.4. My last working version was 4.2.3 before the upgrade. It sure look like a fsockopen() issue. Enclosed below is the source code that produce the same error result with both the Apache/Browser and the Shell Environment. I tried variety of URL Address and still get the same result, like www.google.com, www.cnn.com, www.php.net, etc... Been trying different ways with the scripts, machine and network and yet get the same result. I tried with and without the "tcp:\\" and still get the same result. (One more thing, could error 66 meant 6 with an one digit, not two??) Reproduce code: --- Expected result: Should expect to see an successful connection to www.google.com Actual result: -- Warning: fsockopen() [http://www.php.net/function.fsockopen]: php_hostconnect: connect failed in <> on line 5 Warning: fsockopen() [http://www.php.net/function.fsockopen]: unable to connect to www.google.com:80 in <> on line 5 66 Addr family not supported by protocol -- Edit this bug report at http://bugs.php.net/?id=27509&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: Yea, it is a clean build. Tried it again with php5 beta 4 from the php.net website. Don't see any CVS links for that. Still get the error but it's a different errors. I can not make sense out of this one. --snip-- Content-type: text/html X-Powered-By: PHP/5.0.0b4 !#/usr/local/bin/php Warning: fsockopen() [function.fsockopen]: unable to connect to www.google.com:80 (Unknown error) in <> on line 7 268976720 --snip-- The output, "268976720" is the output by $errstr... Oddly, no displayed $errno... I tried the --disable-ipv6 option and ran the configure, it showed that IP V6 Support is found during the configuration. Thought you may want to know because I'm not sure if this may help. Previous Comments: [2004-03-08 11:52:38] [EMAIL PROTECTED] Are you 100% sure you made a clean build after reconfiguring php ? (make clean ; make) If yes, please try building latest php5 snapshot as a cli to test your script; it has some runtime intelligence to detect systems with broken network stacks. ---- [2004-03-08 10:06:30] scott at abcoa dot com In reply to the 3 comments since my last reply. 1) Excuse my typo, so tried again on the tcp with "//" and got an errno with "0" and errstr with "Error 0". The fsockopen() instruction at php.net showed that this meant an error had occur before the fsockopen(). So, tried the "127.0.0.1" without the "tcp://" and got the original error, with "66" and "Addr family not supported by protocol". You know, I did this one test by using the terminal emulator and use the telnet command, "telnet www.google.com 80" and was able to connected successfully and receive data from it. 2) Recompiled the latest CVS snapshot and still get the same error message. 3) Again, recompiled the latest CVS snapshot with "--disable-ipv6" option and still get this same error message. Now I'm a little concern about how much of a time will be spend on this or whether would this be dragged on like months and months or something. Scott [2004-03-06 16:35:08] [EMAIL PROTECTED] If that doesn't work, try configuring PHP using --disable-ipv6 [2004-03-06 13:29:13] [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 [2004-03-05 18:16:39] scottmacvicar at ntlworld dot com Should be tcp:// not tcp:\\ since \ is an escape character and will end up being evaluated to tcp:\ How about a local IP do they 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
#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: 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. Previous Comments: [2004-03-08 13:09:01] scott at abcoa dot com Yea, it is a clean build. Tried it again with php5 beta 4 from the php.net website. Don't see any CVS links for that. Still get the error but it's a different errors. I can not make sense out of this one. --snip-- Content-type: text/html X-Powered-By: PHP/5.0.0b4 !#/usr/local/bin/php Warning: fsockopen() [function.fsockopen]: unable to connect to www.google.com:80 (Unknown error) in <> on line 7 268976720 --snip-- The output, "268976720" is the output by $errstr... Oddly, no displayed $errno... I tried the --disable-ipv6 option and ran the configure, it showed that IP V6 Support is found during the configuration. Thought you may want to know because I'm not sure if this may help. [2004-03-08 11:52:38] [EMAIL PROTECTED] Are you 100% sure you made a clean build after reconfiguring php ? (make clean ; make) If yes, please try building latest php5 snapshot as a cli to test your script; it has some runtime intelligence to detect systems with broken network stacks. ---- [2004-03-08 10:06:30] scott at abcoa dot com In reply to the 3 comments since my last reply. 1) Excuse my typo, so tried again on the tcp with "//" and got an errno with "0" and errstr with "Error 0". The fsockopen() instruction at php.net showed that this meant an error had occur before the fsockopen(). So, tried the "127.0.0.1" without the "tcp://" and got the original error, with "66" and "Addr family not supported by protocol". You know, I did this one test by using the terminal emulator and use the telnet command, "telnet www.google.com 80" and was able to connected successfully and receive data from it. 2) Recompiled the latest CVS snapshot and still get the same error message. 3) Again, recompiled the latest CVS snapshot with "--disable-ipv6" option and still get this same error message. Now I'm a little concern about how much of a time will be spend on this or whether would this be dragged on like months and months or something. Scott [2004-03-06 16:35:08] [EMAIL PROTECTED] If that doesn't work, try configuring PHP using --disable-ipv6 [2004-03-06 13:29:13] [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 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
#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: I did mentioned that I have been doing this for a month. Compiling is no stranger to me because of doing this for 5 years. To avoid getting myself from going insane here, I decided to take your advice about trying it again. This time I'm putting down all of the steps I did and post the configure's responses here. After compiling/installing, I still get this same fsockopen() error message, "268976720" Snip #1 --snip- Typed: "cd /usr/local/src3/php-5.0.0b4" Typed: "make clean" Typed: "rm config.cache" Typed: "rm config.log" Typed: "./configure --disable-ipv6 --disable-libxml" Typed: "make" Typed: "make install" --snip-- Snip #2 --snip-- Response: creating cache ./config.cache checking host system type... powerpc-ibm-aix4.3.2.0 checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... yes checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... no checking for re2c... exit 0; checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking for bison... bison -y checking bison version... configure: warning: You will need bison 1.28, 1.35, 1.75 or 1.875 if you want to regenerate the Zend parser (found 1.25). 1.25 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... -mthreads checking for pthreads_lib... 00Configuring SAPI modules00 checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for member fd in BUFF *... no checking for mod_charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Apache 1.x (hooks) module support via DSO through APXS... no checking for Apache 1.x (hooks) module support... no checking for mod_charset compatibility option... no checking for Caudium support... no checking for CLI build... yes checking for Continuity support... no checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for Milter support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for thttpd... no checking for TUX... no checking for webjames... no checking for CGI build... yes checking whether writing to stdout works... This is the test message -- yes checking whether to force Apache CGI redirect... no checking whether to discard path_info + path_translated... no checking whether to enable path info checking... yes checking whether to enable fastcgi support... no checking for chosen SAPI module... cgi 00Running system checks00 checking for missing declarations of reentrant functions... done checking for sendmail... /usr/sbin/sendmail checking whether system uses EBCDIC... no checking for socket... yes checking for htonl... yes checking for gethostname... yes checking for gethostbyaddr... yes checking for yp_get_default_domain... yes checking for dlopen... yes checking for sin in -lm... yes checking for res_search... yes checking for inet_aton... yes checking for dn_skipname... yes checking for ANSI C header files... yes checking for dirent.h
#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: 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. Previous Comments: [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. ---- [2004-03-08 13:09:01] scott at abcoa dot com Yea, it is a clean build. Tried it again with php5 beta 4 from the php.net website. Don't see any CVS links for that. Still get the error but it's a different errors. I can not make sense out of this one. --snip-- Content-type: text/html X-Powered-By: PHP/5.0.0b4 !#/usr/local/bin/php Warning: fsockopen() [function.fsockopen]: unable to connect to www.google.com:80 (Unknown error) in <> on line 7 268976720 --snip-- The output, "268976720" is the output by $errstr... Oddly, no displayed $errno... I tried the --disable-ipv6 option and ran the configure, it showed that IP V6 Support is found during the configuration. Thought you may want to know because I'm not sure if this may help. [2004-03-08 11:52:38] [EMAIL PROTECTED] Are you 100% sure you made a clean build after reconfiguring php ? (make clean ; make) If yes, please try building latest php5 snapshot as a cli to test your script; it has some runtime intelligence to detect systems with broken network stacks. 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
#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
#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] [EMAI
#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-
#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: Not a problem! Been wanting the fsockopen() to work, so my company's website can function once again. Applied the patch and went through the programmer's ritual (compiling) all over again. Out came the result, believe it or not, it's the same end result. --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-- Look like the four functions, "php_host_connect(***)", "php_network_getaddress(***)", "php_connect_nonb(***)" and "dump_stock_state(***)" wasn't reached and executed. I did open up the network.c and 27509-diff.txt with the editor and check to see if the patch was applied correctly and I can confirm that the patch was insteed applied. :-( Previous Comments: [2004-03-10 18:42:19] [EMAIL PROTECTED] 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 ---- [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
#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: Here's the response I got... It's also the same with the host, "www.example.com" instead of "www.google.com". --snip-- Content-type: text/html X-Powered-By: PHP/4.3.5RC4-dev !#/usr/local/bin/php getaddresses GETADDRINFO method defaulting to AF_INET(2) hints.ai_family = 0 got result sai->ai_family = 2 returning from getaddresses: n = 1 php_network_getaddresses returned 1 Creating socket of type 0 (AF_INET = 2) socket() returned: -1 Warning: fsockopen(): unable to connect to www.google.com:80 in /home/website/emarket/test_fsockopen_shell.sh on line 6 66 Addr family not supported by protocol --snip-- Previous Comments: [2004-03-11 13:12:03] [EMAIL PROTECTED] Sorry, I wanted you to run a test with fsockopen(), not the socket_* extension. (Believe it or not they're completely different implementations even though they do the same thing) Please run that one against the version you've already patched and compiled. ---- [2004-03-11 10:54:40] scott at abcoa dot com Not a problem! Been wanting the fsockopen() to work, so my company's website can function once again. Applied the patch and went through the programmer's ritual (compiling) all over again. Out came the result, believe it or not, it's the same end result. --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-- Look like the four functions, "php_host_connect(***)", "php_network_getaddress(***)", "php_connect_nonb(***)" and "dump_stock_state(***)" wasn't reached and executed. I did open up the network.c and 27509-diff.txt with the editor and check to see if the patch was applied correctly and I can confirm that the patch was insteed applied. :-( [2004-03-10 18:42:19] [EMAIL PROTECTED] 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 [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
#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: With the latest CVS tarball and the configure line, "./configure --disable-ipv6". After configuring and before the make compilation. The main/php_config.h showed ... --snip-- /* Whether to enable IPv6 support */ /* #undef HAVE_IPV6 */ --snip-- So far, so good. Again, checking for ... --snip-- /* Define if you have the getaddrinfo function */ #define HAVE_GETADDRINFO 1 --snip-- So, it is already defined as you expected. So, replacing it with "/* #define HAVE_GETADDRINFO 1 */". Then on to make and installing. So far, so good. Then ran the fsockopen() test.. The result look good.. --snip-- Content-type: text/html X-Powered-By: PHP/4.3.5RC4-dev !#/usr/local/bin/php 0 --snip-- Then tested with the "Example 1. fsockopen() Example" from http://us3.php.net/manual/en/function.fsockopen.php and it work like a charm. Let me know when the fix is made and get checked into the CVS for 4.3.4 build/branch and for 5.0 build/branch. I'll be happy to do a few more testing if you need me to. Previous Comments: [2004-03-11 15:40:28] [EMAIL PROTECTED] That's. I think "messed up" is the technical term. I see two major problems here. 1) hints.ai_family is being reset by code that should be excluded by having used the --disable-ipv6 switch. 2) getaddrinfo() is returning a structure that, while it contains a top-level field insisting it's an AF_INET address. Contains a sockaddr child structure with an ai_family of PF_UNSPEC. So when php_hostconenect gets it, it tries creating a socket with an "unspecified" address family. No wonder it's unsupported eh? Let's go down this road: First, undo that patch, download a new tarball if necessary. Heck, might as well grab the latest CVS snapshot. Though if you reuse your current tree with a restored main/network.c you'll need to be sure and run `make clean`. Next, run a normal ./configure with the --disable-ipv6 switch. Now, BEFORE running make, edit main/php_config.h and check that HAVE_IPV6 is in fact, not defined. If it is defined, comment it out (And let us know in your feedback). Next, look for HAVE_GETADDRINFO in the same file. Make sure it is also undefined. (I expect that it will be defined, so you'll need to comment it out) Finally, run make, and try out the fsockopen test. ---- [2004-03-11 13:55:26] scott at abcoa dot com Here's the response I got... It's also the same with the host, "www.example.com" instead of "www.google.com". --snip-- Content-type: text/html X-Powered-By: PHP/4.3.5RC4-dev !#/usr/local/bin/php getaddresses GETADDRINFO method defaulting to AF_INET(2) hints.ai_family = 0 got result sai->ai_family = 2 returning from getaddresses: n = 1 php_network_getaddresses returned 1 Creating socket of type 0 (AF_INET = 2) socket() returned: -1 Warning: fsockopen(): unable to connect to www.google.com:80 in /home/website/emarket/test_fsockopen_shell.sh on line 6 66 Addr family not supported by protocol --snip-- [2004-03-11 13:12:03] [EMAIL PROTECTED] Sorry, I wanted you to run a test with fsockopen(), not the socket_* extension. (Believe it or not they're completely different implementations even though they do the same thing) Please run that one against the version you've already patched and compiled. [2004-03-11 10:54:40] scott at abcoa dot com Not a problem! Been wanting the fsockopen() to work, so my company's website can function once again. Applied the patch and went through the programmer's ritual (compiling) all over again. Out came the result, believe it or not, it's the same end result. --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-- Look like the four functions, "php_host_connect(***)", "php_network_getaddress(***)", "php_connect_nonb(***)" and "dump_stock_state(***)" wasn't reached and executed. I did open up the network.c and 27509-diff.txt with the editor and check to see if the patch was applied correctly and I can confirm that the patch was insteed applied. :-( -
#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: Is it still possible for me to use the ipv6 enabled later on? Previous Comments: [2004-03-11 17:42:23] scott at abcoa dot com With the latest CVS tarball and the configure line, "./configure --disable-ipv6". After configuring and before the make compilation. The main/php_config.h showed ... --snip-- /* Whether to enable IPv6 support */ /* #undef HAVE_IPV6 */ --snip-- So far, so good. Again, checking for ... --snip-- /* Define if you have the getaddrinfo function */ #define HAVE_GETADDRINFO 1 --snip-- So, it is already defined as you expected. So, replacing it with "/* #define HAVE_GETADDRINFO 1 */". Then on to make and installing. So far, so good. Then ran the fsockopen() test.. The result look good.. --snip-- Content-type: text/html X-Powered-By: PHP/4.3.5RC4-dev !#/usr/local/bin/php 0 --snip-- Then tested with the "Example 1. fsockopen() Example" from http://us3.php.net/manual/en/function.fsockopen.php and it work like a charm. Let me know when the fix is made and get checked into the CVS for 4.3.4 build/branch and for 5.0 build/branch. I'll be happy to do a few more testing if you need me to. [2004-03-11 15:40:28] [EMAIL PROTECTED] That's. I think "messed up" is the technical term. I see two major problems here. 1) hints.ai_family is being reset by code that should be excluded by having used the --disable-ipv6 switch. 2) getaddrinfo() is returning a structure that, while it contains a top-level field insisting it's an AF_INET address. Contains a sockaddr child structure with an ai_family of PF_UNSPEC. So when php_hostconenect gets it, it tries creating a socket with an "unspecified" address family. No wonder it's unsupported eh? Let's go down this road: First, undo that patch, download a new tarball if necessary. Heck, might as well grab the latest CVS snapshot. Though if you reuse your current tree with a restored main/network.c you'll need to be sure and run `make clean`. Next, run a normal ./configure with the --disable-ipv6 switch. Now, BEFORE running make, edit main/php_config.h and check that HAVE_IPV6 is in fact, not defined. If it is defined, comment it out (And let us know in your feedback). Next, look for HAVE_GETADDRINFO in the same file. Make sure it is also undefined. (I expect that it will be defined, so you'll need to comment it out) Finally, run make, and try out the fsockopen test. ---- [2004-03-11 13:55:26] scott at abcoa dot com Here's the response I got... It's also the same with the host, "www.example.com" instead of "www.google.com". --snip-- Content-type: text/html X-Powered-By: PHP/4.3.5RC4-dev !#/usr/local/bin/php getaddresses GETADDRINFO method defaulting to AF_INET(2) hints.ai_family = 0 got result sai->ai_family = 2 returning from getaddresses: n = 1 php_network_getaddresses returned 1 Creating socket of type 0 (AF_INET = 2) socket() returned: -1 Warning: fsockopen(): unable to connect to www.google.com:80 in /home/website/emarket/test_fsockopen_shell.sh on line 6 66 Addr family not supported by protocol --snip-- [2004-03-11 13:12:03] [EMAIL PROTECTED] Sorry, I wanted you to run a test with fsockopen(), not the socket_* extension. (Believe it or not they're completely different implementations even though they do the same thing) Please run that one against the version you've already patched and compiled. [2004-03-11 10:54:40] scott at abcoa dot com Not a problem! Been wanting the fsockopen() to work, so my company's website can function once again. Applied the patch and went through the programmer's ritual (compiling) all over again. Out came the result, believe it or not, it's the same end result. --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-- Look like the four functions, "php_host_connect(***)", "php_network_getaddress(***)", "php_connect_nonb(***)" and "dump_stock_state(***)" wasn't reached and executed. I did open up the network.c and 27509-diff.txt with the editor and check to s
#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 Assigned To: pollita New Comment: Downloaded the CVS snapshot "php4-STABLE-200403121830" and did the configure line with the common options I use for Apache, like openssl, odbc, etc. This time, I left out the "--disable-ipv6" option. So far so good, re-checked the file, "main/php_config.h" for "HAVE_IPV6" and "HAVE_GETADDRINFO". So far, so good. The "HAVE_GETADDRINFO" is comment out as expected with the recent fix. Went on to make and install PHP and test the fsockopen(). So far so good. (Just want to test it just in case :-) ). Then tried again with the same configure line but include the "--disable-ipv6". So far so good with the "HAVE_GETADDRINFO" commented out and "HAVE_IPV6" with a value of "0". The fix you checked in is working great!! You got it! Previous Comments: [2004-03-11 19:42:29] [EMAIL PROTECTED] I've committed an extended check to configure.in but it didn't make it into the 3/12/04 00:30 GMT snapshot. You'll need to wait for the 3/12/04 02:30 GMT snapshot. When you get a change to try that out, run ./configure (with whatever options you'd normally use). after configure completes, check your main/php_config.h for the HAVE_GETADDRINFO line. If it's still defined (despite the revised check) then email me a copy of your config.log file. Otherwise all should be well, go ahead and `make` and test out fsockopen(). Even if it works, reply back saying so, that way I can merge the change to the PHP5 branch and close this bug out. [2004-03-11 18:07:54] [EMAIL PROTECTED] I'd say "give it a shot". The problem is sounding very much like a brokenness in the getaddrinfo() implementation rather than the IPv6 stack. I'll see what can be done about building a getaddrinfo test into the ./configure process so that it's automatically disabled if it proves itself unreliable. I want to discuss this with some people before making any commits, in the mean time I encourage you to try different settings with/without HAVE_IPV6 and with/without HAVE_GETADDRINFO. Work in your normal ./configure options (i.e.: --with-apxs, --enable-ftp, --with-sqlite, etc...) as well. [2004-03-11 17:43:34] scott at abcoa dot com Is it still possible for me to use the ipv6 enabled later on? [2004-03-11 17:42:23] scott at abcoa dot com With the latest CVS tarball and the configure line, "./configure --disable-ipv6". After configuring and before the make compilation. The main/php_config.h showed ... --snip-- /* Whether to enable IPv6 support */ /* #undef HAVE_IPV6 */ --snip-- So far, so good. Again, checking for ... --snip-- /* Define if you have the getaddrinfo function */ #define HAVE_GETADDRINFO 1 --snip-- So, it is already defined as you expected. So, replacing it with "/* #define HAVE_GETADDRINFO 1 */". Then on to make and installing. So far, so good. Then ran the fsockopen() test.. The result look good.. --snip-- Content-type: text/html X-Powered-By: PHP/4.3.5RC4-dev !#/usr/local/bin/php 0 --snip-- Then tested with the "Example 1. fsockopen() Example" from http://us3.php.net/manual/en/function.fsockopen.php and it work like a charm. Let me know when the fix is made and get checked into the CVS for 4.3.4 build/branch and for 5.0 build/branch. I'll be happy to do a few more testing if you need me to. [2004-03-11 15:40:28] [EMAIL PROTECTED] That's. I think "messed up" is the technical term. I see two major problems here. 1) hints.ai_family is being reset by code that should be excluded by having used the --disable-ipv6 switch. 2) getaddrinfo() is returning a structure that, while it contains a top-level field insisting it's an AF_INET address. Contains a sockaddr child structure with an ai_family of PF_UNSPEC. So when php_hostconenect gets it, it tries creating a socket with an "unspecified" address family. No wonder it's unsupported eh? Let's go down this road: First, undo that patch, download a new tarball if necessary. Heck, might as well grab the latest CVS snapshot. Though if you reuse your current tree with a restored main/network.c you'll need to be sure and run `make
#27509 [Csd]: 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: Closed Bug Type: Sockets related Operating System: AIX 4.3.3 PHP Version: 4.3.4 Assigned To: pollita New Comment: Yea! Thanks for your time and patience with this bug too. Previous Comments: [2004-03-12 15:50:37] [EMAIL PROTECTED] Great, let's close it then :) [2004-03-12 15:43:48] scott at abcoa dot com Downloaded the CVS snapshot "php4-STABLE-200403121830" and did the configure line with the common options I use for Apache, like openssl, odbc, etc. This time, I left out the "--disable-ipv6" option. So far so good, re-checked the file, "main/php_config.h" for "HAVE_IPV6" and "HAVE_GETADDRINFO". So far, so good. The "HAVE_GETADDRINFO" is comment out as expected with the recent fix. Went on to make and install PHP and test the fsockopen(). So far so good. (Just want to test it just in case :-) ). Then tried again with the same configure line but include the "--disable-ipv6". So far so good with the "HAVE_GETADDRINFO" commented out and "HAVE_IPV6" with a value of "0". The fix you checked in is working great!! You got it! [2004-03-11 19:42:29] [EMAIL PROTECTED] I've committed an extended check to configure.in but it didn't make it into the 3/12/04 00:30 GMT snapshot. You'll need to wait for the 3/12/04 02:30 GMT snapshot. When you get a change to try that out, run ./configure (with whatever options you'd normally use). after configure completes, check your main/php_config.h for the HAVE_GETADDRINFO line. If it's still defined (despite the revised check) then email me a copy of your config.log file. Otherwise all should be well, go ahead and `make` and test out fsockopen(). Even if it works, reply back saying so, that way I can merge the change to the PHP5 branch and close this bug out. [2004-03-11 18:07:54] [EMAIL PROTECTED] I'd say "give it a shot". The problem is sounding very much like a brokenness in the getaddrinfo() implementation rather than the IPv6 stack. I'll see what can be done about building a getaddrinfo test into the ./configure process so that it's automatically disabled if it proves itself unreliable. I want to discuss this with some people before making any commits, in the mean time I encourage you to try different settings with/without HAVE_IPV6 and with/without HAVE_GETADDRINFO. Work in your normal ./configure options (i.e.: --with-apxs, --enable-ftp, --with-sqlite, etc...) as well. [2004-03-11 17:43:34] scott at abcoa dot com Is it still possible for me to use the ipv6 enabled later on? 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
#26016 [Com]: Warning: fsockopen(): Bug
ID: 26016 Comment by: scott at marinar dot com Reported By: hill at bluecarrots dot com Status: No Feedback Bug Type: *General Issues Operating System: Linux PHP Version: 4.3.3 New Comment: The same is seen here with php 4.3.6 freshly compiled on Debian / Linux. Configure command is "./configure --enable-bcmath --with-openssl=/usr/local/openssl --with-mysql --with-apxs=/usr/bin/apxs --prefix=/usr/local" This bug persists through reloads of apache; apache version is 1.3.26. With so many people obviously affected by this PHP bug across multiple platforms, I'm concerned that the answer from PHP seems to be "it's not a PHP problem" promptly followed by marking threads as bogus. --Scott! Previous Comments: [2004-03-19 03:39:53] andrew at shh dot fi The error is real except this guy has the wrong script. I have the same problem - this is the script: $method = "ssl://"; $host = "myserver.com"; $port = 443; $fp = fsockopen($method.$host, $port, $errno, $errstr, $timeout = 30); I get the error: Warning: fsockopen(): no SSL support in this build AND SSL is loaded in php. Its a bug I patch on windows, but need one for linux [2003-11-03 14:06:38] [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-10-28 04:44:03] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. please provide a sample script to illustrate the problem [2003-10-28 04:40:30] hill at bluecarrots dot com Description: I get the warning at the top of the page. Several refreshes of the browser rectifies. Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/.sites/.blahphp on line 14 Warning: fsockopen(): unable to connect to blah.com:80 in /home/.sites/blah.php on line 14 Resource temporarily unavailable (11) Reproduce code: --- Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/.sites/.blahphp on line 14 Warning: fsockopen(): unable to connect to blah.com:80 in /home/.sites/blah.php on line 14 Resource temporarily unavailable (11) Expected result: I expect the page to connect securely to a secure server and send some secure details. I get the warning at the top of the page. Several refreshes of the browser rectifies. I have to use this PHP code, which has been provided by the Payment provider, to get to a server that takes online payments, some information is first sent securely in order to reach the payment page on the Payment providers server. Actual result: -- The simle page takes time to load and when it does the fsockopen warning is present. -- Edit this bug report at http://bugs.php.net/?id=26016&edit=1
#29926 [NEW]: display_errors setting ignored
From: scott at slerman dot net Operating system: Fedora Core 2 PHP version: 5.0.1 PHP Bug Type: *Configuration Issues Bug description: display_errors setting ignored Description: The php.ini setting display_errors seems to be ignored; no errors are displayed, even if display_errors is turned on. Reproduce code: --- "; echo $foo . "bar"; $foo[bar] = "phpinfo()"; ?> Expected result: There should be warning messages about $foo being undefined and the constant "bar" being undefined. Actual result: -- Output is: 1 bar As far as I know, the first line being 1 means that display_errors is on. -- Edit bug report at http://bugs.php.net/?id=29926&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29926&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29926&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29926&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=29926&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=29926&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29926&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29926&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29926&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29926&r=support Expected behavior: http://bugs.php.net/fix.php?id=29926&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29926&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29926&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=29926&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29926&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=29926&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29926&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29926&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29926&r=float
#29926 [Bgs]: display_errors setting ignored
ID: 29926 User updated by: scott at slerman dot net Reported By: scott at slerman dot net Status: Bogus Bug Type: *Configuration Issues Operating System: Fedora Core 2 PHP Version: 5.0.1 New Comment: Good point. I had checked phpinfo(), and it said error_reporting was 4095, so I figured it couldn't have been that. I discovered a .htaccess file that was setting error_reporting to 2048 (which, in my own defense, I don't remember ever creating). Will remember this next time. Previous Comments: [2004-09-01 08:00:17] [EMAIL PROTECTED] Which errors are shown (error level) has to do with error_reporting, not display_errors. [2004-09-01 05:51:42] scott at slerman dot net Description: The php.ini setting display_errors seems to be ignored; no errors are displayed, even if display_errors is turned on. Reproduce code: --- "; echo $foo . "bar"; $foo[bar] = "phpinfo()"; ?> Expected result: There should be warning messages about $foo being undefined and the constant "bar" being undefined. Actual result: -- Output is: 1 bar As far as I know, the first line being 1 means that display_errors is on. -- Edit this bug report at http://bugs.php.net/?id=29926&edit=1
#25863 [Com]: IIS: The specified CGI application misbehaved
ID: 25863 Comment by: scott at decisivecommunications dot com Reported By: salmanarshad2000 at yahoo dot com Status: Closed Bug Type: CGI related Operating System: win32 only PHP Version: 4CVS, 5CVS, 6CVS.. New Comment: I had tons of problems getting php5 to work in IIS 5.1. So many reports have you just check phpinfo(); to see if it is working after an install, but once you run something with more complex (Wordpress) code it all goes to hell. I'm not pointing fingers I don't know where the bug lies, PHP, IIS, MySQL??? For myself some problems (like blank pages that shouldn't be) we fixed by using the CGI instead of ISAPI. But then I got CGI crashing on the WordPress login. I started over again with PHP 4.3.8 CGI installer and everything is now apprently working smoothly. Some boards reported turning of Zend Optimzation in the 5.0.1 PHP ini but I didn't even have that setting. Previous Comments: [2004-06-29 12:03:00] closedbolt at gmx dot de Seems like php.exe in php 5 rc3 does not prepend any headers. --> cgi error in IIS php-cgi.exe does... --> works fine for me now. Example: test.php C:\php>php.exe test.php hi C:\php>php-cgi.exe test.php Content-type: text/html X-Powered-By: PHP/5.0.0RC3 hi C:\php> [2004-06-23 18:38:14] tincanmann at hotmail dot com Hi, thanks for all the other posts and hopefully this can help someone else! I also struggled with this problem of getting PHP to run on IIS. I solved it slightly differently on my development server to the live production server, both running Win2003 Server (production being more patched, secure, etc). 1) Ensure anonymous access not allowed by editing the website details in IIS. This solved my one server but not the other. However, it all seems to stem from the security and permissions. 2) Try access the website using https:// instead of http:// ... strange, I know, but it worked for the production server (and saved me having to rewrite in ASP). Gareth [2004-05-26 15:36:11] onderoz at zmail dot sk PHP5 Release candidate 2 + IIS5 on W2K Advanced Server. Still having the same problem.. The damned CGI misbehaved bla bla bla.. I need a complete SOLUTION for this, not WORKAROUND, if we're talking about a complete language. What i did : 1.. Downloaded *latest* version of the PHP (5 RC2) 2.. Expanded zip file to the directory C:\PHP5\ 3.. added paths to PATH as C:\PHP5;C:\PHP5\EXT as in folder tree. 4.. added extension .php and .php5 with c:\php5\php.exe %s %S 5.. added extension to HKEY_CLASSES_ROOT 6.. added pathinfo to HKEY_LOCAL_MACHINE 7.. gave permissions -full control- to IUSR_*, IWAM_*, EVERYONE on C:\PHP5 and c:\inetpub\wwwroot\PHP5SCRIPTS 8.. edited php.ini file a. cgi.force_redirect=0 b. ;doc_root= so.. what's next?!? 1.. how should I get this system working with PHP? 2.. do I have to mess with these with every new installation/upgrade/system change? thanks folks, for *not* helping us newbies by not providing an automated system for the installation process. Onder [2004-05-08 20:20:53] dmeeking at shaw dot ca I found that excluding c:\php\ from my (Norton) virus scanner fixed the problem. Some comments led me to believe that windows was getting grumpy when multiple requests were being handled by php.exe. This made me wonder if the antivirus was locking the file, since it was set to scan every exe upon execution. Turning off scanning on the PHP folder has fixed this problem for me (iis5 / PHP 4.3.6). [2004-04-28 18:19:25] david dot blair at nsi1 dot com I need to retract my earlier statement of: "After the reset, the CGI errors occurred only once per page." 3 days in and we've had a couple reoccurring page errors...the frequency is going down, or people aren't getting back to me on the problem...the latter is most likely the case here. I should also state that we are running IIS 6 on 2003(I previously wrote 2000...my fault) 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/25863 -- Edit this bug report at http://bugs.php.net/?id=25863&edit=1
#32330 [Com]: session_destroy, "Failed to initialize storage module", custom session handler
ID: 32330
Comment by: scott at trtinfo dot com
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Session related
Operating System: *
PHP Version: 4CVS, 5CVS (2005-03-17)
Assigned To: sniper
New Comment:
i am getting this error on the following environments:
Windows2003 - Zend 2.03, php Version 5.0.3
Redhat 9, Zend 2.03, php Version 4.3.10
Redhat 9, Zend 2.03, php Version 4.3.9
this is happening more often each day. Sessions handler set to files,
session repository directory does not have any space issues. Chmod on
tmp dir set 777.
I am however creating my own hash value for the session id.
This is also done on another server and it has not had this session
error at all. Yet.
Previous Comments:
[2005-03-19 00:55:18] [EMAIL PROTECTED]
Good catch, thanks.
[2005-03-17 10:37:29] [EMAIL PROTECTED]
I see that the php_session_destroy() is called in php_session_decode()
too..
[2005-03-17 10:14:08] [EMAIL PROTECTED]
I unfortunately lack the time to verify this with a new php
installation currently.
By looking at
http://cvs.php.net/co.php/php-src/ext/session/session.c?r=1.336.2.50
(latest commit of 4_3 branch) the relevant parts of the code haven't
changed. PS(mod_data) is still set to NULL in php_rinit_session_globals
which is called from php_session_destroy, this when a user from PHP
calls session_destroy(), the custom session save handlers are removed.
Thanks
[2005-03-16 09:29:18] [EMAIL PROTECTED]
Description:
When I use custom session handling functions and use the following
session functions in this order:
[...]
session_set_save_handler(...)
[...]
session_start()
[...]
session_destroy()
[...]
session_start()
I get
"Fatal error: session_start(): Failed to initialize storage module:
user (path: /var/lib/php4) in test.php on line 9"
After session_destroy is called, the functions assigned with
session_set_save_handler() do not work anymore and have to be assigned
again.
By calling session_set_save_handler() again after session_destroy() it
will work.
This applies to 4.9.10 and 5.0.3 as well.
I think the cause is in session.c in php_session_destroy:
[...]
if (PS(mod)->s_destroy(&PS(mod_data), PS(id) TSRMLS_CC) == FAILURE)
{
retval = FAILURE;
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Session object
destruction failed");
}
php_rshutdown_session_globals(TSRMLS_C);
php_rinit_session_globals(TSRMLS_C);
[...]
First, the user defined destroy-handler is called then
php_rshutdown_session_globals and then php_rinit_session_globals. In
php_rinit_session_globals PS(mod_data) is cleared
static void php_rinit_session_globals(TSRMLS_D)
{
PS(id) = NULL;
PS(session_status) = php_session_none;
PS(mod_data) = NULL;
PS(http_session_vars) = NULL;
}
which is a struct for the user defined functions.
The current documentation says:
"session_destroy() destroys all of the data associated with the current
session."
But it seems to do more: it also clears any custom set session save
handlers which unexpected.
Reproduce code:
---
Expected result:
No fatal error message
Actual result:
--
Fatal error: session_start(): Failed to initialize storage module: user
--
Edit this bug report at http://bugs.php.net/?id=32330&edit=1
#32330 [Com]: session_destroy, "Failed to initialize storage module", custom session handler
ID: 32330 Comment by: scott at trtinfo dot com Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Session related Operating System: * PHP Version: 4CVS, 5CVS (2005-03-17) Assigned To: sniper New Comment: scott => scliburn are one in the same :). We have not been using any custom session handlers. We have been utilizing the PHP built in session handlers. My session.save_handler all have been set to "files". I have noticed the error message still states: Fatal error: session_start(): Failed to initialize storage module: user (path: /tmp) Take notice to the module "user", however this is my php.ini (i've located and updated all instances of the php.ini); session.save_handler = files I was also unable to produce this error on another machine (win2003-webedition) which has thread saftey on. Not sure if that is helpful. This error has only produced itself after upgrading Zend 2+ on php 4.3.9, 4.3.10, & 5.03 (I cannot produce this error on 5.02 with Zend 2+) yet. I'm taking a wild non-technical quess in that the save_handler setting is obviously getting reset during a php request, but have no clue as to where. I know it's not the code calling to this. I wrote it. Zend? Heres another twist. I do have another site that is running osCommerce with custom session handlers and that site doesnot produce this error (once again, yet). odly enough Previous Comments: [2005-03-24 07:22:24] [EMAIL PROTECTED] scott, scliburn: are you both using session_set_save_handler() ? Are you operating in the same environment (custom save handlers are getting lost after session_destroy) or are you just having the same error message? Most bugs I've seen refering to 'Failed to initialize...' are because session module in php.ini is set to user instead of files when there are no custom session handlers, which has nothing to do with this issue. [2005-03-23 20:40:49] scliburn at trtinfo dot com I would like to also add that I'm running and experiencing this issue in both api versions CGI/ISAPI. not sure if that mattered ---- [2005-03-23 20:34:44] scott at trtinfo dot com i am getting this error on the following environments: Windows2003 - Zend 2.03, php Version 5.0.3 Redhat 9, Zend 2.03, php Version 4.3.10 Redhat 9, Zend 2.03, php Version 4.3.9 this is happening more often each day. Sessions handler set to files, session repository directory does not have any space issues. Chmod on tmp dir set 777. I am however creating my own hash value for the session id. This is also done on another server and it has not had this session error at all. Yet. [2005-03-19 00:55:18] [EMAIL PROTECTED] Good catch, thanks. [2005-03-17 10:37:29] [EMAIL PROTECTED] I see that the php_session_destroy() is called in php_session_decode() too.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32330 -- Edit this bug report at http://bugs.php.net/?id=32330&edit=1
#19528 [Opn]: odbc_fetch_row() doesn't returned true if there is one row only
ID: 19528 User updated by: scott at abcoa dot com Reported By: scott at abcoa dot com Status: Open Bug Type: ODBC related Operating System: AIX (UNIX) PHP Version: 4.2.2 New Comment: I was going to close this bug until I saw that there is 3 people out of 3 who are able to reproduce this problem. So, I decided to leave this open unless otherwise is closed by the developer at php.net because there are other people out there who are still struggling with this and are not as fortunate. The reason I'm going to close this bug is because I'm dumping IBM DB2 and make the move to Relexus Linter (DB software in Russia). It became appearant that it is a better software than IBM DB2 in many ways. Linter is smaller, use less maintainance, less headache, cost less, less problem with license, use less memory and work much faster on the same machine regardless of whether the table in the database is very large or not. Good Luck! Scott Previous Comments: [2003-03-11 08:49:39] scott at abcoa dot com Lost track of time, so sorry about that. What we're going to need is more people who are experiencing this problem. In answer to your question, I'm not sure if it is a driver issue or not because I have not upgraded the AIX nor have I upgraded the DB2 driver nor have I upgraded the DB2 software. I'm waiting for version 9.1 to come out and buy it, whew, it's a pretty expensive software. The only thing changes from that time of version 4.0.6 to 4.2.3 was the inclusion of the '--with-mcrypt' option to the configure command but this doesn't seem to be the cause of the problem because they are not related. We had one other user in this bug report who reported this problem. So, go ahead and put this bug in inactive status or something until someone can step forward with the problem. I don't have a solution to this problem. Thanks, Scott P.S. I have noticed that PHP have a built-in programming script that allow PHP to create a formatting and datas into a PDF then generate a PDF file. Maybe PHP developers can do that similar thing by coming up with some ideas to create a PHP Database or a PHP CVS file that can act as a database. The logic shouldn't be too difficult to come up with and it could help to depend less on the 3rd party database and instead more on the PHP. It is just an idea but not a bad idea... I would love to hear about it one day. [2003-03-10 20:41:10] [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-03-05 16:38:52] [EMAIL PROTECTED] To answer some of the comments in here, yes unixODBC is a Driver Manager much in the same vain as iODBC. The reason for asking is that while PHP does support DB2, I (as the developer) have no direct access to a DB2 machine to test if anything at all works on it. The unixODBC DM is actually the suggested and prefered method by IBM for connecting to a DB2 installation, not directly through library linking like you do in a --with-ibm-db2 option. The point of using a Driver Manager though is to remove the headaches of using a different database on a per machine basis. But again absolutely nothing has changed between odbc_fetch_row functionality from 4.0.6 and 4.2.3, hence I'm wondering if it's a driver issue. ---- [2003-03-05 14:37:53] scott at abcoa dot com I'm not sure if I would want to try it. Seem that I would need to use the driver manager and the driver. It reminded me of OpenLink that became too much and I threw it out in the past. I like the idea of having PHP's ODBC to work with DB2 by using the '--with-ibm-db2' prefix because it give me fewer softwares to work with. I mean DB2 is not only database I had to deal with, but of some different database softwares as well as some for Windows. I mean no offense. I didn't really have that problem way back in the past. Maybe the problem will fix itself in the near future. Who know! [2003-03-04 10:36:43] [EMAIL PROTECTED] Any chance you can try building with unixODBC as the driver, and connecting via that? It seems to be the recommended means from IBM for connecting to DB2 systems. The remainder of the comments for this report are too long.
#19528 [Csd]: odbc_fetch_row() doesn't returned true if there is one row only
ID: 19528 User updated by: scott at abcoa dot com Reported By: scott at abcoa dot com Status: Closed Bug Type: ODBC related Operating System: AIX (UNIX) PHP Version: 4.2.2 New Comment: Then the matter is settled. It would have been so cool to have table in text file where everything is arrange by x and y, just like the spreadsheet for an example. If everyone use this then we wouldn't have much need for thousands of database softwares. Previous Comments: [2003-06-24 10:21:14] [EMAIL PROTECTED] Sniper you like me, you really like me :) I won't open the can of worms that is remove the --with-ibm-db2 option until I have a more viable solution then what is currently enabled. So for those of you reading this in the future, worry not (yet)! [2003-06-23 21:14:05] [EMAIL PROTECTED] Like Mr. Kalowsky said, people should be using unixODBC anyway with IBM DB2 (if they even suggest that themselves too, we really should consider removing the not-so-good DB2 support altogether..?) Closing this for now. If someone else thinks it's worth to fix this, feel free to open new report..and donate some money to Dan. :) [2003-06-20 11:24:33] scott at abcoa dot com I was going to close this bug until I saw that there is 3 people out of 3 who are able to reproduce this problem. So, I decided to leave this open unless otherwise is closed by the developer at php.net because there are other people out there who are still struggling with this and are not as fortunate. The reason I'm going to close this bug is because I'm dumping IBM DB2 and make the move to Relexus Linter (DB software in Russia). It became appearant that it is a better software than IBM DB2 in many ways. Linter is smaller, use less maintainance, less headache, cost less, less problem with license, use less memory and work much faster on the same machine regardless of whether the table in the database is very large or not. Good Luck! Scott ---- [2003-03-11 08:49:39] scott at abcoa dot com Lost track of time, so sorry about that. What we're going to need is more people who are experiencing this problem. In answer to your question, I'm not sure if it is a driver issue or not because I have not upgraded the AIX nor have I upgraded the DB2 driver nor have I upgraded the DB2 software. I'm waiting for version 9.1 to come out and buy it, whew, it's a pretty expensive software. The only thing changes from that time of version 4.0.6 to 4.2.3 was the inclusion of the '--with-mcrypt' option to the configure command but this doesn't seem to be the cause of the problem because they are not related. We had one other user in this bug report who reported this problem. So, go ahead and put this bug in inactive status or something until someone can step forward with the problem. I don't have a solution to this problem. Thanks, Scott P.S. I have noticed that PHP have a built-in programming script that allow PHP to create a formatting and datas into a PDF then generate a PDF file. Maybe PHP developers can do that similar thing by coming up with some ideas to create a PHP Database or a PHP CVS file that can act as a database. The logic shouldn't be too difficult to come up with and it could help to depend less on the 3rd party database and instead more on the PHP. It is just an idea but not a bad idea... I would love to hear about it one day. [2003-03-10 20:41:10] [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. 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/19528 -- Edit this bug report at http://bugs.php.net/?id=19528&edit=1
#17732 [Com]: decode_request - reference vars depracated
ID: 17732 Comment by: scott at executebusiness dot com Reported By: ramses0 at yahoo dot com Status: Closed Bug Type: XMLRPC-EPI related Operating System: Linux PHP Version: 4.1.2 New Comment: Can someone suggest why this is deprecated? I haven't found any reason for allow_call_time_pass_reference deprecation. Far as I can tell using byref is a good idea in programming to save cpu time when passing large vars. Previous Comments: [2002-06-15 22:24:28] [EMAIL PROTECTED] This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. [2002-06-12 17:50:02] ramses0 at yahoo dot com Using the following demonstration RPC request, the function xmlrpc_decode_request (apparently) does not correctly update the passed in parameter $method_name, as described in the documentation on: http://xmlrpc-epi.sourceforge.net/main.php?t=php_api On a hunch, I tried changing the call to: xmlrpc_decode_request($xml, &$method); to use call-time pass by reference. It then worked, but call time pass by reference is depracated: Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of xmlrpc_decode_request(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. As an aside- it appears that you cannot "swallow" the warning by doing an $results = @decode( $a, &$b )... it stil gives the "warning, depracated" message. So that is possibly another bug. I have grepped through the source trees somewhat, but couldn't find much examples of functions directly affecting their passed in values (except "sort", which is pretty complicated). Thanks- --Robert (bugreport is mirrored at the sf.net pages, but that area appears to be mildly unmaintained) greeting Dan END; // "; echo "Request:"; print_r( $request ); // decode the request $method_name = ''; $stuff = xmlrpc_decode_request( $request, $method_name ); echo "Results:"; print_r( $stuff ); echo "Method:"; print_r( $method_name ); echo ""; ?> -- Edit this bug report at http://bugs.php.net/?id=17732&edit=1
#17868 [Com]: Doesn't work two and more directives of PHP code on different OS
ID: 17868 Comment by: scott at afmmail dot com Reported By: messiah at hotbox dot ru Status: Closed Bug Type: Apache2 related Operating System: * PHP Version: 4.3.0-dev New Comment: I too would really like to know if there is a fix for this problem. We are having the exact same problem running a clean install of Apache 2.0,40 Linus 9.0 with PHP 4.2.2 on our new server. We did try it using FreeBSD and everything worked fine. All of the php includes pased fine. Reinstalled Redhat and ran into the same problem again. After reading this thread I too am unsure where or how I can fix this problem. We really need to find a solution because it is holingup the implementation of our new server. Previous Comments: [2003-12-30 12:22:33] ccarroll4 at hotmail dot com I am also having this problem on a default install of Redhat 9 - Apache v. 2.0.40, PHP 4.2.2. Apache was not installed from an RPM (to my surprise), but PHP was. The posts here are confusing; one says go to PHP 4.3.2, the next says that installing 4.3.2 broke scripts. Any CLEAR solutions? After a year and a half, it seems like this should be resolved once and for all. [2003-12-01 08:47:50] raphael at segal dot com dot au Was this ever resolved - I am getting this error on a default RPM install of RedHat 9.0 [2003-08-10 17:31:02] php at pamelajoy dot com I use several includes on every PHP page. I have not had any problems until today when my webhost upgraded to PHP 4.3.2. Now none of my includes are being parsed. Yes, my webhost uses Apache, and we are discussing it in our forum at http://www.rivalpro.net/forums/iv1/index.php?act=ST&f=16&t=524&s=7e56594f281f099bcc05bbfb451bee12";>http://www.rivalpro.net/forums/iv1/index.php?act=ST&f=16&t=524&s=7e56594f281f099bcc05bbfb451bee12. I hope there is a solution other than changing back to shtml pages. [2003-05-28 17:56:13] [EMAIL PROTECTED] Wait for PHP 4.3.2. There using --with-apxs2 will enable the new handler version of the apache2 module. [2003-05-28 12:56:22] joe at joe-lewis dot com Is this apxs2 an apache configuration option or a php option? I am using apache 2.0.45, with php 4.3.1, and am still encountering the error. I have tried --with-apxs2handler=/usr/local/bin/apxs and --with-apxs2filter=/usr/local/bin/apxs in both PHP and Apache, with no successes. In fact, now (though my configuration is good), any PHP page is not executed or parsed, but returned as type x-httpd-php, which is "somewhat" operational (i.e. it has the right type, but the libphp4 module is not being called as specified in my httpd.conf file). 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/17868 -- Edit this bug report at http://bugs.php.net/?id=17868&edit=1
[PHP-BUG] Bug #62317 [NEW]: Session upload progress returns empty array if files larger than post_max_size
From: scott at phphq dot net Operating system: Win Server 2003 x86 / IIS 6 PHP version: 5.4.3 Package: Session related Bug Type: Bug Bug description:Session upload progress returns empty array if files larger than post_max_size Description: I am submitting this as a bug because PHP will instantly return an empty $_SESSION array if the file size sum of all uploaded files is larger than allowed by post_max_size or upload_max_filesize even though the browser continues to upload. I would expect that PHP would automatically cancel these uploads, or at least return an error so I can use $_SESSION[key]['cancel_upload']; myself. I'm on PHP 5.4.3, Win Server 2003 x86, IIS6 as fast_cgi. session.upload_progress.cleanup is turned off so I could try and debug this. It's not happening because of the cleanup process. Test script: --- Here is what you can use to duplicate the issue: http://phphq.net/_upbug/ Expected result: I would expect some sort of error. Actual result: -- Null responce -- Edit bug report at https://bugs.php.net/bug.php?id=62317&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62317&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62317&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62317&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62317&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62317&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62317&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62317&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62317&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62317&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62317&r=support Expected behavior: https://bugs.php.net/fix.php?id=62317&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62317&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62317&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62317&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62317&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62317&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62317&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62317&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62317&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62317&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62317&r=mysqlcfg
#45543 [Com]: DateTime::setTimezone can not set timezones without ID
ID: 45543
Comment by: scott at crisscott dot com
Reported By: tj at systisoft dot com
Status: Assigned
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3CVS-2008-07-17 (CVS)
Assigned To: derick
New Comment:
I was able to reproduce this with PHP 5.2.9 from the commandline.
php -v
PHP 5.2.9 (cli) (built: May 1 2009 13:47:24)
$> php -r '$d = new DateTime("2009-01-01 00:00:00+0400");
$d->setTimezone($d->getTimezone());'
Previous Comments:
[2008-07-17 14:34:47] tj at systisoft dot com
Description:
If you set a time zone for a DateTime via DateTime::setTimeZone() and
that time zone has no ID you get an error message and the time zone will
not be set.
This can lead to problems if you have two DateTime objects from a
source you do not control and want to format the second DateTime object
in the same time zone as the first.
Reproduce code:
---
$d1 = new DateTime('2008-01-01 12:00:00 +02:00');
$d2 = new DateTime('2008-01-01 12:00:00 UTC');
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;
$d2->setTimeZone($d1->getTimeZone());
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;
Expected result:
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
2008-01-01T12:00:00+0200
2008-01-01T14:00:00+0200
Actual result:
--
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
PHP Warning: DateTime::setTimezone(): Can only do this for zones with
ID for now in /Users/tobias/test.php on line 5
Warning: DateTime::setTimezone(): Can only do this for zones with ID
for
now in /Users/tobias/test.php on line 5
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
[2008-07-17 13:07:47] tj at systisoft dot com
Description:
if you set a time zone for a DateTime via DateTime::setTimeZone() and
that time zone has no ID you get an error message and the time zone will
not be set.
This can lead to Problems if you have two DateTime objects from a surce
you do not control and want to format the secont DateTime object in the
same time zone as the first.
Reproduce code:
---
$d1 = new DateTime('2008-01-01 12:00:00 +02:00');
$d2 = new DateTime('2008-01-01 12:00:00 UTC');
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;
$d2->setTimeZone($d1->getTimeZone());
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;
Expected result:
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
2008-01-01T12:00:00+0200
2008-01-01T14:00:00+0200
Actual result:
--
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
PHP Warning: DateTime::setTimezone(): Can only do this for zones with
ID for now in /Users/tobias/test.php on line 5
Warning: DateTime::setTimezone(): Can only do this for zones with ID
for now in /Users/tobias/test.php on line 5
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
--
Edit this bug report at http://bugs.php.net/?id=45543&edit=1
#47285 [Com]: strtotime() still leaks memory
ID: 47285
Comment by: scott at crisscott dot com
Reported By: danger at FreeBSD dot org
Status: Assigned
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 5.2.8
Assigned To: derick
New Comment:
Reproduced on RHEL 4 (PHP built from source not RPM)
PHP 5.2.9 (cli) (built: May 1 2009 13:47:24)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Zend Debugger v5.2.14, Copyright (c) 1999-2008, by Zend
Technologies
Applying the patch from oliver at realtsp dot com slowed down the leak,
but did not stop it entirely.
Previous Comments:
[2009-07-07 10:47:47] oliver at realtsp dot com
I can confirm that we can reproduce this bug on FreeBSD 7.2 with
php5.2.10 and that the patch provided by bloudon at townnews dot com
does stop the leak.
I had to manually apply the patch because copying out of the html
rarely works, so I have prepared a "clean" version which applies without
errors to the current FreeBSD 7.2 port of php5. Here it is:
http://www.realtsp.com/public/patch-ext_date_php_date.c
Oliver
[2009-04-15 07:55:33] kimc at operamail dot com
You dont see the memory leak with PHP's memory_get_usage(), and the
process wont get killed by PHP's general memory_limit.
PHP doesnt see the memory use, but the kernel does and after some time
the kernel will kill it due to ulimit or out of memory.
[2009-04-06 10:01:32] davide dot ferrari at atrapalo dot com
Sorry for being dumb but does this leak affect memory_limit ? I mean, I
can reproduce the memleak with Linux and PHP 5.2.9 but
memory_get_usage() output seems constant, although memory occupied by
the process itself is getting biger every second, so there's clearly a
memleak.
I ask this because I don't know if there is an actual relationship
between this bug and some strange cronjob deaths I'm experiencing with
PHP 5.2.9.
TIA
[2009-03-30 12:25:48] kimc at operamail dot com
The last patch fixes the memory leak for me.
[2009-03-11 15:36:05] bloudon at townnews dot com
Leak also observed in 5.2.8 and 5.2.9 on Linux.
This patch (against 5.2.9) is working out for us so far in our dev
environment:
--- ext/date/php_date.orig.c2009-03-11 10:07:36.0 -0500
+++ ext/date/php_date.c 2009-03-11 10:12:40.0 -0500
@@ -1108,7 +1108,7 @@
long preset_ts, ts;
timelib_time *t, *now;
- timelib_tzinfo *tzi;
+ timelib_tzinfo *tzi, *old_tzi;
tzi = get_timezone_info(TSRMLS_C);
@@ -1119,10 +1119,14 @@
initial_ts = emalloc(25);
snprintf(initial_ts, 24, "@%ld UTC", preset_ts);
t = timelib_strtotime(initial_ts, strlen(initial_ts), NULL,
DATE_TIMEZONEDB); /* we ignore the error here, as this should never fail
*/
+ old_tzi = t->tz_info;
timelib_update_ts(t, tzi);
now->tz_info = tzi;
now->zone_type = TIMELIB_ZONETYPE_ID;
timelib_unixtime2local(now, t->sse);
+ if ( old_tzi ) {
+ timelib_tzinfo_dtor(old_tzi);
+ }
timelib_time_dtor(t);
efree(initial_ts);
} else if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s|l",
×, &time_len, &preset_ts) != FAILURE) {
@@ -1141,6 +1145,7 @@
}
t = timelib_strtotime(times, time_len, &error, DATE_TIMEZONEDB);
+ old_tzi = t->tz_info;
error1 = error->error_count;
timelib_error_container_dtor(error);
timelib_fill_holes(t, now, TIMELIB_NO_CLONE);
@@ -1148,6 +1153,9 @@
ts = timelib_date_to_int(t, &error2);
timelib_time_dtor(now);
+ if ( old_tzi ) {
+ timelib_tzinfo_dtor(old_tzi);
+ }
timelib_time_dtor(t);
if (error1 || error2) {
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/47285
--
Edit this bug report at http://bugs.php.net/?id=47285&edit=1
#49342 [NEW]: gnu_cmp doesn't work with decimal strings
From: scott at connerly dot net
Operating system: Linux
PHP version: 5.2.10
PHP Bug Type: GNU MP related
Bug description: gnu_cmp doesn't work with decimal strings
Description:
gnu_cmp doesn't work with decimal strings
Reproduce code:
---
---
>From manual page: function.gmp-cmp
---
$integers = gmp_cmp('2','5');
$floats = gmp_cmp('2.5','5');
var_dump($integers,$floats);
Expected result:
both should return -1
Actual result:
--
int(-1)
bool(false)
--
Edit bug report at http://bugs.php.net/?id=49342&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49342&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49342&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49342&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49342&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49342&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49342&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49342&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49342&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49342&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49342&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49342&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49342&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49342&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49342&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49342&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49342&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49342&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49342&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49342&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49342&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49342&r=mysqlcfg
#43189 [Com]: Fails to link iconv
ID: 43189 Comment by: scott at mydogateit dot com Reported By: meh at mailinator dot com Status: Feedback Bug Type: ICONV related Operating System: Mac OS X 10.5 PHP Version: 5.3CVS-2007-11-04 (snap) New Comment: This is an issue with Leopards iconv.h file (/usr/include/iconv.h). Try this... $ sudo mv /usr/include/iconv.h /usr/include/iconv.h.leo_orig $ sudo ln -s /sw/include/iconv.h /usr/include/iconv.h and try make again. (I did this using iconv from MacPorts, but I assume the find dist will work just as well). Previous Comments: [2007-11-11 18:53:02] [EMAIL PROTECTED] How many iconv.h files do you have in your system? (search for *iconv*.h :) [2007-11-04 23:33:10] meh at mailinator dot com Description: ld: warning, duplicate dylib /sw/lib/libssl.0.9.7.dylib ld: warning, duplicate dylib /sw/lib/libcrypto.0.9.7.dylib Undefined symbols: "_iconv_close", referenced from: _php_iconv_string in iconv.o _php_iconv_string in iconv.o __php_iconv_strlen in iconv.o __php_iconv_strpos in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_substr in iconv.o _php_iconv_stream_filter_dtor in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o "_iconv_open", referenced from: _php_iconv_string in iconv.o __php_iconv_strlen in iconv.o __php_iconv_strpos in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _php_iconv_stream_filter_factory_create in iconv.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Reproduce code: --- ./configure --with-apxs2 --with-xsl --with-mysql=/sw --with-pdo --with-pdo-mysql=/sw --with-zlib --without-pear --with-iconv=/sw I've tried --with-iconv and --with-iconv=/usr as well. Configure succeedes with any of these, but linker fails every time. I have Fink installed: /sw/lib/libiconv.2.4.0.dylib /sw/lib/libiconv.2.dylib /sw/lib/libiconv.dylib /sw/lib/libiconv.la Expected result: Either configure should fail or linker should succeed. Actual result: -- Missing symbols... -- Edit this bug report at http://bugs.php.net/?id=43189&edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: scott at atomicrocketturtle dot com Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Testing this patch against 5.2.5, ioncube-loader and zend-optimizer will cause segmentation faults. Similar result with eaccelerator, which was resolved with a rebuild. Previous Comments: [2008-01-17 16:52:48] d at tpyo dot net Thanks Manuel. Patch works perfectly. But I agree, it is a fairly serious issue that undoubtedly affects a lot of users. [2008-01-17 13:40:04] manuel at mausz dot at Err... php as apache module... :) [2008-01-17 13:35:48] manuel at mausz dot at Can some dev please take a look at this (or the patch)? This is a serious issue for all users running apache as module and mixing php_admin_value and php_value. It also looks like this is the same as: http://bugs.php.net/bug.php?id=43842 http://bugs.php.net/bug.php?id=43755 http://bugs.php.net/bug.php?id=43207 [2008-01-13 03:14:53] root at net1 dot cc I've been using the patched PHP for several hours now, and - confirmed - it's working flawless! This patch really fixes the issue! Thanks once again, Manuel! For FreeBSD users, I've uploaded a modified patch file for deployment with the ports system, for ease of use, and instructions here: http://mirror.net1.cc/projects/php-bug43677-patch/ [2008-01-12 21:19:29] root at net1 dot cc I'm gonna test Manuel's patch (thanks!) and report back later if it does fix the problems observed. 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677&edit=1
#43999 [Com]: Date is not 'next month' as expected
ID: 43999
Comment by: scott at slerman dot net
Reported By: gavinp at tbs dot uk dot com
Status: Open
Bug Type: Date/time related
Operating System: Debian
PHP Version: 4.4.8
New Comment:
Today is January 31st.
Adding 1 to the month would produce February 31st.
February 31st does not exist, so it is converted to March 2nd (or March
3rd during non-leap years).
The GNU date format documentation
(http://www.gnu.org/software/tar/manual/html_node/tar_113.html) gives
you the solution of getting the next month after the 15th of the current
month. You can do this in PHP with the second parameter to strtotime:
strtotime('next month', mktime(0, 0, 0, idate('m'), 15))
Previous Comments:
[2008-01-31 16:20:48] gavinp at tbs dot uk dot com
Description:
Hi [EMAIL PROTECTED],
I have not posted this twice,(however because you locked the last bug I
now have to and in case another user has ... your search system will
need some work then. I could not find a bug describing the same problem.
Please direct me to the correct place that is an open bug and I will
happy tag this onto the end of it.
strtotime('next month', $basedate); where $basedate = today.
Should output the next month. The next month from today is Feb. Simple.
That is the 'expected behaviour'.
That's like saying 2+2 = 4 except on Fridays when it = 5, and then
saying because it's always been like this then it's 'Expected.'
If you are going to refer me to the documentation, please direct me to
the documentations excact location where it says 'next month on the last
day of the month should be two months instead of one.' I can not find
this part in the documentation anywhere also.
However I would love to eat humble pie so please do show me.
Reproduce code:
---
$basedate = time();
$date1 = strtotime('next month', $basedate);
$date2 = strtotime('+1 month', $basedate);
$date3 = strtotime('first month', $basedate);
$date4 = mktime(0, 0, 0, date("m")+1, date("d"), date("Y"));
$format1 = date('F', $date1);
$format2 = date('F', $date2);
$format3 = date('F', $date3);
$format4 = date('F', $date4);
echo $format1;
echo $format2;
echo $format3;
echo $format4;
Expected result:
February
February
February
February
Actual result:
--
March
March
March
March
--
Edit this bug report at http://bugs.php.net/?id=43999&edit=1
#47724 [NEW]: Reproducable segmenation fault using symfony and doctrine
From: scott at danielfamily dot com Operating system: Centos 5.2 PHP version: 5.2.9 PHP Bug Type: Reproducible crash Bug description: Reproducable segmenation fault using symfony and doctrine Description: Sorry for the longer than asked for initial post, but I've spent many many hours profiling this problem to make this bug report. Our project uses symfony framework with the doctrine database abstraction. We have had a number of crash sequences that are VERY hard to simplify and usually crash intermittently. I have isolated an instance that always crashes on our linux systems and usually crashes under windows. If I change the order of code or add code, the problem may disappear temporarily only to resurface later after additional code modification have been made. I've done this several times, but have no confidence in deploying this kind of fix in a final released product. After many many hours, I've built a vmware appliance with Centos 5.2 and the LAMP stack installed. It was built using the latest Apache and PHP source. It is built using the enable-debug switch and I've gotten a stack trace (included below). Running the vmware appliance and hitting a single url running from it's server causes the error every time. If someone is assigned to this problem and communicates with me, I can send them the vmware appliance to run under windows. It is already setup with the software stack to reproduce and debug the problem. It should save many hours of configuration (at least it would for me). I believe that it is very possible this related to Bug #40479. Unfortunately, I have some experience with this problem with another project and believe it is a very serious unresolved issue. Actual result: -- [r...@localhost bin]# gdb /usr/local/apache2/bin/httpd GNU gdb Red Hat Linux (6.5-37.el5_2.2rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -X Starting program: /usr/local/apache2/bin/httpd -X [Thread debugging using libthread_db enabled] [New Thread -1208129792 (LWP 22085)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208129792 (LWP 22085)] 0x01146ab9 in zend_if_strlen (ht=1, return_value=0xa682b40, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /root/Desktop/php-5.2.9/Zend/zend_builtin_functions.c:286 286 RETVAL_LONG(Z_STRLEN_PP(str)); (gdb) bt #0 0x01146ab9 in zend_if_strlen (ht=1, return_value=0xa682b40, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /root/Desktop/php-5.2.9/Zend/zend_builtin_functions.c:286 #1 0x0115cc34 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf826c24) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:200 #2 0x01162706 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbf826c24) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:1729 #3 0x0115c795 in execute (op_array=0xa6715f8) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92 #4 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf826de4) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234 #5 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf826de4) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322 #6 0x0115c795 in execute (op_array=0xb7d92f88) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92 #7 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf8270b4) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234 #8 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf8270b4) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322 #9 0x0115c795 in execute (op_array=0xa47e408) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92 #10 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf827434) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234 #11 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf827434) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322 #12 0x0115c795 in execute (op_array=0xb7d8bd58) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92 #13 0x0119df6a in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (execute_data=0xbf827734) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:20117 #14 0x0115c795 in execute (op_array=0xb7d7d784) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92 #15 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf827e64) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234 #16 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf827e
#47724 [Com]: Reproducable segmenation fault using symfony and doctrine
ID: 47724 Comment by: scott at danielfamily dot com Reported By: scott at danielfamily dot com Status: Feedback Bug Type: Reproducible crash Operating System: Centos 5.2 PHP Version: 5.2.9 New Comment: I understand and appreciate the purpose of the canned response, but please reread my original bug submission. What you are asking for is impossible. Duplication of the problem REQUIRES a very complex sequence of PHP code. If I change a single line of PHP code, the problem is likely to disappear. Please take me up on my offer to transfer the VMWARE appliance that clearly and consistently duplicates the problem. Previous Comments: [2009-03-21 23:03:13] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2009-03-20 02:29:47] scott at danielfamily dot com Description: Sorry for the longer than asked for initial post, but I've spent many many hours profiling this problem to make this bug report. Our project uses symfony framework with the doctrine database abstraction. We have had a number of crash sequences that are VERY hard to simplify and usually crash intermittently. I have isolated an instance that always crashes on our linux systems and usually crashes under windows. If I change the order of code or add code, the problem may disappear temporarily only to resurface later after additional code modification have been made. I've done this several times, but have no confidence in deploying this kind of fix in a final released product. After many many hours, I've built a vmware appliance with Centos 5.2 and the LAMP stack installed. It was built using the latest Apache and PHP source. It is built using the enable-debug switch and I've gotten a stack trace (included below). Running the vmware appliance and hitting a single url running from it's server causes the error every time. If someone is assigned to this problem and communicates with me, I can send them the vmware appliance to run under windows. It is already setup with the software stack to reproduce and debug the problem. It should save many hours of configuration (at least it would for me). I believe that it is very possible this related to Bug #40479. Unfortunately, I have some experience with this problem with another project and believe it is a very serious unresolved issue. Actual result: -- [r...@localhost bin]# gdb /usr/local/apache2/bin/httpd GNU gdb Red Hat Linux (6.5-37.el5_2.2rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -X Starting program: /usr/local/apache2/bin/httpd -X [Thread debugging using libthread_db enabled] [New Thread -1208129792 (LWP 22085)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208129792 (LWP 22085)] 0x01146ab9 in zend_if_strlen (ht=1, return_value=0xa682b40, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /root/Desktop/php-5.2.9/Zend/zend_builtin_functions.c:286 286 RETVAL_LONG(Z_STRLEN_PP(str)); (gdb) bt #0 0x01146ab9 in zend_if_strlen (ht=1, return_value=0xa682b40, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /root/Desktop/php-5.2.9/Zend/zend_builtin_functions.c:286 #1 0x0115cc34 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf826c24) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:200 #2 0x01162706 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbf826c24) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:1729 #3 0x0115c795 in execute (op_array=0xa6715f8) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92 #4 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf826de4) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234 #5 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf826de4) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322 #6 0x0115c795 in execute (op_array=0xb7d92f88) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#47724 [Com]: Reproducable segmenation fault using symfony and doctrine
ID: 47724 Comment by: scott at danielfamily dot com Reported By: scott at danielfamily dot com Status: Feedback Bug Type: Reproducible crash Operating System: Centos 5.2 PHP Version: 5.2.9 New Comment: I believe very strongly that this is a bug in PHP, not in doctrine or symfony. Modifying seemingly random and benign pieces of code, changing the order of code, or collapsing classes usually results in the problem disappearing. This makes it impossible to comply with your request for a simple script. This is VERY likely to be a corrupt heap situation that only manifests itself when the planets are aligned correctly. I have gotten those planets to align consistently and the crash always happens. I'm willing to do anything reasonable to get someone to look at this problem. Building the VMWARE appliance seemed like the best approach as it will allow someone familiar with the internals of PHP to download the appliance and duplicate the problem in minutes. I've already posted this on the symfony forums and gotten sympathy, but no substitive suggestions. I'll try posting it as a symfony bug and see what happens. Previous Comments: [2009-03-22 18:00:09] paj...@php.net If you are not able to create a self contained script to reproduce the problem, report the bug to symfony or doctrine developers and ask them to analyze it. We can't use these tools as a base to debug this issue. Thanks for your understanding. [2009-03-22 17:38:55] scott at danielfamily dot com I understand and appreciate the purpose of the canned response, but please reread my original bug submission. What you are asking for is impossible. Duplication of the problem REQUIRES a very complex sequence of PHP code. If I change a single line of PHP code, the problem is likely to disappear. Please take me up on my offer to transfer the VMWARE appliance that clearly and consistently duplicates the problem. [2009-03-21 23:03:13] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2009-03-20 02:29:47] scott at danielfamily dot com Description: Sorry for the longer than asked for initial post, but I've spent many many hours profiling this problem to make this bug report. Our project uses symfony framework with the doctrine database abstraction. We have had a number of crash sequences that are VERY hard to simplify and usually crash intermittently. I have isolated an instance that always crashes on our linux systems and usually crashes under windows. If I change the order of code or add code, the problem may disappear temporarily only to resurface later after additional code modification have been made. I've done this several times, but have no confidence in deploying this kind of fix in a final released product. After many many hours, I've built a vmware appliance with Centos 5.2 and the LAMP stack installed. It was built using the latest Apache and PHP source. It is built using the enable-debug switch and I've gotten a stack trace (included below). Running the vmware appliance and hitting a single url running from it's server causes the error every time. If someone is assigned to this problem and communicates with me, I can send them the vmware appliance to run under windows. It is already setup with the software stack to reproduce and debug the problem. It should save many hours of configuration (at least it would for me). I believe that it is very possible this related to Bug #40479. Unfortunately, I have some experience with this problem with another project and believe it is a very serious unresolved issue. Actual result: -- [r...@localhost bin]# gdb /usr/local/apache2/bin/httpd GNU gdb Red Hat Linux (6.5-37.el5_2.2rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1&quo
#47724 [Com]: Reproducable segmenation fault using symfony and doctrine
ID: 47724 Comment by: scott at danielfamily dot com Reported By: scott at danielfamily dot com Status: Feedback Bug Type: Reproducible crash Operating System: Centos 5.2 PHP Version: 5.2.9 New Comment: Thanks for the quick response. I understand that infinite recursion is a sure way to crash PHP. I've fixed those problems a bunch of times over the years. However, those bugs tend to manifest themselves in a consistent way. In this situation, removing code that is not even executed can cause the problem to disappear. Adding a few random instructions can also make the problem disappear. This would not happen if there was a recursion problem. This really feels like a heap corruption or some other wickedness in code A is causing a crash in code B where A and B are basically unrelated. These are REALLY REALLY hard to find and fix so I am sympathetic to your reluctance to dive in, but I believe this is a real problem. I've posted a ticket with the symfony team and hope that someone will respond (http://trac.symfony-project.org/ticket/6152), but as I say in that ticket, I believe the problem is with PHP, not symfony or doctrine. The symfony/doctrine stack simply represents the proper level of complexity to cause the PHP failure. Part of my persistence is that I believe it is very possible that this is related to Bug #40479 (http://bugs.php.net/bug.php?id=40479). I have some very negative experience with this problem on another project where my team spent nearly a man-month trying to find a random heap corruption problem. We ended up abandoning the Smarty based project and using Symfony with good results. In that case the problem was consistent, but intermittent. In this case, the problem is consistent and reproducible. Previous Comments: [2009-03-23 18:08:14] ras...@php.net Are you sure this isn't a circular reference causing some sort of infinite recursion? There is no protection against infinite recursion crashes in 5.2.x [2009-03-23 17:56:13] scott at danielfamily dot com I believe very strongly that this is a bug in PHP, not in doctrine or symfony. Modifying seemingly random and benign pieces of code, changing the order of code, or collapsing classes usually results in the problem disappearing. This makes it impossible to comply with your request for a simple script. This is VERY likely to be a corrupt heap situation that only manifests itself when the planets are aligned correctly. I have gotten those planets to align consistently and the crash always happens. I'm willing to do anything reasonable to get someone to look at this problem. Building the VMWARE appliance seemed like the best approach as it will allow someone familiar with the internals of PHP to download the appliance and duplicate the problem in minutes. I've already posted this on the symfony forums and gotten sympathy, but no substitive suggestions. I'll try posting it as a symfony bug and see what happens. [2009-03-22 18:00:09] paj...@php.net If you are not able to create a self contained script to reproduce the problem, report the bug to symfony or doctrine developers and ask them to analyze it. We can't use these tools as a base to debug this issue. Thanks for your understanding. ---- [2009-03-22 17:38:55] scott at danielfamily dot com I understand and appreciate the purpose of the canned response, but please reread my original bug submission. What you are asking for is impossible. Duplication of the problem REQUIRES a very complex sequence of PHP code. If I change a single line of PHP code, the problem is likely to disappear. Please take me up on my offer to transfer the VMWARE appliance that clearly and consistently duplicates the problem. [2009-03-21 23:03:13] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47724 -- Edit this bug report at http://bugs.php.net/?id=47724&edit=1
#47724 [Com]: Reproducable segmenation fault using symfony and doctrine
ID: 47724 Comment by: scott at danielfamily dot com Reported By: scott at danielfamily dot com Status: No Feedback Bug Type: Reproducible crash Operating System: Centos 5.2 PHP Version: 5.2.9 New Comment: Scott MacVicar from the PHP team send me a note saying he would look at the bug. I uploaded the VMWARE appliance and send him the information, but have not heard back after some days. Still hoping for some love. Previous Comments: [2009-03-31 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-03-23 19:14:17] scott at danielfamily dot com Thanks for the quick response. I understand that infinite recursion is a sure way to crash PHP. I've fixed those problems a bunch of times over the years. However, those bugs tend to manifest themselves in a consistent way. In this situation, removing code that is not even executed can cause the problem to disappear. Adding a few random instructions can also make the problem disappear. This would not happen if there was a recursion problem. This really feels like a heap corruption or some other wickedness in code A is causing a crash in code B where A and B are basically unrelated. These are REALLY REALLY hard to find and fix so I am sympathetic to your reluctance to dive in, but I believe this is a real problem. I've posted a ticket with the symfony team and hope that someone will respond (http://trac.symfony-project.org/ticket/6152), but as I say in that ticket, I believe the problem is with PHP, not symfony or doctrine. The symfony/doctrine stack simply represents the proper level of complexity to cause the PHP failure. Part of my persistence is that I believe it is very possible that this is related to Bug #40479 (http://bugs.php.net/bug.php?id=40479). I have some very negative experience with this problem on another project where my team spent nearly a man-month trying to find a random heap corruption problem. We ended up abandoning the Smarty based project and using Symfony with good results. In that case the problem was consistent, but intermittent. In this case, the problem is consistent and reproducible. [2009-03-23 18:08:14] ras...@php.net Are you sure this isn't a circular reference causing some sort of infinite recursion? There is no protection against infinite recursion crashes in 5.2.x ---- [2009-03-23 17:56:13] scott at danielfamily dot com I believe very strongly that this is a bug in PHP, not in doctrine or symfony. Modifying seemingly random and benign pieces of code, changing the order of code, or collapsing classes usually results in the problem disappearing. This makes it impossible to comply with your request for a simple script. This is VERY likely to be a corrupt heap situation that only manifests itself when the planets are aligned correctly. I have gotten those planets to align consistently and the crash always happens. I'm willing to do anything reasonable to get someone to look at this problem. Building the VMWARE appliance seemed like the best approach as it will allow someone familiar with the internals of PHP to download the appliance and duplicate the problem in minutes. I've already posted this on the symfony forums and gotten sympathy, but no substitive suggestions. I'll try posting it as a symfony bug and see what happens. [2009-03-22 18:00:09] paj...@php.net If you are not able to create a self contained script to reproduce the problem, report the bug to symfony or doctrine developers and ask them to analyze it. We can't use these tools as a base to debug this issue. Thanks for your understanding. 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/47724 -- Edit this bug report at http://bugs.php.net/?id=47724&edit=1
#47724 [Com]: Reproducable segmenation fault using symfony and doctrine
ID: 47724 Comment by: scott at danielfamily dot com Reported By: scott at danielfamily dot com Status: No Feedback Bug Type: Reproducible crash Operating System: Centos 5.2 PHP Version: 5.2.9 New Comment: We have since found another consistent failure case in a thread of code that is unrelated to the one reported here. It is another case where adding a single instruction makes the fault disappear. Previous Comments: [2009-03-31 12:10:48] peter at f-is dot eu Scott, thanks for your work at the VMWARE image, and Scott MacVicar for looking into it. I really hope this annoying bug finally get's fixed. I've been playing with Duma, Valgrind and GDB for a few days, but my knowledge about these tools, c programming, or the internals of PHP seem insufficient. >From what i can tell, this is a reference counting problem. Some object has 3 references, and than some time later the some memory location contains a String, with 1 reference, which gets dereferenced and de-allocated. During php shutdown, the original object is being read, and because the memory is 'gone' it segfaults. The String that seems to overwrite the object is being provided by the __toString function of the original object. So i guess something goes wrong there. I can't stress enough that my experience with C is extremely limited, so the above may be completely wrong :P. There is also no way for me to be sure that this is the same bug that Scott has, but the symptoms are the same. This is the information valgrind spits out about the crash is the following. Note that this only happens in crashing pages, or pages that sometimes crash, depending on input: ==29860== Invalid read of size 4 ==29860==at 0x63EBB7: _zval_ptr_dtor (zend_execute_API.c:410) ==29860==by 0x64F079: _zval_ptr_dtor_wrapper (zend_variables.c:177) ==29860==by 0x65F9C8: zend_hash_destroy (zend_hash.c:526) ==29860==by 0x64EC8A: _zval_dtor_func (zend_variables.c:45) ==29860==by 0x63E978: _zval_dtor (zend_variables.h:35) ==29860==by 0x63EC31: _zval_ptr_dtor (zend_execute_API.c:414) ==29860==by 0x64F079: _zval_ptr_dtor_wrapper (zend_variables.c:177) ==29860==by 0x65F9C8: zend_hash_destroy (zend_hash.c:526) ==29860==by 0x675161: zend_object_std_dtor (zend_objects.c:45) ==29860==by 0x675600: zend_objects_free_object_storage (zend_objects.c:122) ==29860==by 0x679E67: zend_objects_store_del_ref_by_handle (zend_objects_API.c:211) ==29860==by 0x679C45: zend_objects_store_del_ref (zend_objects_API.c:169) ==29860== Address 0xBF348B8 is 16 bytes inside a block of size 24 free'd ==29860==at 0x4A0541E: free (vg_replace_malloc.c:233) ==29860==by 0x62E4EB: _efree (zend_alloc.c:2303) ==29860==by 0x63ECD9: safe_free_zval_ptr_rel (zend_execute.h:70) ==29860==by 0x63EC51: _zval_ptr_dtor (zend_execute_API.c:415) ==29860==by 0x67D57C: zend_ptr_stack_clear_multiple (zend_execute.h:155) ==29860==by 0x67CE1E: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:307) ==29860==by 0x683160: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1729) ==29860==by 0x67C11B: execute (zend_vm_execute.h:92) ==29860==by 0x6951FA: ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER (zend_vm_execute.h:7811) ==29860==by 0x67C11B: execute (zend_vm_execute.h:92) ==29860==by 0x6517CC: zend_execute_scripts (zend.c:1134) ==29860==by 0x5F108F: php_execute_script (main.c:2023) This is the output of php that I got by enabling debugging options. They concern the same memory region as the above: Reducing refcount for bf348a8 (feff5738) type 5: 16->15 Reducing refcount for bf348a8 (feff5ba8) type 5: 15->14 Reducing refcount for bf348a8 (feff5cf0) type 5: 14->13 Reducing refcount for bf348a8 (bf45c08) type 5: 13->12 Reducing refcount for bf348a8 (bf45cc0) type 5: 12->11 Reducing refcount for bf348a8 (bf351a8) type 5: 11->10 Reducing refcount for bf348a8 (a0a518) type 5: 10->9 Reducing refcount for bf348a8 (feff84a8) type 5: 10->9 Reducing refcount for bf348a8 (bf350a8) type 5: 9->8 Reducing refcount for bf348a8 (a0a518) type 5: 8->7 Reducing refcount for bf348a8 (feff8d28) type 5: 7->6 Reducing refcount for bf348a8 (bf34b70) type 5: 6->5 Reducing refcount for bf348a8 (a0a518) type 5: 5->4 Reducing refcount for bf348a8 (a0a518) type 5: 4->3 Reducing refcount for bf348a8 (feffa048) type 6: 1->0 Destroying bf348a8 of type 6 Reducing refcount for bf348a8 (bf44e38) type 6: 0->-1 Reducing refcount for bf348a8 (bf35f70) type 6: -1->-2 ---- [2009-03-31 03:21:39] scott at danielfamily dot com Scott MacVicar from the PHP team send me a note saying he would look at the bug. I uploaded the VMWARE appliance and send him
Bug #49349 [Com]: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors)
Edit report at http://bugs.php.net/bug.php?id=49349&edit=1
ID: 49349
Comment by: scott at etw dot ca
Reported by: raulsalitrero at gmail dot com
Summary: gettext behaves differently in php 5.3.0 (5.2.x
ignored setlocale errors)
Status: Assigned
Type: Bug
Package: Gettext related
Operating System: win32 only - windows xp sp3
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Is there a release date for 5.3.3? Spent the last few months building a
project in 5.3 and my final steps was to add language support which i
cant do with gettext due to this bug, and to revert to 5.2x would
require other major code changes
Previous Comments:
[2010-05-05 12:12:39] sjake_it at hotmail dot com
Same problem here with Windows Server 2003 SP2.
This bug prevents me from upgrading to php 5.3.x
It's been 8 months now so I hope this bug will be fixed quickly now.
[2010-04-19 02:00:08] egorinsk at gmail dot com
Hi, the same problem here with Windows XP SP2 and PHP 5.3.1 . In PHP
5.2, setlocale() call failed, but gettext() used information from LANG,
LC_ALL and LANGUAGE variables. That was good, because I could use
putenv() to change gettext() language on Windows and setlocale() on
Linux.
But now setlocale() on Windows fails, and gettext() always uses system
locale, and messages are not translated. Actually, I don't need locales,
they only bring problems, I'd prefer to always set it to POSIX locale to
get consistent behaviour independent from server setup, but gettext()
requires to use it :(
[2010-04-14 01:17:18] jorgecanta47 at hotmail dot com
Same problem here with Windows Vista Home Premium, PHP 5.3.1 in XAMPP.
Is there any workaround yet?
Thanks
[2010-04-05 17:19:37] euridica at narod dot ru
Still same in 5.3.2. Translation is done only to default system locale.
[2009-12-18 15:44:06] bengibollen at hotmail dot com
I have got this problem as well. I'd like to add that the system default
language/locale gets translated. But no other languages.
Example:
I have windows vista, English version, and the system default locale is
set to Swedish. The strings that are supposed to be translated are all
written in English; _("Hello World!").
I have made three translations:
./se/LC_MESSAGES/default.mo
./de/LC_MESSAGES/default.mo
./en/LC_MESSAGES/default.mo /*nonsense words/phrases only for testing*/
I always get the Swedish translation no matter what configurations* I
try. If I rename the Swedish translation file I get no translation at
all, only the default string.
* I've tried all kind of parameters for the following:
setlocale(LC_ALL, ...);
putenv("LANGUAGE=...");
putenv("LANG=...");putenv("LC_ALL=...");
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/bug.php?id=49349
--
Edit this bug report at http://bugs.php.net/bug.php?id=49349&edit=1
Req #32746 [Bgs]: PHP command line option doesn't have verbose/debug output.
Edit report at http://bugs.php.net/bug.php?id=32746&edit=1 ID: 32746 User updated by:scott at abcoa dot com Reported by:scott at abcoa dot com Summary:PHP command line option doesn't have verbose/debug output. Status: Bogus Type: Feature/Change Request Package:*General Issues Operating System: AIX or any Unix(s)/Linux(s) PHP Version:4.3.10 Block user comment: N Private report: N New Comment: No, that's not how it works... If you have Bash shell environment or Korn shell environment, you typed the "-v" option and you get the verbose output. PHP doesn't do that which is the point here. Previous Comments: [2010-12-22 03:38:20] johan...@php.net Use a proper debugger like Xdebug. ---- [2005-04-18 17:50:38] scott at abcoa dot com Description: This is a request for enhancement for the command line option. I couldn't find an earlier bug report via bug search, so forgive me if this is a duplicate or something. As I looked up at http://us2.php.net/features.commandline and it doesn't have the option for debugging or verbose output via the shell environment. With most shell environment for bash, ksh, etc., I can do the -x or maybe -d option to see the output via the O/S and I/O so I can see what is goign on behind hte scene when I have problem with why am I not getting response. A line by line trace is useful also... Yes, I can do with exec() or system() but I had cURL compiled with PHP and other stuffs, so it get more complicated than it look. Thanks... Reproduce code: --- #!/usr/local/bin/php Expected result: Something like this or close enough, whatever make it possible for us to read the O/S output or I/O output... --snip-- -=[/usr/local/bin]==>sh -x ./inquiry_pull_test.sh + 0< l + = ./inquiry_pull_test.sh[3]: =: not found. + Testing Inquiry Send... * About to connect() to ec.equifax.com:443 * Connected to ec.equifax.com ((nil)) port 443 * SSL connection using RC4-MD5 * Server certificate: *subject: /C=US/ST=Georgia/L=Alpharetta/O=Equifax Inc/CN=ec.equifax.com *start date: 2004-07-01 02:57:28 GMT *expire date: 2005-07-01 02:57:28 GMT *common name: ec.equifax.com (matched) *issuer: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Server CA/email=server-ce...@thawte.com > POST /servlet/stspost HTTP/1.1 Authorization: Basic blah blah OpenSSL/0.9.6g Host: ec.equifax.com Pragma: no-cache Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Content-Length: 396 Content-Type: application/x-www-form-urlencoded site_id=0&service_name=test&efx_request=DIAL blah blah --snip-- -- Edit this bug report at http://bugs.php.net/bug.php?id=32746&edit=1
#35096 [Com]: still trouble with mod_rewrite/apache2
ID: 35096
Comment by: scott at whitetigerphotography dot com
Reported By: rob at burningsoda dot com
Status: Feedback
Bug Type: Apache2 related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-11-04) (snap)
New Comment:
Having an identical problem on FreeBSD 4.11-release-p13 with the latest
version from ports (PHP 4.4.1 (cli) (built: Nov 6 2005 23:03:29))
(patched with the original CVS fix for this bug but that doesn't fix
it)
This too happens for any rewrite rule used for PHP. I use rewrite rules
for almost all of my production sites and they have all stopped working,
except for one which uses a CGI script instead. Affects software like
Mambo (Joomla) with SEF enabled and Gallery
Examples for rewrite reproduce code (from gallery):
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.\?/]+)/([0-9]+)$
/view_photo.php?set_albumName=$1&index=$2 [QSA]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.\?/]+)/([A-Za-z_0-9\-]+)$
/view_photo.php?set_albumName=$1&id=$2 [QSA]
Result:
Blank pages most of the time but in the case of gallery... occasional
parts of pages for some reason. No errors found in PHP or Apache logs
Previous Comments:
[2005-11-07 07:30:34] tmelzer at tomesoft dot de
On SuSE 9.1
with apache 2.0.55
and php-4.4.x-dev with shared modules in this order
- cryptopp
- bz2
- imap
- exif
- mime_magic
- dba
- zlib
- gd
- sockets
- curl
- iconv
- xslt
- mysql
- interbase
- session
.htaccess
RewriteEngine On
RewriteBase /shop/
RewriteRule ^irw_(.*)\.html index.php?param=$1
[2005-11-06 22:41:36] free4cd at yahoo dot de
Same Problem with PHP 4.4.1 and 5.1 snapshots.
If rewrite is enabled you get a blank page. No error in log file or
else.
Problem with Joomla and vBulletin/vBSEO if rewrite engine is turned on.
If rewrite is disabled all works fine.
My .htaccess for Joomla:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php
[2005-11-06 19:47:49] remko at elvandar dot org
I had similiar problems with apache2+mod_rewrite and php
4.4.1. All sites that made use of mod_rewrite broke and gave
a white page (nothing in the error log though), all other
sites that use php but not mod_rewrite were working
perfectly.
my .htaccess:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php
[2005-11-06 16:29:08] brian dot white at foxfire74 dot com
I have a WordPress powerered blog and get it for ANY rewrite rule.
Here is a stripped down version of my .htaccess:
---
# BEGIN WordPress
RewriteEngine On
RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [S=75]
RewriteRule ^search/(.+)/?$ /blog/index.php?s=$1 [QSA,L]
RewriteRule ^category/(.+)/?$ /blog/index.php?category_name=$1 [QSA,L]
RewriteRule ^author/([^/]+)/?$ /blog/index.php?author_name=$1 [QSA,L]
RewriteRule ^([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/?$
/blog/index.php?year=$1&monthnum=$2&day=$3 [QSA,L]
RewriteRule ^([0-9]{4})/([0-9]{1,2})/?$
/blog/index.php?year=$1&monthnum=$2 [QSA,L]
RewriteRule ^([0-9]{4})/?$ /blog/index.php?year=$1 [QSA,L]
RewriteRule ^([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/([^/]+)(/[0-9]+)?/?$
/blog/index.php?year=$1&monthnum=$2&day=$3&name=$4&page=$5 [QSA,L]
# END WordPress
Here what was requested in the browser:
--
http://.../blog/2005/10/31/happy-halloween/
Here is what shows up in the logs:
-
[Mon Oct 31 23:25:42 2005] [error] PHP Warning:
main(./wp-blog-header.php): failed to open stream: No such file or
directory in C:\\...\\wordpress\\index.php on line 4
[Mon Oct 31 23:25:42 2005] [error] PHP Fatal error: main(): Failed
opening required './wp-blog-header.php'
(include_path='.;c:\\php4\\pear') in C:\\...\\wordpress\\index.php on
line 4
Result:
--
The browser displays a blank page since PHP blows up.
Using:
-
PHP 4.4.1
Windows XP SP2
Apache/2.0.55 (Win32) PHP/4.4.1
php4apache2.dll
[2005-11-06 15:52:48] [EMAIL PROTECTED]
Exactly how can we reproduce this? It works just fine for me when I
have this .htaccess file:
RewriteEngine on
RewriteRule ^(.+)/$ index.php?myarg=$1 [L]
So what else do we need?
The remainder of the comments for this report are too long. To view
the rest o
#35096 [Com]: using mod_rewrite with apache2 crashes
ID: 35096 Comment by: scott at whitetigerphotography dot com Reported By: rob at burningsoda dot com Status: Feedback Bug Type: Apache2 related Operating System: * PHP Version: 5CVS, 4CVS (2005-11-04) (snap) New Comment: PHP isn't actually crashing with this bug. The original report doesn't seem to suggest it's crashing either, I'm not sure why the report title is as it is. This bug is very easily reproducable (on FreeBSD/PHP 4.4.1 at least) with default installs The bug simply causes PHP not to output anything in most cases, or output part of a page in others then stop Previous Comments: [2005-11-08 17:49:05] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2005-11-08 17:47:38] [EMAIL PROTECTED] --enable-versioning <-- Do you know what that does? (this has nothing to do with the bug, just note that you're using configure options you should not use) [2005-11-08 15:13:58] rob at burningsoda dot com sniper, To quickly reproduce the bug on FreeBSD 6.0, I do the following: 1. Install Apache 2.0.55 using FreeBSD ports 2. Install PHP 5.0.5 using FreeBSD ports --> The bug does _not_ show up. (If I had installed 4.4.1 from ports, it would) 4. Get a 5-dev snapshot (the last one I got is of 2005-11-06) and do this: ./configure\ --enable-versioning\ --enable-memory-limit\ --with-layout=GNU\ --with-config-file-scan-dir=/usr/local/etc/php\ --disable-all\ --enable-libxml --with-libxml-dir=/usr/local\ --enable-spl\ --with-apxs2=/usr/local/sbin/apxs\ --prefix=/usr/local\ i386-portbld-freebsd6.0 &&\ make clean &&\ make &&\ cp libs/libphp5.so /usr/local/libexec/apache2 &&\ /usr/local/etc/rc.d/apache2.sh restart --> there it is. The configure arguments are the standard arguments of the FreeBSD build system, but I do _not_ apply any of the FreeBSD-specific patches, they deliver (and which got included in the build in step 2). So, either the bug was introduced after 5.0.5 or one of the patches (have a look at them here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php5/files/) fixes it (which I personally don't think). Cheers, Rob. [2005-11-08 01:26:50] Chris at Epler dot net FreeBSD 4.11, Apache 2.0.55 Immediately after upgrading the PHP package from ports I get blank pages from Gallery integrated into Drupal which is using mod_rewrite. 4.4.0 did not have this issue and no other config file changes were made. [2005-11-07 20:17:13] free4cd at yahoo dot de Same problem on SuSE 9.3 and Apache 2.0.55 and 4.x and 5.x snapshots on i386. I've compiled Apache by hand and used the SuSE rpm's but I get the same error (blank page). I've also tried the php.ini-recommended and php.ini-dist without changes and it don't work. With 4.4.0 all works fine but since release of 4.4.1 and later snapshots (4.x and 5.x) mod_rewrite fails. 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/35096 -- Edit this bug report at http://bugs.php.net/?id=35096&edit=1
#35888 [NEW]: make install --> cp: sapi/cli/php no such file or directory
From: scott at abcoa dot com Operating system: AIX 5.2 PHP version: 5.1.1 PHP Bug Type: Compile Failure Bug description: make install --> cp: sapi/cli/php no such file or directory Description: Got a make install failure. The configure command is --snip-- ./configure --with-apxs2=../../apache2/bin/apxs --without-mysql --with-unixODBC --with-openssl --with-curl --disable-xml --disable-libxml --disable-dom --disable-simplexml --without-pear --enable-track-vars --enable-ftp --enable-sockets --snip-- --snip-- #make install echo '\ \ Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp5.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/ cp .libs/libphp5.a /usr/local/apache2/modules/libphp5.a cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /usr/local/src/php-5.1.1/libs' chmod 755 /usr/local/apache2/modules/libphp5.so [activating module `php5' in /usr/local/apache2/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ cp: sapi/cli/php: No such file or directory make: The error code from the last command is 1. Stop. # --snip-- Result from the ls -la command... --snip-- #ls -la sapi/cli/ total 264 drwxr-xr-x 3 1003 1003 4096 Jan 3 16:14 . drwxr-xr-x 22 1003 1003 4096 Nov 27 15:19 .. drwxr-xr-x 2 root system 256 Jan 3 16:14 .libs -rw-r--r-- 1 1003 1003 56 Aug 11 16:45 CREDITS -rw-r--r-- 1 1003 1003436 Oct 13 06:02 Makefile.frag -rw-r--r-- 1 1003 1003845 May 29 2003 README -rw-r--r-- 1 1003 1003 7 Mar 30 2003 TODO -rw-r--r-- 1 1003 1003 56 Jan 13 2004 cli_win32.c -rw-r--r-- 1 1003 1003 2158 Jul 7 2005 config.m4 -rw-r--r-- 1 1003 1003551 May 14 2005 config.w32 -rw-r--r-- 1 1003 1003 4235 Aug 3 07:12 getopt.c -rw-r--r-- 1 root system 312 Jan 3 16:14 getopt.lo -rw-r--r-- 1 root system 9118 Jan 3 15:35 php.1 -rw-r--r-- 1 1003 1003 9126 Aug 3 07:12 php.1.in -rw-r--r-- 1 1003 1003 32086 Nov 17 03:37 php_cli.c -rw-r--r-- 1 root system 314 Jan 3 16:14 php_cli.lo -rw-r--r-- 1 1003 1003 10787 Nov 17 03:37 php_cli_readline.c -rw-r--r-- 1 1003 1003 1371 Aug 3 07:12 php_cli_readline.h -rw-r--r-- 1 root system 332 Jan 3 16:14 php_cli_readline.lo -rw-r--r-- 1 1003 1003 1797 Aug 3 07:12 php_getopt.h # --snip-- Reproduce code: --- Do the usual configure, make, make install command then the error will popup. Expected result: Should be able to compile. Actual result: -- Compile failure. -- Edit bug report at http://bugs.php.net/?id=35888&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35888&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35888&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35888&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35888&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35888&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35888&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35888&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35888&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35888&r=support Expected behavior:http://bugs.php.net/fix.php?id=35888&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35888&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35888&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35888&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35888&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35888&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35888&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35888&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35888&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35888&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35888&r=mysqlcfg
#42130 [NEW]: Echo / Print Statements using OOP place OOP before string
From: scott at truebluewc dot com Operating system: Linux PHP version: 5.2.3 PHP Bug Type: *General Issues Bug description: Echo / Print Statements using OOP place OOP before string Description: When using an echo, print or a combination of those statements with an OOP, the OOP function within an echo statement, and using an echo inside that function, causes that function's echo to be first outputed before the echo statement called originally. See below code. Reproduce code: --- class file - syrup.php main file - index.php "; echo "and I hate ".syrup::pancakes(); echo "Actually.. I can't really decide!"; ?> Expected result: I love syrup on my pancakes! and I hate syrup on my pancakes! Actually.. I can't really decide! Actual result: -- syrup on my pancakes!I love syrup on my pancakes!and I hate Actually.. I can't really decide! -- Edit bug report at http://bugs.php.net/?id=42130&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42130&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42130&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42130&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42130&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42130&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42130&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42130&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42130&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42130&r=support Expected behavior:http://bugs.php.net/fix.php?id=42130&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42130&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42130&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42130&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42130&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42130&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42130&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42130&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42130&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42130&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42130&r=mysqlcfg
#38539 [NEW]: php-4.4.4 Not loading extensions
From: scott at phphq dot net Operating system: Windows Server 2003 STD PHP version: 4.4.4 PHP Bug Type: Unknown/Other Function Bug description: php-4.4.4 Not loading extensions Description: Since upgrading to php 4.4.4 php no longer loads any extensions. I installed it the same way I did php 4.4.3 and all earlier versions since 4.3.8. My install is like this: Shutdown IIS mv C:\php > C:\php-4.4.3.bak unzip new php package to C:\php Move php4isapi.dll to C:\php and change permissions accordingly. Change permissions on php4ts.dll and move files from \dll's to C:\php. Copy old php.ini to C:\php Restart IIS, phpinfo(), shows new version. This has worked for me flawless since 4.3.8, but with 4.4.4 it will not load any extensions. Downgrading back to 4.4.3 loads the extensions fine. Some misc info: PHPRC C:\php PATH: ;C:\php REG: IniFilePath: C:\php phpinfo() shows it is loading my php.ini (C:\php\php.ini) and the extension directory is C:\php\extensions, yet it will not load any extensions. Nothing has changed in my php.ini for a long time, the only extensions I have loaded are gettext, gd2, mbstring, zip. Running Win Server 2003 STD w/ IIS6. -- Edit bug report at http://bugs.php.net/?id=38539&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38539&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38539&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38539&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38539&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38539&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38539&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38539&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38539&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38539&r=support Expected behavior:http://bugs.php.net/fix.php?id=38539&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38539&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38539&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38539&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38539&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38539&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38539&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38539&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38539&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38539&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38539&r=mysqlcfg
#39513 [NEW]: URL file-access is disabled when allow_url_fopen = On
From: scott at html dot info Operating system: RHEL 4.4 64-bit PHP version: 5.2.0 PHP Bug Type: Filesystem function related Bug description: URL file-access is disabled when allow_url_fopen = On Description: allow_url_fopen is On in php.ini, phpinfo(); shows it as On, but scripts are broke since the 5.1 -> 5.2 upgrade. Reproduce code: --- http://www.google.com";; ?> Actual result: -- Warning: include() [function.include]: URL file-access is disabled in the server configuration in /home/.../public_html/test1.php on line 2 Warning: include(http://www.google.com) [function.include]: failed to open stream: no suitable wrapper could be found in /home/.../public_html/test1.php on line 2 Warning: include() [function.include]: Failed opening 'http://www.google.com' for inclusion (include_path='.:/usr/local/lib/php') in /home/.../public_html/test1.php on line 2 -- Edit bug report at http://bugs.php.net/?id=39513&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39513&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39513&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39513&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39513&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39513&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39513&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39513&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39513&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39513&r=support Expected behavior:http://bugs.php.net/fix.php?id=39513&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39513&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39513&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39513&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39513&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39513&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39513&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39513&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39513&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39513&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39513&r=mysqlcfg
#39513 [Bgs]: URL file-access is disabled when allow_url_fopen = On
ID: 39513 User updated by: scott at html dot info Reported By: scott at html dot info Status: Bogus Bug Type: Filesystem function related Operating System: RHEL 4.4 64-bit PHP Version: 5.2.0 New Comment: Oh thanks, that I missed. I looked at the docs but didn't see anything. Previous Comments: [2006-11-14 18:47:35] [EMAIL PROTECTED] Set allow_url_include to On. See more details in README.UPDATE_5_2. [2006-11-14 18:39:05] scott at html dot info Description: allow_url_fopen is On in php.ini, phpinfo(); shows it as On, but scripts are broke since the 5.1 -> 5.2 upgrade. Reproduce code: --- http://www.google.com";; ?> Actual result: -- Warning: include() [function.include]: URL file-access is disabled in the server configuration in /home/.../public_html/test1.php on line 2 Warning: include(http://www.google.com) [function.include]: failed to open stream: no suitable wrapper could be found in /home/.../public_html/test1.php on line 2 Warning: include() [function.include]: Failed opening 'http://www.google.com' for inclusion (include_path='.:/usr/local/lib/php') in /home/.../public_html/test1.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=39513&edit=1
#37495 [NEW]: php.ini - add a short example of the 3 options to the session.save_handler
From: scott at abcoa dot com Operating system: PHP version: 5.1.4 PHP Bug Type: Session related Bug description: php.ini - add a short example of the 3 options to the session.save_handler Description: The session.save_handler which showed "files" is the default option to be used. After 5 years of using the session, it never occur to me what the other options are until now. I have filed bug #37484 requesting some update to the php.net documentation that would give more clarification to the session.save_handler, the 3 options and their purpose. Since the documentation is an ongoing process, I figured if we can add something like "(Option Setting: files, mm, users)". Not sure if "user" come with or without a "s". The reason for this thought is it would stimulate our understanding on the use of sessions if someone didn't know any. I thought it would be nice to let people know what the options are and that there are more than one options to use. -- Edit bug report at http://bugs.php.net/?id=37495&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37495&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37495&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37495&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37495&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37495&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37495&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37495&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37495&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37495&r=support Expected behavior:http://bugs.php.net/fix.php?id=37495&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37495&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37495&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37495&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37495&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37495&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37495&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37495&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37495&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37495&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37495&r=mysqlcfg
#36852 [Bgs]: makefile failed due to apxs's command failure w/ rc=65536 error
ID: 36852 User updated by: scott at abcoa dot com Reported By: scott at abcoa dot com Status: Bogus Bug Type: Apache2 related Operating System: AIX 5.2 PHP Version: 5.1.2 New Comment: I was asked by a couple of folks to post this comment to help anyone who suffer from this issue to help to make their live be made easier and to cut down the loss of their business hours. --snip-- > My configuration is: > Apache: v2.2.4, PHP: v5.2.1 > > I'm not quite clear what the difference between the .la and the .so > files. Anyway, what I've figured out is the following: for somewhat > the php tries to install the libphp5.la as an apache module, and > instdso.sh doesn't like that very well. I don't see the point why to > install that, since libphp5.so is also created in the .libs directory. > So I've changed the INSTALL_IT line in the Makefile and replaced > libphp5.la with .libs/libphp5.so > > After this make install worked well, installed the .so file, added a > line into httpd.conf, etc. > > I know this is a quick&dirty fix, but somehow this bug should be > addressed, it's out there since a while ago. --snip-- Previous Comments: [2006-04-10 21:33:11] [EMAIL PROTECTED] It's not PHP bug either. It's libtool bug (or they say it's feature). Make sure you have shared libs of everything installed you link PHP (and Apache!) with. [2006-04-10 17:40:56] scott at abcoa dot com Followed up with your configure option and still get the same exact error.. I looked at the "install-sapi:" part in the makefile and it point to libphp5.la, then followed by removing the libphp5.so files, then followed by the APXS command. --snip-- /usr/local/apache2/bin/apxs -S LIBEXECDIR='/usr/local/apache2/modules' -S SYSCONFDIR='/usr/local/apache2/conf' -i -a -n php5 libphp5.la --snip-- It's the apxs command that look for libphp5.so files. I can verify that when executing this apxs command. [2006-04-10 12:31:18] [EMAIL PROTECTED] If it works with this configure line, there is no bug: # rm config.cache ; ./configure --disable-all --with-apxs2 If that works, there is propably some static library that PHP is linked with and then libtool thinks you want the whole thing as static. (this is a libtool bug, not PHP bug) [2006-03-24 23:53:54] scott at abcoa dot com Description: Apache version 2.2.0 I get a PHP compile failure with the make command. Configure command was --snip-- ./configure --with-apxs2=../../apache2/bin/apxs --disable-all --with-unixODBC --with-openssl --with-curl --with-curlwrappers --enable-spl --enable-session --enable-track-vars --enable-ftp --enable-sockets --snip-- followed by the make command. Narrowed down the problem to the apxs script in PHP's makefile, when translated is this... --snip-- /usr/local/apache2/bin/apxs -S LIBEXECDIR='/usr/local/apache2/modules' -S SYSCONFDIR='/usr/local/apache2/conf' -i -a -n php5 libphp5.la --snip-- Which give this installation output as below... --snip-- /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp5.la /usr/local/apache2/modules rm -f /usr/local/apache2/modules/libphp5.so /usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/ cp .libs/libphp5.a /usr/local/apache2/modules/libphp5.a cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /usr/local/src/php-5.1.2/libs' chmod 755 /usr/local/apache2/modules/libphp5.so chmod: /usr/local/apache2/modules/libphp5.so: A file or directory in the path name does not exist. apxs:Error: Command failed with rc=65536 --snip-- Problem is there's no libphp5.so as the libphp5.la and libphp5.a are the only two things that are found in that directory. Seem that it use the static file instead of the dso file. Thought it was an Apache bug so filed a bug there, bug #39099 and a couple of bugs report from the bugs.php.net search seem to confirm that. Then I was told that it's not an Apache bug but a PHP bug. So, I filed it here instead. Expected result: No apxs error message and to be able to compile successfully with the dso file (php module). -- Edit this bug report at http://bugs.php.net/?id=36852&edit=1
#31994 [Com]: output conversion failed due to conv error
ID: 31994
Comment by: scott at realorganized dot com
Reported By: misnet at hotmail dot com
Status: No Feedback
Bug Type: XSLT related
Operating System: windows 2003 server
PHP Version: 5CVS-2005-02-25
New Comment:
Here's some example code that shows the problem:
createElement("xxx", chr(200));
$domfather->appendChild($node);
echo "";
echo htmlspecialchars($domfather->saveXML());
$nodelist = $domfather->getElementsByTagName("xxx");
$data = $nodelist->item(0)->nodeValue;
echo $data;
echo strlen($data);
?>
Character code 200 is an e grave and is a valid iso-8859-1
character. The output from my server is below. When I retrieve
the node's data back, it is as expected. But it's the saveXML()
code that seems to have a problem. I suspect the problem is with
the utf-8 -> iso-8859 conversion before output.
Warning: DOMDocument::saveXML() [function.DOMDocument-saveXML]:
output conversion failed due to conv error in /Library/Tenon/
WebServer/WebSites/realtyjuggler.com/subscription/test.php on line
23
Warning: DOMDocument::saveXML() [function.DOMDocument-saveXML]:
Bytes: 0xC8 0x3C 0x2F 0x78 in /Library/Tenon/WebServer/WebSites/
realtyjuggler.com/subscription/test.php on line 23
È1
Previous Comments:
[2005-04-17 01:00:06] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-04-09 17:34:52] [EMAIL PROTECTED]
You're probably using a character which can not be represented in
iso-8859-1... but I don't know for sure as I don't have the data. Come
up with a *self-contained* script that does not rely on a database...
[2005-04-09 08:27:21] cbdbs at yahoo dot com
$doc = new DOMDocument('1.0','ISO-8859-1');
// we want a nice output
$doc->formatOutput = true;
$familias = $doc->appendChild(new DOMElement('familias'));
while ($fam_datos = mysql_fetch_array($data)){
$familia = $familias->appendChild(new DOMElement('familia'));
$familia->appendChild(new DOMElement('Apellidos',
$fam_datos['Familia']));
$familia->appendChild(new DOMElement('Representante',
$fam_datos['Apellidos']));
$familia->appendChild(new DOMElement('Nombre',
$fam_datos['Nombres']));
$familia->appendChild(new DOMElement('Edad',
$fam_datos['Edad']));
$familia->appendChild(new DOMElement('Salud', 'Sano'));
}
header('Content-Type: text/xml');
$documento = $doc->saveXML();
echo $documento;
OUTPUT
Warning: output conversion failed due to conv error in
c:\home\prueba\www\grid\xml.php...
[2005-04-07 11:43:19] emil at wayers dot com
This error/problem resolves around your used encoding type. when using
encoding="GB2312" in php5.0.4/cvs-current the engine will issue a
warning at the exact point a charcter has been found which isn't
suitable for this encoding context.
My script, which is similar to the given script, issued the exact same
warning on a character (ë) when using the standard iso encoding. After I
changed my encoding to UTF-8 all reported problems where gone.
I'm sure this isn't a real engine f*ck up but just a misguided error
message ;) But if this workaround doesn't work for you try changing your
Article->ComeFrom & Article->Contents & Article->AddTime content into
htmlentities.
good luck!
[2005-03-28 04:43:12] misnet at hotmail dot com
What about the bug? Can it not be resolved?
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/31994
--
Edit this bug report at http://bugs.php.net/?id=31994&edit=1
#41208 [NEW]: saveXML() fails with iso-8859-1 input
From: scott at realorganized dot com
Operating system: Mac OS X, Linux
PHP version: 5.2.1
PHP Bug Type: DOM XML related
Bug description: saveXML() fails with iso-8859-1 input
Description:
When using input encoding of charset=iso-8859-1 domDocument()
fails to output the ascii code 200 (e grave) using saveXML()
Reproduce code:
---
Here's some example code that shows the problem:
createElement("xxx", chr(200));
$domfather->appendChild($node);
echo "";
echo htmlspecialchars($domfather->saveXML());
$nodelist = $domfather->getElementsByTagName("xxx");
$data = $nodelist->item(0)->nodeValue;
echo $data;
echo strlen($data);
?>
Expected result:
I was expecting the saveXML() to output the e grave symbol (ascii
200)
iso-8859-1 character mapping is here:
http://old.no/charmap/iso-8859-1.html
and shows that ascii is completely valid.
Please notice that the data is provided correctly when I ask for
it by node. the failure is just when using the saveXML()
function.
Actual result:
--
The output from my server is below. When I retrieve
the node's data back, it is as expected. But it's the saveXML()
code that seems to have a problem. I suspect the problem is with
the utf-8 -> iso-8859 conversion before output.
Warning: DOMDocument::saveXML() [function.DOMDocument-saveXML]:
output conversion failed due to conv error in /Library/Tenon/
WebServer/WebSites/realtyjuggler.com/subscription/test.php on line
23
Warning: DOMDocument::saveXML() [function.DOMDocument-saveXML]:
Bytes: 0xC8 0x3C 0x2F 0x78 in /Library/Tenon/WebServer/WebSites/
realtyjuggler.com/subscription/test.php on line 23
È1
--
Edit bug report at http://bugs.php.net/?id=41208&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41208&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41208&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41208&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41208&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41208&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41208&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41208&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41208&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41208&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41208&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41208&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41208&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41208&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41208&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41208&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41208&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41208&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41208&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41208&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41208&r=mysqlcfg
#41208 [Opn]: saveXML() fails with iso-8859-1 input
ID: 41208
User updated by: scott at realorganized dot com
Reported By: scott at realorganized dot com
Status: Open
Bug Type: DOM XML related
Operating System: Mac OS X, Linux
PHP Version: 5.2.1
New Comment:
change:
$domfather->saveXML()
to:
$domfather->saveXML($node)
in the example code and execute and no echo at all - no error,
nothing. It's like it crashed or something.
Previous Comments:
[2007-04-26 21:53:54] scott at realorganized dot com
Description:
When using input encoding of charset=iso-8859-1 domDocument()
fails to output the ascii code 200 (e grave) using saveXML()
Reproduce code:
---
Here's some example code that shows the problem:
createElement("xxx", chr(200));
$domfather->appendChild($node);
echo "";
echo htmlspecialchars($domfather->saveXML());
$nodelist = $domfather->getElementsByTagName("xxx");
$data = $nodelist->item(0)->nodeValue;
echo $data;
echo strlen($data);
?>
Expected result:
I was expecting the saveXML() to output the e grave symbol (ascii
200)
iso-8859-1 character mapping is here:
http://old.no/charmap/iso-8859-1.html
and shows that ascii is completely valid.
Please notice that the data is provided correctly when I ask for
it by node. the failure is just when using the saveXML()
function.
Actual result:
--
The output from my server is below. When I retrieve
the node's data back, it is as expected. But it's the saveXML()
code that seems to have a problem. I suspect the problem is with
the utf-8 -> iso-8859 conversion before output.
Warning: DOMDocument::saveXML() [function.DOMDocument-saveXML]:
output conversion failed due to conv error in /Library/Tenon/
WebServer/WebSites/realtyjuggler.com/subscription/test.php on line
23
Warning: DOMDocument::saveXML() [function.DOMDocument-saveXML]:
Bytes: 0xC8 0x3C 0x2F 0x78 in /Library/Tenon/WebServer/WebSites/
realtyjuggler.com/subscription/test.php on line 23
È1
--
Edit this bug report at http://bugs.php.net/?id=41208&edit=1
#35888 [Fbk->Opn]: make install --> cp: sapi/cli/php no such file or directory
ID: 35888 User updated by: scott at abcoa dot com Reported By: scott at abcoa dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: AIX 5.2 PHP Version: 5.1.1 New Comment: Changed feedback to open since I posted the comment earlier. Previous Comments: [2006-01-04 16:32:03] sfletcher at abcoa dot com Recompiled with the latest CVS snapshot this morning and still get the same compile error. Noticed the wording in the error message is a bit different now. --snip-- Installing PHP CLI binary:/usr/local/bin/ cp: sapi/cli/php: A file or directory in the path name does not exist. make: 1254-004 The error code from the last command is 1. --snip-- Also, please disregard the original configure command in the first posting as the never ending addition of the new XML extensions give me the griefs. The new configure command is --snip-- ./configure --with-apxs2=../../apache2/bin/apxs --disable-all --with-unixODBC --with-openssl --with-curl --with-curlwrappers --enable-spl --enable-session --enable-track-vars --enable-ftp --enable-sockets --snip-- [2006-01-04 01:24:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2006-01-03 23:56:58] scott at abcoa dot com Description: Got a make install failure. The configure command is --snip-- ./configure --with-apxs2=../../apache2/bin/apxs --without-mysql --with-unixODBC --with-openssl --with-curl --disable-xml --disable-libxml --disable-dom --disable-simplexml --without-pear --enable-track-vars --enable-ftp --enable-sockets --snip-- --snip-- #make install echo '\ \ Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp5.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/ cp .libs/libphp5.a /usr/local/apache2/modules/libphp5.a cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /usr/local/src/php-5.1.1/libs' chmod 755 /usr/local/apache2/modules/libphp5.so [activating module `php5' in /usr/local/apache2/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ cp: sapi/cli/php: No such file or directory make: The error code from the last command is 1. Stop. # --snip-- Result from the ls -la command... --snip-- #ls -la sapi/cli/ total 264 drwxr-xr-x 3 1003 1003 4096 Jan 3 16:14 . drwxr-xr-x 22 1003 1003 4096 Nov 27 15:19 .. drwxr-xr-x 2 root system 256 Jan 3 16:14 .libs -rw-r--r-- 1 1003 1003 56 Aug 11 16:45 CREDITS -rw-r--r-- 1 1003 1003436 Oct 13 06:02 Makefile.frag -rw-r--r-- 1 1003 1003845 May 29 2003 README -rw-r--r-- 1 1003 1003 7 Mar 30 2003 TODO -rw-r--r-- 1 1003 1003 56 Jan 13 2004 cli_win32.c -rw-r--r-- 1 1003 1003 2158 Jul 7 2005 config.m4 -rw-r--r-- 1 1003 1003551 May 14 2005 config.w32 -rw-r--r-- 1 1003 1003 4235 Aug 3 07:12 getopt.c -rw-r--r-- 1 root system 312 Jan 3 16:14 getopt.lo -rw-r--r-- 1 root system 9118 Jan 3 15:35 php.1 -rw-r--r-- 1 1003 1003 9126 Aug 3 07:12 php.1.in -rw-r--r-- 1 1003 1003 32086 Nov 17 03:37 php_cli.c -rw-r--r-- 1 root system 314 Jan 3 16:14 php_cli.lo -rw-r--r-- 1 1003 1003 10787 Nov 17 03:37 php_cli_readline.c -rw-r--r-- 1 1003 1003 1371 Aug 3 07:12 php_cli_readline.h -rw-r--r-- 1 root system 332 Jan 3 16:14 php_cli_readline.lo -rw-r--r-- 1 1003 1003 1797 Aug 3 07:12 php_getopt.h # --snip-- Reproduce code: --- Do the usual configure, make, make install command then the error will popup. Expected result: Should be able to compile. Actual result: -- Compile failure. -- Edit this bug report at http://bugs.php.net/?id=35888&edit=1
