[PHP-DEV] PHP 4.1.0 configure options
Suggested Slogan: PHP: Now with close to 400 lines of configure options... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14424: is_readable returns error if file does not exist.
Sadly they made this change. I don't agree with it or like it, but the
change has been made. Use exists instead.
--
Mike
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 11, 2001 9:22 AM
Subject: [PHP-DEV] Bug #14424: is_readable returns error if file does not
exist.
From: [EMAIL PROTECTED]
Operating system: Suse linux 7.2
PHP version: 4.1.0
PHP Bug Type: Filesystem function related
Bug description: is_readable returns error if file does not exist.
Code example:
if (is_readable(foo)) {
echo file exists.P;
} else {
echo file does not exist.P;
}
Error message:
Warning: stat failed for foo (errno=2 - No such file or directory) in
/home/xxx/public_html/is_readable.php on line 3
Configure options:
./configure --with-apache=/home/xxx/apache_1.3.22 --with-mysql=/usr/local
--with-gd=/usr/local --with-zlib-dir=/usr/local --with-png-dir=/usr
--with-jpeg-dir=/home/xxx/jpeg-6b --with-xpm-dir=/usr/X11R6 --with-ttf
--with-curl
Seems similar to is_file() bug. Problem does not occur on older versions
(i.e. 4.0.6).
--
Edit bug report at: http://bugs.php.net/?id=14424edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14420: is_file prints stat failed .. message
This has been changed. Use exists() first. Technically, if the file does exist, it's not a file in my opinion and should return false, but nobody seems to agree with me. -- Mike - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 11, 2001 5:01 AM Subject: [PHP-DEV] Bug #14420: is_file prints stat failed .. message From: [EMAIL PROTECTED] Operating system: Redhat Linux PHP version: 4.1.0 PHP Bug Type: Scripting Engine problem Bug description: is_file prints stat failed .. message We have found it out when upgraded our PHP from ver.4.0.1 to 4.1.0 . Function is_file() prints error message if file doesn't exist. The error message looks like: Warning: stat failed for /home/.../index.phtml (errno=2 - No such file or directory) in /home/.../index.phtml on line 17 When I tried to simulate the problem in test file - it didn't appear . But then I included my configuration file which contained other inclusions for our corporate API. Problem appeared in the test file. I commented inclusion line - problem still appear. After typing the message above, I refreshed that page - problem disappeared. All further tryings to cause error got failed. Problem appears constanlty on our sites where we use this function. -- Edit bug report at: http://bugs.php.net/?id=14420edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14420: is_file prints stat failed .. message
Agreed. These changes should be made into toggles. If you ask me, if the file doesn't exist, it's not a file. That shouldn't be an error message. -- Mike - Original Message - From: Vitali Evstigneev [EMAIL PROTECTED] To: Mike Rogers [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, December 11, 2001 9:41 PM Subject: Re: [PHP-DEV] Bug #14420: is_file prints stat failed .. message Hello Mike! Thanks for responding. I'm affraid I haven't described problem well enough. Function is_file() still returns FALSE. But in the same time it types error message to output. It doesn't affect program's flow but affects interface. I understand that if we parse name is_file then function seems to be assuming that argument points either to existing file or folder or link. That's true amd I'm agree with you. We should use file_exists() first. But I'm talking about different thing. I'm talking about compatibility of code written on lower version with higher version i.e. succession of versions. is_file() was written very long time ago, and it was working by some way. People used that function and they knew that it works fine. Now, because of our wish to make PHP language more beautiful and logically perfect, those people have to change tonns of code. Some code has been frosen for changes and they have to make more paper work to get approval from management for making changes and so one and so forth. Why don't we leave working function in it's previous state and achieve succession of versions by that? Regards, Vitali - Original Message - From: Mike Rogers [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, December 12, 2001 7:16 AM Subject: Re: [PHP-DEV] Bug #14420: is_file prints stat failed .. message This has been changed. Use exists() first. Technically, if the file does exist, it's not a file in my opinion and should return false, but nobody seems to agree with me. -- Mike - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 11, 2001 5:01 AM Subject: [PHP-DEV] Bug #14420: is_file prints stat failed .. message From: [EMAIL PROTECTED] Operating system: Redhat Linux PHP version: 4.1.0 PHP Bug Type: Scripting Engine problem Bug description: is_file prints stat failed .. message We have found it out when upgraded our PHP from ver.4.0.1 to 4.1.0 . Function is_file() prints error message if file doesn't exist. The error message looks like: Warning: stat failed for /home/.../index.phtml (errno=2 - No such file or directory) in /home/.../index.phtml on line 17 When I tried to simulate the problem in test file - it didn't appear . But then I included my configuration file which contained other inclusions for our corporate API. Problem appeared in the test file. I commented inclusion line - problem still appear. After typing the message above, I refreshed that page - problem disappeared. All further tryings to cause error got failed. Problem appears constanlty on our sites where we use this function. -- Edit bug report at: http://bugs.php.net/?id=14420edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14108: file_exists() prints a warning when it shouldn't
There was some question of this quite some time ago. is_file() was changed (to many peoples annoyance by what I saw) to report the error. file_exists still shouldn't report the error. Personally, I think they both shouldn't. If it doesn't exist, it sure as hell isn't a file, so it should be false. Cluttering too many error messages is bad. People don't want to have to change their log level because existing scripts like it. -- Mike - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 19, 2001 6:35 AM Subject: [PHP-DEV] Bug #14108: file_exists() prints a warning when it shouldn't From: [EMAIL PROTECTED] Operating system: Debian PHP version: 4.1.0RC1 PHP Bug Type: *Directory/Filesystem functions Bug description: file_exists() prints a warning when it shouldn't Running this code ?file_exists(/etc/passwd/bla);? (where /etc/passwd exists for those non-UNIX people) gives this warning Warning: stat failed for /etc/passwd/bla (errno=20 - Not a directory) in This worked in 4.0.6 and doesn't in 4.1.0RC (1 and 2). It's been reported as #114409 in Debian with a patch -- Edit bug report at: http://bugs.php.net/?id=14108edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)
Because that appears to be rediculous idea. At present, unless you have a problem which requires you to upgrade, you stick with the stable proven release. The only reason why Linux kernel gets released so often is because it contains security fixes that affect everyone and are in the public. Security fixes should be released immediately. Just bug fixes, added features and optimized functions should only be done in major releases. Keep in mind, with every new feature, we break another two. Do you _really_ want that many new things on production machines that haven't been properly testes. In 4.0.7, there was a complete rework of the Zend memory management by my understanding- Imagine not testing that at all and putting it out. You are asking for serious problems. Administrators do not want to be upgrading on a weekly basis (or less). We need to keep stable, quality, secure releases- and that only comes from extensive testing. My point- yes it is more work, but let's make a new release candidate from 4.0.7 and release it. It's stable and seems very reliable. It also makes less work for Zend releasing thier optimizer for each release of PHP. Please guys- do not consider regular small releases. Major releases that are properly tested and released (and yes I do keep up on CVS much of the time to test and contribute to the code- I am one of those properly testing it) -- -- Mike - Original Message - From: Jani Taskinen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, November 10, 2001 4:34 PM Subject: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0) On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. I have a bad feeling about this branch and I vote for dropping it and starting new from HEAD. There are several reasons for this: The change between 4.0.7 - 4.1.0 (and also sudden change of the release master from Zeev to Stig) has confused some people according the discussion on php-qa list a while ago. Many of them might have tested 4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. Not to forget the 11th of September.. I have no idea who have tested the latest RC. Does anyone have? After the latest RC there have been a LOT of fixes in the release branch and also several fixes in the HEAD (which weren't MFH'd) and there hasn't been any new RCs after those fixes were committed. How many people test the branch (from CVS) ? Has anyone kept any list of the test results and problems found ? Has anyone kept eye on fixes done which weren't merged to the branch ? Answer is: We don't KNOW. The thing is that the project has grown to be so big that we can not afford long periods of time between releases. Too much stuff gets in without testing. Too many NEW bugs are introduced and like it has been said many times before, not enough people really pay attention to fixing them. Developers simply ignore them and continue adding new stuff thus creating new possible bugs. Anyone think what I think? Release early, release often http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.h tml This works very well for Linux, why wouldn't it work for PHP ? Our QA team is very small. It has actually gotten smaller during the last 6 months instead of getting bigger like it should have. Enough ranting, let's get into fixing this situation. I can't see any solutions that won't bite us but one solution that won't bite as so badly in the _long_run_, as if we delay it or release too early we're gonna get hurt. My proposal is this: - Release the current branch as 4.1.0 but clearly state that there will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and the QA process on it with some things kept in mind: o Any serious problems found (by our best QA team: the real users) in 4.1 we fix them in 4.2 and announce that after 4.2 release we start following the versioning rules for real. o We continue releasing 4.2.x versions out of the 4.2 branch but with ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to HEAD. We should decide what amount of fixes or with what severity triggers the (short) QA process for the 4.2.x branch. o After there have been, let's say 5 big ones in HEAD, we start new branch, 4.3 and QA process moves there. The QA should not take so long with this. Security related fixes should trigger new release process immediately. o Any changes into extensions from now on should include the start of using the version
Re: [PHP-DEV] Bug #12068 Updated: Maybe a memory leak or something.
Does this memlimit patch need to be applied to 4.0.8-dev or 4.1.0 builds, or has it been finally implemented into the distribution -- Mike - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 21, 2001 1:20 AM Subject: [PHP-DEV] Bug #12068 Updated: Maybe a memory leak or something. ID: 12068 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Apache related Operating System: SunOS 5.7 sun4u sparc UltraE10k PHP Version: 4.0.6 New Comment: Did you use the --enable-memory-limit when configuring PHP? If so, try applying the patch found at: http://www.php.net/distributions/php-4.0.6-memlimit.diff.gz --Jani Previous Comments: [2001-07-11 17:14:49] [EMAIL PROTECTED] This was outputted from top. 2581 nobody 1 00 555M 541M cpu54 1:59 12.37% httpd 2572 nobody 1 00 721M 542M cpu50 2:03 12.30% httpd Those were just two child processes from httpd. This happens when I run ? phpinfo();? if I reload the page about 3 or 4 times (IE), My System slows down considerably. Edit this bug report at http://bugs.php.net/?id=12068edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Zend Optimizer
Guys; Is there any way to get the Zend Optimizer to work with the latest CVS snapshot. I really need it working and can't go backwards because I would break why I am using a snapshot in the first place. Any ideas? -- Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Big Reporting Database VERSION
Guys- How about we add the current development version (4.1.0RC1) to the bug-track database's lists of options. It would make a lot of sense if people aren't filling out 4.1.0RC1 bugs claiming them to be 4.0.6 bugs. -- Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] MySQL_Num_Rows functionality
mysql_num_rows() to a result that returned zero rows returns 'Supplied argument is not a valid MySQL result resource'. If it is an invalid resource (such as SELECT * from table to an empty table), shouldn't it return ZERO (0). That seems to make the most sense, as opposed to throwing an error. if (mysql_num_rows($result) != 0) seems to be useful, but it doesn't work because of this. I realize I can put an @' symbol, but i just think it should return zero. -- Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] MySQL_Num_Rows functionality
Ignore. This only happened for a few minutes and without changing anything started working. I don't know why. -- Mike - Original Message - From: Mike Rogers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 30, 2001 12:48 AM Subject: [PHP-DEV] MySQL_Num_Rows functionality mysql_num_rows() to a result that returned zero rows returns 'Supplied argument is not a valid MySQL result resource'. If it is an invalid resource (such as SELECT * from table to an empty table), shouldn't it return ZERO (0). That seems to make the most sense, as opposed to throwing an error. if (mysql_num_rows($result) != 0) seems to be useful, but it doesn't work because of this. I realize I can put an @' symbol, but i just think it should return zero. -- Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PostgreSQL / PHP Overrun Error
I have just upgraded to the new PostgreSQL 7.1.3 (from 7.0.3) and have been
experiencing a pretty serious problem:
On one particular page, in what seems to be completely random instances,
I get buffer overruns and either 0-rows or a crashed apache child. Turning
on PHP's --enable-debug, I receive the following [in httpd error log]:
[Wed Sep 26 06:21:12 2001] Script: '/path/to/script.php'
---
pgsql.c(167) : Block 0x086A6DF8 status:
Beginning: Overrun (magic=0x, expected=0x7312F8DC)
End: Unknown
---
Sometimes it will actually crash mid-way (probably overwrote some valuable
code):
---
pgsql.c(167) : Block 0x08684290 status:
Beginning: Overrun (magic=0x111A, expected=0x7312F8DC)
[Wed Sep 26 09:22:46 2001] [notice] child pid 8710 exit signal Segmentation
fault (11)
This problem is of great concern to me and I have been working for days
trying to debug it myself and find other reports, with little success. The
line it claims to be failing on is PHP's ext/pgsql/pgsql.c on line 167 (by
what this claims) which is the following function [the
efree(PGG(last_notice)) line].
static void
_notice_handler(void *arg, const char *message)
{
PGLS_FETCH();
if (! PGG(ignore_notices)) {
php_log_err((char *) message);
if (PGG(last_notice) != NULL) {
efree(PGG(last_notice));
}
PGG(last_notice) = estrdup(message);
}
}
Can anyone provide further input as to why this is causing problems? The
PHP code works sometimes and not others, and it seems to be only that one
script, so I do not believe it to be a hardware issue.
Any thoughts? I can provide any further system information if needed. I
have tried recompiling pgsql, php and apache with different optimizations
[including none at all and debug mode on as i have now] with little change
in the result.
Thanks in advance;
--
Mike
cc: pgp-db-help; pgp-dev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PostgreSQL / PHP Overrun Error
Hi Zeev;
Seems to have fixed the problem. What is this expected to be included
in a final version 4.0.7 I assume... I try to avoid alpha/beta but I
suppose I have little choice at this time. Now I just see enormous amounts
of:
string.c(1341) : Freeing 0x086AB454 (6 bytes), script=/path/to/scripts
I assume that's normal in debug mode for the Zend cleanup engines... So
I suppose all is well. Thank you so much. If you have a guestimate on the
next release including all of this, that would be amaizing.
Thanks for all of your help;
--
Mike
- Original Message -
From: Zeev Suraski [EMAIL PROTECTED]
To: Mike Rogers [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, September 26, 2001 6:51 PM
Subject: Re: [PHP-DEV] PostgreSQL / PHP Overrun Error
Can you try the latest CVS? It should fix the problem.
Zeev
At 18:35 26-09-01, Mike Rogers wrote:
I have just upgraded to the new PostgreSQL 7.1.3 (from 7.0.3) and have
been
experiencing a pretty serious problem:
On one particular page, in what seems to be completely random
instances,
I get buffer overruns and either 0-rows or a crashed apache child.
Turning
on PHP's --enable-debug, I receive the following [in httpd error log]:
[Wed Sep 26 06:21:12 2001] Script: '/path/to/script.php'
---
pgsql.c(167) : Block 0x086A6DF8 status:
Beginning: Overrun (magic=0x, expected=0x7312F8DC)
End: Unknown
---
Sometimes it will actually crash mid-way (probably overwrote some
valuable
code):
---
pgsql.c(167) : Block 0x08684290 status:
Beginning: Overrun (magic=0x111A, expected=0x7312F8DC)
[Wed Sep 26 09:22:46 2001] [notice] child pid 8710 exit signal
Segmentation
fault (11)
This problem is of great concern to me and I have been working for days
trying to debug it myself and find other reports, with little success.
The
line it claims to be failing on is PHP's ext/pgsql/pgsql.c on line 167
(by
what this claims) which is the following function [the
efree(PGG(last_notice)) line].
static void
_notice_handler(void *arg, const char *message)
{
PGLS_FETCH();
if (! PGG(ignore_notices)) {
php_log_err((char *) message);
if (PGG(last_notice) != NULL) {
efree(PGG(last_notice));
}
PGG(last_notice) = estrdup(message);
}
}
Can anyone provide further input as to why this is causing problems? The
PHP code works sometimes and not others, and it seems to be only that one
script, so I do not believe it to be a hardware issue.
Any thoughts? I can provide any further system information if needed. I
have tried recompiling pgsql, php and apache with different optimizations
[including none at all and debug mode on as i have now] with little
change
in the result.
Thanks in advance;
--
Mike
cc: pgp-db-help; pgp-dev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Error Logging on a Per-Domain basis [to apache logs]
I have tried setting as follows in my .htaccess and in my apache server logs: php_value error_log /path/to/log.file php_flag log_errors On And it doesn't seem to do anything. I am already logging to each virtual hosts' error log for http-related logs [such as not found, etc]. Is there any way to put PHP error logs into the same files that Apache logs to as opposed to the master log file? That seems to make an enormous amounts of sense on mutli-user machines (and if there is no error log set for the virtual host, it should use the server log). Is this feature implemented? Could it be? -- Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PostgreSQL / PHP Overrun Error
Solved- Logs seem pretty empty now thanks to the new CVS.
Interesting question actually. Any way to put a hard compile-time
variable [or php.ini only variable] that will not show the configure line in
phpinfo(). That seems very logical to ensure that customers can not
reproduce your exact setup with ease.
--
Mike
- Original Message -
From: Zeev Suraski [EMAIL PROTECTED]
To: Mike Rogers [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, September 26, 2001 9:21 PM
Subject: Re: [PHP-DEV] PostgreSQL / PHP Overrun Error
4.0.7 will include this fix. All I can say is that it's supposed to come
out 'soon'...
About that leak - can you test the latest CVS again? :)
At 01:58 27-09-01, Mike Rogers wrote:
Hi Zeev;
Seems to have fixed the problem. What is this expected to be
included
in a final version 4.0.7 I assume... I try to avoid alpha/beta but I
suppose I have little choice at this time. Now I just see enormous
amounts
of:
string.c(1341) : Freeing 0x086AB454 (6 bytes),
script=/path/to/scripts
I assume that's normal in debug mode for the Zend cleanup engines...
So
I suppose all is well. Thank you so much. If you have a guestimate on
the
next release including all of this, that would be amaizing.
Thanks for all of your help;
--
Mike
- Original Message -
From: Zeev Suraski [EMAIL PROTECTED]
To: Mike Rogers [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, September 26, 2001 6:51 PM
Subject: Re: [PHP-DEV] PostgreSQL / PHP Overrun Error
Can you try the latest CVS? It should fix the problem.
Zeev
At 18:35 26-09-01, Mike Rogers wrote:
I have just upgraded to the new PostgreSQL 7.1.3 (from 7.0.3) and
have
been
experiencing a pretty serious problem:
On one particular page, in what seems to be completely random
instances,
I get buffer overruns and either 0-rows or a crashed apache child.
Turning
on PHP's --enable-debug, I receive the following [in httpd error
log]:
[Wed Sep 26 06:21:12 2001] Script: '/path/to/script.php'
---
pgsql.c(167) : Block 0x086A6DF8 status:
Beginning: Overrun (magic=0x, expected=0x7312F8DC)
End: Unknown
---
Sometimes it will actually crash mid-way (probably overwrote some
valuable
code):
---
pgsql.c(167) : Block 0x08684290 status:
Beginning: Overrun (magic=0x111A, expected=0x7312F8DC)
[Wed Sep 26 09:22:46 2001] [notice] child pid 8710 exit signal
Segmentation
fault (11)
This problem is of great concern to me and I have been working for
days
trying to debug it myself and find other reports, with little
success.
The
line it claims to be failing on is PHP's ext/pgsql/pgsql.c on line
167
(by
what this claims) which is the following function [the
efree(PGG(last_notice)) line].
static void
_notice_handler(void *arg, const char *message)
{
PGLS_FETCH();
if (! PGG(ignore_notices)) {
php_log_err((char *) message);
if (PGG(last_notice) != NULL) {
efree(PGG(last_notice));
}
PGG(last_notice) = estrdup(message);
}
}
Can anyone provide further input as to why this is causing problems?
The
PHP code works sometimes and not others, and it seems to be only that
one
script, so I do not believe it to be a hardware issue.
Any thoughts? I can provide any further system information if
needed. I
have tried recompiling pgsql, php and apache with different
optimizations
[including none at all and debug mode on as i have now] with little
change
in the result.
Thanks in advance;
--
Mike
cc: pgp-db-help; pgp-dev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail:
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail:
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] php_smart_str leek
I seem to have found a leak: php_smart_str.h(74) : Freeing 0x08641FF4 (4568 bytes), script=/path/to/file.php Last leak repeated 2 times Latest CVS (9.45pm EST, Wednesday night) -- Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] php_smart_str leek
There doesn't appear to be anything unusual in the script. There are a few includes pointing almost completely to HTML, and a few MySQL database queries. It is not my code to release, so I am hesitant to do so. Any alternate ways to debug this? I can strace or gdb to a thread and wait for it to come up if that would help. -- Mike - Original Message - From: Sterling Hughes [EMAIL PROTECTED] To: Mike Rogers [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 10:57 PM Subject: Re: [PHP-DEV] php_smart_str leek On Wed, 26 Sep 2001, Mike Rogers wrote: I seem to have found a leak: php_smart_str.h(74) : Freeing 0x08641FF4 (4568 bytes), script=/path/to/file.php Last leak repeated 2 times Can you show me the source of file.php (the leak isn't in the smart_str() code, but rather in a library that implements it)? -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
