Everything

php

HEAD eats all memory

php.internals

Antony Dovgal

22 years ago

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

John Huntjens

22 years ago

> 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

Antony Dovgal

22 years ago

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

John Huntjens

22 years ago

> > > 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

Derick Rethans

22 years ago

On Mon, 1 Dec 2003, John Huntjens 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.

Derick

John Huntjens

22 years ago

<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!

JOhn

Antony Dovgal

22 years ago

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

Edin Kadribasic

22 years ago

On Monday, Dec 1, 2003, at 17:12 Europe/Copenhagen, John Huntjens 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!

<snip>

Hey John, no need for harsh tone. PHP5 is work in progress so while it
is nice that people test the snaps there is by no means a guarantee
that things will work. So tone down your replies a bit.

Edin

John Huntjens

22 years ago

> > <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!
> <snip>
>
> Hey John, no need for harsh tone. PHP5 is work in progress so while it
> is nice that people test the snaps there is by no means a guarantee
> that things will work. So tone down your replies a bit.

Well, I am normally a very polite guy, but when someone tell's me to shut up
...

JOhn

Ilia A.

22 years ago

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

Antony Dovgal

22 years ago

On Mon, 1 Dec 2003 17:03:43 +0100 (CET)
Derick Rethans <derick@php.net> wrote:

> On Mon, 1 Dec 2003, John Huntjens 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

Jani Taskinen

22 years ago

On Mon, 1 Dec 2003, Antony Dovgal 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.

>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

Antony Dovgal

22 years ago

On Mon, 1 Dec 2003 20:56:53 +0200 (EET)
Jani Taskinen <sniper@iki.fi> wrote:

> On Mon, 1 Dec 2003, Antony Dovgal 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

Jani Taskinen

22 years ago

Works fine for me.

--Jani

On Mon, 1 Dec 2003, Antony Dovgal wrote:

Sebastian Bergmann

22 years ago

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/

Antony Dovgal

22 years ago

On Mon, 1 Dec 2003 17:40:09 +0200 (EET)
Jani Taskinen <sniper@iki.fi> wrote:

>
>     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

Jani Taskinen

22 years ago

Try with the snapshot from http://snaps.php.net

--Jani

On Mon, 1 Dec 2003, Antony Dovgal wrote:

Antony Dovgal

22 years ago

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

John Huntjens

22 years ago

> 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

John Huntjens

22 years ago

> 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

Antony Dovgal

22 years ago

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.48
>
> On 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

Jani Taskinen

22 years ago

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, Antony Dovgal wrote:

Derick Rethans

22 years ago

On Mon, 1 Dec 2003, Antony Dovgal wrote:

> 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.48
> >
> > On 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

Rasmus Lerdorf

22 years ago

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, Derick Rethans wrote:

Antony Dovgal

22 years ago

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

Jani Taskinen

22 years ago

On Mon, 1 Dec 2003, Antony Dovgal wrote:

>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 =(

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

Sebastian Bergmann

22 years ago

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/

Antony Dovgal

22 years ago

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