Hi, all
Current HEAD eats all memory and dies, trying to execute any script (<? phpinfo(); ?>, for example).
Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built some minutes ago) work fine on the same machine.
My configuration:
Linux 2.4.21
autoconf 2.57
automake 1.7
libtool 1.5
gcc 3.3
glibc-2.3.2
apache 1.3.27
cat ./config.nice
! /bin/sh
'./configure'
'--with-apxs=/usr/local/apache/bin/apxs'
'--enable-memory-limit'
'--disable-dom'
'--without-pear'
'--without-sqlite'
'--disable-cli'
"$@"
of course, when memory-limit is enabled, it only complains "Allowed memory size of 16777216 bytes exhausted"
and php tries to eat all memory only when I remove it.
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
Current HEAD eats all memory and dies, trying to execute any script (<?
phpinfo(); ?>, for example).
Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built some
minutes ago) work fine on the same machine.
Thank god ;-) i thought it was on my machine only!
Gr,
JOhn
On Mon, 1 Dec 2003 15:51:54 +0100
"John Huntjens" john@ceressoft.nl wrote:
Current HEAD eats all memory and dies, trying to execute any script (<?
phpinfo(); ?>, for example).
Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built some
minutes ago) work fine on the same machine.Thank god ;-) i thought it was on my machine only!
I'm glad to hear, that it's not only my problem.
But I wonder why it wasn't discovered before...
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
Current HEAD eats all memory and dies, trying to execute any script
(<?
phpinfo(); ?>, for example).
Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built
some
minutes ago) work fine on the same machine.Thank god ;-) i thought it was on my machine only!
I'm glad to hear, that it's not only my problem.
But I wonder why it wasn't discovered before...
What i more worried about:
Is'nt there a quality check about things commited to cvs?
It shoud not be possible to break things in such a fundamental way!!
Gr,
JOhn
PS. for now rolled back to php5-200311291030.tar.tar, works ok
Current HEAD eats all memory and dies, trying to execute any script
(<?
phpinfo(); ?>, for example).
Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built
some
minutes ago) work fine on the same machine.Thank god ;-) i thought it was on my machine only!
I'm glad to hear, that it's not only my problem.
But I wonder why it wasn't discovered before...What i more worried about:
Is'nt there a quality check about things commited to cvs?
It shoud not be possible to break things in such a fundamental way!!
Oh shutup. It works just fine. You guys must be doing something wrong.
Derick
What i more worried about:
Is'nt there a quality check about things commited to cvs?
It shoud not be possible to break things in such a fundamental way!!Oh shutup. It works just fine. You guys must be doing something wrong.
No I won't!
I compile a snap every day, in the same configuration: snap from 29-11 is
ok, today's snap is not.
You must be brain dead to say to shutup, without make any verifications!
JOhn
On Mon, 1 Dec 2003 17:12:02 +0100
"John Huntjens" john@ceressoft.nl wrote:
<snap>What i more worried about:
Is'nt there a quality check about things commited to cvs?
It shoud not be possible to break things in such a fundamental way!!Oh shutup. It works just fine. You guys must be doing something wrong.
No I won't!
I compile a snap every day, in the same configuration: snap from 29-11 is
ok, today's snap is not.You must be brain dead to say to shutup, without make any verifications!
please, calm down.
I'm sure, that Derick, Jani and Sebastian verified this before answering.
better tell me versions of your autotools.
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
John instead of making a nuisance of yourself, why not find the problem that
affects your installation (that 3 developers cannot replicate) and suggest a
fix?
Ilia
On Mon, 1 Dec 2003 17:03:43 +0100 (CET)
Derick Rethans derick@php.net wrote:
Current HEAD eats all memory and dies, trying to execute any script
(<?
phpinfo(); ?>, for example).
Version of HEAD from 2003-11-29 and current PHP_4_3 (both are built
some
minutes ago) work fine on the same machine.Thank god ;-) i thought it was on my machine only!
I'm glad to hear, that it's not only my problem.
But I wonder why it wasn't discovered before...What i more worried about:
Is'nt there a quality check about things commited to cvs?
It shoud not be possible to break things in such a fundamental way!!Oh shutup. It works just fine. You guys must be doing something wrong.
of course, there is such possibility.
but I have really no idea what can cause today's HEAD to eat memory and Friday's HEAD to work fine at the same time.
autotools again?
BTW, I've already asked about this message:
buildconf: autoconf version 2.50 (ok)
buildconf: Your version of autoconf likely contains buggy cache code.
Running cvsclean for you.
To avoid this, install autoconf-2.13 and automake-1.5.
and nobody answered.
the problem: if I install autoconf-2.13, ./buildconf fails, because it requires autoconf >= 2.50.
so, at this moment I don't know which version of autoconf should I use to build PHP from sources in the right way,
but autoconf 2.50 worked fine till now (except this message).
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
BTW, I've already asked about this message:
buildconf: autoconf version 2.50 (ok)
buildconf: Your version of autoconf likely contains buggy cache code.
Running cvsclean for you.
To avoid this, install autoconf-2.13 and automake-1.5.
Don't use autoconf > 2.13, it's really SLOW and also buggy.
and nobody answered.
the problem: if I install autoconf-2.13, ./buildconf
fails, because it requires autoconf >= 2.50.
Eh..if that was true, I would never ever run this every day:
# ./cvsclean && ./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: libtool version 1.4.3 (ok)
.
.
Or would I? :)
so, at this moment I don't know which version of autoconf should I use to
build PHP from sources in the right way, but autoconf 2.50 worked fine till
now (except this message).
I has never worked perfectly, please don't claim that.
As I doubt you have the correct bison, libtool, etc. either,
I recommend that you stick with snapshots.
--Jani
On Mon, 1 Dec 2003 20:56:53 +0200 (EET)
Jani Taskinen sniper@iki.fi wrote:
BTW, I've already asked about this message:
buildconf: autoconf version 2.50 (ok)
buildconf: Your version of autoconf likely contains buggy cache code.
Running cvsclean for you.
To avoid this, install autoconf-2.13 and automake-1.5.Don't use autoconf > 2.13, it's really SLOW and also buggy.
ok
Eh..if that was true, I would never ever run this every day: # ./cvsclean && ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: libtool version 1.4.3 (ok) . . Or would I? :)
changing automake to 1.4-p6 and libtool to 1.4.3 helped.
thank you very much, Jani.
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
Works fine for me.
--Jani
Hi, all
Current HEAD eats all memory and dies, trying to execute any script (<?
phpinfo(); ?>, for example). Version of HEAD from 2003-11-29 and current
PHP_4_3 (both are built some minutes ago) work fine on the same machine.My configuration:
Linux 2.4.21
autoconf 2.57
automake 1.7
libtool 1.5
gcc 3.3
glibc-2.3.2
apache 1.3.27cat ./config.nice
! /bin/sh
'./configure'
'--with-apxs=/usr/local/apache/bin/apxs'
'--enable-memory-limit'
'--disable-dom'
'--without-pear'
'--without-sqlite'
'--disable-cli'
"$@"
of course, when memory-limit is enabled, it only complains "Allowed memory size of 16777216 bytes exhausted"
and php tries to eat all memory only when I remove it.
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
Jani Taskinen wrote:
Works fine for me.
Works fine here, too. (Win32)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Jani Taskinen
>
> Works fine for me.
>
I've already re-checked that about 10 times.
2 minutes ago I've repeated all the process from the very beginning:
#cvs co php-src
#./buildconf
#./configure ...blah-blah (configure line from the previous letter)
#make
same results with <? `phpinfo()`; ?>:
...
Allowed memory size of 16777216 bytes exhausted (tried to allocate 256 bytes)
...
---
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
Try with the snapshot from http://snaps.php.net
--Jani
>On Mon, 1 Dec 2003 17:40:09 +0200 (EET)
>Jani Taskinen
>
>>
>> Works fine for me.
>>
>
>I've already re-checked that about 10 times.
>
>2 minutes ago I've repeated all the process from the very beginning:
>#cvs co php-src
>#./buildconf
>#./configure ...blah-blah (configure line from the previous letter)
>#make
>
>same results with <? `phpinfo()`; ?>:
>...
>Allowed memory size of 16777216 bytes exhausted (tried to allocate 256 bytes)
>...
>
>
>---
>WBR,
>Antony Dovgal aka tony2001
>tony2001@phpclub.net
On Mon, 1 Dec 2003 18:04:46 +0200 (EET)
Jani Taskinen sniper@iki.fi wrote:
Try with the snapshot from http://snaps.php.net
no, php5-200312011430 didn't help (just ./configure; make).
I've tried this snapshot and current CVS-version on 2 linux-boxes with the same result.
It still tries to eat memory =(
Second machine is:
Linux 2.4.18-5
gcc-2.96
autoconf 2.50
automake 1.4-p5
libtool 1.5
Apache 1.3.27
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
no, php5-200312011430 didn't help (just ./configure; make).
I've tried this snapshot and current CVS-version on 2 linux-boxes with the
same result.
It still tries to eat memory =(Second machine is:
Linux 2.4.18-5
gcc-2.96
autoconf 2.50
automake 1.4-p5
libtool 1.5
Apache 1.3.27
My first machine:
Linux 2.4.16
gcc-2.95-3
autoconf 2.52
automake 1.4-p5
libtool 1.5
Apache 1.3.20
Now trying on a second machine:
Linux 2.4.18
gcc-3.3
autoconf 2.57
automake 1.7
libtool 1.5
Apache 2.0.48
JOhn
Now trying on a second machine:
Linux 2.4.18
gcc-3.3
autoconf 2.57
automake 1.7
libtool 1.5
Apache 2.0.48
On this machine build is OK
JOhn
On Mon, 1 Dec 2003 18:21:33 +0100
"John Huntjens" john@ceressoft.nl wrote:
Now trying on a second machine:
Linux 2.4.18
gcc-3.3
autoconf 2.57
automake 1.7
libtool 1.5
Apache 2.0.48On this machine build is OK
I've changed autoconf to 2.57 and automake to 1.7 - all the same.
Upgrading Apache to 1.3.29 doesn't affect this too.
Found an interesting effect:
this bug appears only when I'm using Opera or Mozilla.
both lynx & wget browse ok =)
Derick, please, take an attentive look at your patch to SAPI.c, SAPI.h, rfc1867.c, php_variables.c (Sat Nov 29 10:24:35 2003)
- Fix sapi_input_filter patch.
Reverting your patch fixes the problem, cause the problem seems to be in header parsing routines.
Again, the problem is definitely in this patch.
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
Finally..if you had mentioned THIS in the first place, you wouldn't
have wasted our time..
(didn't I ask for some reproducing procedure? I don't remember anymore :)
--Jani
On Mon, 1 Dec 2003 18:21:33 +0100
"John Huntjens" john@ceressoft.nl wrote:Now trying on a second machine:
Linux 2.4.18
gcc-3.3
autoconf 2.57
automake 1.7
libtool 1.5
Apache 2.0.48On this machine build is OK
I've changed autoconf to 2.57 and automake to 1.7 - all the same.
Upgrading Apache to 1.3.29 doesn't affect this too.Found an interesting effect:
this bug appears only when I'm using Opera or Mozilla.
both lynx & wget browse ok =)Derick, please, take an attentive look at your patch to SAPI.c, SAPI.h, rfc1867.c, php_variables.c (Sat Nov 29 10:24:35 2003)
- Fix sapi_input_filter patch.
Reverting your patch fixes the problem, cause the problem seems to be in header parsing routines.
Again, the problem is definitely in this patch.
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
On Mon, 1 Dec 2003 18:21:33 +0100
"John Huntjens" john@ceressoft.nl wrote:Now trying on a second machine:
Linux 2.4.18
gcc-3.3
autoconf 2.57
automake 1.7
libtool 1.5
Apache 2.0.48On this machine build is OK
I've changed autoconf to 2.57 and automake to 1.7 - all the same.
Upgrading Apache to 1.3.29 doesn't affect this too.Found an interesting effect:
this bug appears only when I'm using Opera or Mozilla.
both lynx & wget browse ok =)Derick, please, take an attentive look at your patch to SAPI.c, SAPI.h, rfc1867.c, php_variables.c (Sat Nov 29 10:24:35 2003)
- Fix sapi_input_filter patch.
Reverting your patch fixes the problem, cause the problem seems to be in header parsing routines.
Again, the problem is definitely in this patch.
Hmm, interesting. But I'll need to have abetter 'bug' report before I
can do anything about it as things work just fine for me...
Derick
Derick, looking at the code it looks like we are checking for the a= case
and handling that correctly, but not the =a case. As in foo.com?a= vs
foo.com?=a
Not sure if it is yours or my bug. Currently in India and the connection
here is too damn slow to browse through cvs.
-Rasmus
On Mon, 1 Dec 2003 18:21:33 +0100
"John Huntjens" john@ceressoft.nl wrote:Now trying on a second machine:
Linux 2.4.18
gcc-3.3
autoconf 2.57
automake 1.7
libtool 1.5
Apache 2.0.48On this machine build is OK
I've changed autoconf to 2.57 and automake to 1.7 - all the same.
Upgrading Apache to 1.3.29 doesn't affect this too.Found an interesting effect:
this bug appears only when I'm using Opera or Mozilla.
both lynx & wget browse ok =)Derick, please, take an attentive look at your patch to SAPI.c, SAPI.h, rfc1867.c, php_variables.c (Sat Nov 29 10:24:35 2003)
- Fix sapi_input_filter patch.
Reverting your patch fixes the problem, cause the problem seems to be in header parsing routines.
Again, the problem is definitely in this patch.Hmm, interesting. But I'll need to have abetter 'bug' report before I
can do anything about it as things work just fine for me...Derick
Derick, looking at the code it looks like we are checking for the a= case
and handling that correctly, but not the =a case. As in foo.com?a= vs
foo.com?=a
That is something I did not touch, but I found the problem which caused
this...forgot to change the default sapi input filter handler to return
new_val_len. I'll have a look at the =a case (what should this do?)
later.
Derick
Derick, looking at the code it looks like we are checking for the a= case
and handling that correctly, but not the =a case. As in foo.com?a= vs
foo.com?=aThat is something I did not touch, but I found the problem which caused
this...forgot to change the default sapi input filter handler to return
new_val_len. I'll have a look at the =a case (what should this do?)
It should skip the variable.
-R
Derick, looking at the code it looks like we are checking for the a= case
and handling that correctly, but not the =a case. As in foo.com?a= vs
foo.com?=aThat is something I did not touch, but I found the problem which caused
this...forgot to change the default sapi input filter handler to return
new_val_len. I'll have a look at the =a case (what should this do?)It should skip the variable.
No problems here, as safe_php_register_variable calls
php_register_variable, which calls php_register_variable_safe, which
calls php_register_variable_ex which has this code in there:
/* ignore leading spaces in the variable name */
while (*var && *var==' ') {
var++;
}
var_len = strlen(var);
if (var_len==0) { /* empty variable name, or variable name with a space in it */
zval_dtor(val);
return;
}
Derick
On Mon, 1 Dec 2003 20:12:38 +0100 (CET)
Derick Rethans derick@php.net wrote:
Reverting your patch fixes the problem, cause the problem seems to be in header parsing routines.
Again, the problem is definitely in this patch.Hmm, interesting. But I'll need to have abetter 'bug' report before I
can do anything about it as things work just fine for me...
ok, I'll try to figure out the exact reason.
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
On Mon, 1 Dec 2003 18:04:46 +0200 (EET)
Jani Taskinen sniper@iki.fi wrote:Try with the snapshot from http://snaps.php.netno, php5-200312011430 didn't help (just ./configure; make).
I've tried this snapshot and current CVS-version on 2 linux-boxes with the same result.
It still tries to eat memory =(
Was there some script to go with this..?
gcc-2.96
There is no such gcc version..
autoconf 2.50
No workie.
libtool 1.5
No workie.
--Jani
Jani Taskinen wrote:
Was there some script to go with this..?
Maybe this is related to the problem with PHP's logos I posted earlier?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
On Mon, 1 Dec 2003 20:46:38 +0200 (EET)
Jani Taskinen sniper@iki.fi wrote:
It still tries to eat memory =(
Was there some script to go with this..?
<? phpinfo(); ?>
or
<? echo "1"; ?>
it doesn't matter, cause it seems to be happening on the stage of parsing ENV or SERVER variables.
gcc-2.96
There is no such gcc version..
gcc --version
2.96
RH-based distribution, you know =)
autoconf 2.50
No workie.
works ok for me.
libtool 1.5
No workie.
again, works ok for me.
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net